How to force filename completion under oh-my-zsh? - autocomplete

The problem:
Sometimes, when I try to do things in zsh, it won't complete the filenames I want because they don't apply to the current context. Two examples:
I want to force-add a file which is currently ignored in hg or git. oh-my-zsh tries to help me by only completing non-ignored files, but in this case it is a hindrance. I'm forced to type the full path to the file manually.
I want to use git diff to diff two arbitrary files on my hard drive. These files do not reside in any repository, but who cares?! git diff --no-index is a really nice way to diff any two files. But because they aren't in a repo, zsh won't complete them.
The proposed solution:
I could simply edit the source control context to complete all filenames, regardless of their source control status. But there are a couple limitations:
I don't know how to do that.
It might be nice to have an "escape hatch" whereby I could force file completion, no matter what the context.
So, I decided instead to bind a key shortcut to force normal, context-free file completion.
What I have so far:
Zsh apparently has an easy way of doing this, as detailed in this question. So I've added the following lines to my .zshrc:
zle -C complete complete-word complete-files
bindkey '^[[Z' complete
complete-files () { compadd - $PREFIX* }
This causes shift-tab to initiate file completion. It works beautifully in standard zsh! But boo-hoo, for some reason it doesn't work when I source oh-my-zsh. :-(
So is there a way to get this to work with oh-my-zsh, or is there an alternative solution I might find satisfying?

My way of doing exactly that (replacing the default diff command with the one from git) was pretty straightforward.
Add this to your ~/.zshrc:
diff() {
git diff --no-index "$#"
}
Before I was using an alias, but since zsh can "solve" them, it was then using the autocompletion functions from git diff, which inadvertently led to the same problem as you.
Using a function solves this issue as zsh reverts to the classic "files only" completion.

Related

Sublime fails to open new_file in macro

In Sublime (Version 3.2.2, Build 3211) (Ubuntu 18.04.5), I'd like to record a macro where I select-all, copy and paste the current content into another, unsaved file. And then do other commands as well, but I'm not even getting that far. The new-file step doesn't seem to work – neither new, nor new_window, newWindow, new_file, newFile seem to work; not even reopen_last_file. It should be new_file, though.
The console throws this:
Unknown macro command new_file
Which is weird. The command new_file works fine in other contexts: looking at the key-bindings settings, ctrl+n is bound to the same command and the hotkey has no issues.
Selecting all, copying – even this following bit works as intended:
{
"command": "insert",
"args": {"characters": "Hello, Friend!\n"}
}
In their forums, user "jps" writes:
With regards to the other console messages (unknown command, etc), don’t worry about them, they’re supposed to be there :slight_smile:
… but this doesn't seem to be right if it's obviously not working.
I have a project open but closing the project has no effect.
Is there maybe a package or something missing?
Macros in sublime can only capture and replay TextCommand commands; that is, commands that directly modify the content of a buffer or it's visual state. Examples including adding or removing text, changing the selection, moving the cursor around or changing view specific settings (like toggling word wrap or changing rulers, etc).
Commands like new_file, new_window or opening and closing projects are WindowCommand commands, which can't be captured via a macro.
In order to run a sequence of commands that includes a WindowCommand (or ApplicationCommand), you need to use a package. Two examples of that which are readily available on Package Control are Chain of Command and Multicommand.

How do you disable fish shell's guessing autocompletion feature?

In bash, if you type something like:
ls /etc/abc
and hit <tab>, it will beep, and do nothing, basically letting you know that it couldn't figure out how to complete it. In the case of that specific command, a file starting with /etc/abc didn't exist.
In fish, it will use some sophisticated algorithm to figure out what it thinks you may have meant, and can change what you typed completely, possible changing your ls /etc/abc to ls /etc/fstab, because at some point in the past, you may have typed ls /etc/fstab.
I'm sure it's not that arbitrary, but the fact is, it removed my /etc/abc arg, and replaced it with what it thought I meant. Sometimes, I made one mistake in one character, and instead of going back and fixing my mistake like I would in bash, hitting <tab> replaced the entire thing I wrote, forcing me to rewrite the entire arg.
I can see how some people might like this feature, but for me, it's insanely annoying. Maybe I'm just used to bash.
Is there a way to have fish turns this off, so it never replaces what I wrote? If I wrote /etc/abc, hit <tab>, and it can't figure out a completion that starts with that, leave it alone. Don't replace it with its best guess.
I don't even know what the feature is called. Does it even have a name, or is it just a nameless part of the autocompletion of fish?
Update:
A real example I just ran into.
I have a file in the current directory named lib.py. I type git difftool li and hit <tab>. It replaces what I wrote with git difftool templates/nxt_connect/dish_controls.html, immediately making me want to stab somebody as I have to delete the super long string it helpfully filled in for me, and try again. What's worse is that I assume I typed something in wrong, so I'll try exactly the same thing, and end up with exactly the same result, only to realize fish doesn't have a completion file built-in for git difftool, which is why it doesn't even check my current directory for files.
and can change what you typed completely, possible changing your ls /etc/abc to ls /etc/fstab,
Fish won't change /etc/abc to /etc/fstab
What it will do is fuzzy-match your command, so e.g. /etc/ft will match /etc/fstab, but that's only because both "f" and "t" are in "fstab" in that order, and only if it was the only possible match.
This won't happen with /etc/abc, because that doesn't match /etc/fstab.
because at some point in the past, you may have typed ls /etc/fstab.
It does not take history into account in this case. It really only uses history for the autosuggestion - the greyed-out continuation of what you typed, but that only does prefix matching.
Is there a way to have fish turns this off, so it never replaces what I wrote?
Fish provides no option to change this behavior.
The next fish release (version 3.2) will offer an "undo" function (bound to ctrl+z by default) so you can undo any match by pressing that.
is it just a nameless part of the autocompletion of fish?
fuzzy matching.

IPython's history-search-backward not working as desired

IPython's history-search-backward feature is one of my favorite features. history-search-backward allows you to type part of a command and then search backward through your readline history for commands that began with that part of the command. By default (I believe) these are bound to UpArrow or Ctrl+P and DownArrow or Ctrl+N (for backward and forward respectively).
They are not working for me. Instead they just go linearly through my history instead of taking into account the characters I've already typed to (allgedly) filter my history.
I'm running IPython 0.13.2 (with Python 2 and 3) on Arch Linux from within XTerm.
If I hit Escape, Ctrl+P, then UpArrow and DownArrow work exactly as I want them to.
Additionally if I change my ipython_config.py to include
c.TerminalInteractiveShell.readline_parse_and_bind = ['"\\e[B": history-search-forward', '"\\e[A": history-search-backward']
then I can just do Escape UpArrow for the desired behaviour. (Here's the rest of my config file.)
Ctrl+V UpArrow produces ^[[A as I expect. I have the python readline library installed (which seems to fix common problems with macs running IPython).
I have these lines in my .bashrc
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
and they work exactly as I want them to within bash.
I have no idea what else to try next, so I've come here. Please help, I hope I've included enough information and done enough research.
The culprit was set keymap vi set in my .inputrc. I removed that and IPython history went back to what I expected. Thanks to #Thomas K!

meld: Make one part read only

Up to now I used emacs ediff mode for merging. I tried meld, but could not find a way to make one buffer/file read only. I never merge in two directions, that's way I make one part read only before merging.
The "Merge mode (in development)" section on the meld features page calls this Lock down and that kind of functionality doesn't seem to be released yet, beside it not being clear if this can be used outside of merge mode. ( status 2020-08 )
WHat you can do is make the file you don't want to change (temporarily) read-only.
That will give you a lock-icon and a grey-ed out "Save file in this pane" icon next to your filename, and you cannot edit the file in that pane.
This article can help you I believe. It says
[merge]
tool = mymeld
[mergetool "mymeld"]
cmd = meld --diff $BASE $LOCAL --diff $BASE $REMOTE --diff $LOCAL $MERGED $REMOTE
This is what I call traditional two-way merge with tabs. Now, since I
already noted Meld supports three-way merging, there is another
option. When “diff3” git conflict style is set, Meld prints “(??)” on
the line showing the content from BASE. In this mode, LOCAL and REMOTE
files are read-only which is also handy.

Is there any ECB (or other)-enhanced find file mojo?

Can I use ECB (or some other project aware thing, like eproject, ibuffer, etc.) to enhance emacs's find-file goodness?
Imagine this scenario: I have several projects/directories specified in my ecb-source-path, let's call them Project1 and Project2, and they look like so:
Project1
foo.c
bar.c
Project2
foo.c
baz.c
I'd like to have find-file (or another command) work to find and jump to the files there without having to navigate to the ecb directories buffer, or have the buffers open already.
I guess my ideal usage scenario would be like so:
I'd like to C-x C-f baz (or another special command) to open Project2/baz.c. Going even further, I'd love if I could use something like ido's flex matching to get p2foo open Project2/foo.c.
¿C'est posible?
If in your example you are in project1 foo.c, and you want to get to project1 bar.c, I think most of the project tools like ede, eproject, gnu global, idutils integration etc have "jump to file" type commands. I, of course, recommend the CEDET/EDE and ECB combination. The keybinding is C-c . f which is ede-find-file.
Setting up CEDET and EDE is pretty easy, but EDE knows only a small number of different project types, and you may need to configure it for your projects by hand which is less easy.
If you want to be in project1/foo.c and jump to project2/baz.c, you just need to use locate:
M-x locate RET baz.c RET
Now select from the list.
You could use the filecache package to index the directories you want, then use ido to choose a filename from the cache. Here is one example; there are other implementations you can Google for.
Take a look at find-file-in-project. It seems to me you're looking for something similar.
I've written a package find-file-in-tags which enables you to open files in your TAGS file without specifying the path to the file. If there are multiple files that match what you've entered, you're prompted to refine your choice (or open all).
Additionally, if you have multiple work areas for the same project, find-file-in-tags uses a single TAGS file for all those work areas but opens up the file in the same work area as the buffer in which you are invoking find-file-in-tags.