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.
Related
Assume I want to invoke a tool with a lot of options, like:
$ somescript --option1 --option2 --option3 --option4 --option5 whatever even more stuff
But the width of the terminal doesn't allow to have that thing on a "single line".
That alone isn't a problem, but with fish, there is a problem with scrolling.
When I enter that extra-wide command, at some point, there will be a line break:
$ somescript --option1 --option2 --option3 --option4 --option5
whatever even more stuff
All fine so far. While typing such a lengthy command, I can scroll forth and back at any point. Works as expected. So, assume I entered the command, made a mistake, and now want to remove --option4.
The normal thing: use "arrow up" to get to that command in the history, to then use "arrow left" to scroll within the command. And now something weird happens.
Everything is fine while the cursor is within the second line. But when the cursor moves to the first line ... after 3 to 5 more "arrow left" strokes, the cursor moves UP another line. Then it sits above the first line of the command. There is also a vertical jump of a few characters.
In other words: as soon as a command is longer than the width of the terminal, I am unable to scroll into the first line reliably. The cursor shows up somewhere, and it is really hard to guess where it really sits at any moment. Which makes it almost impossible to edit anything in that first line.
This is on MacOs, using iterm 3.2.9 and fish version 3.0.2 installed via brew.
Wrote up defect 6014 on github. Outcome is rather frustrating.
The problem is: the Mac terminal(s) all handle certain unicode characters the wrong way. "Normally" that isn't a problem, but when you use one of those fish prompts that give you the git status (like AcidHub which is my favorite) ... fish can't compute/determine the exact line width, and there you go.
So, basically, when using fish on MacOs, option space is limited to:
use the defaults, which (when using special prompts, like AcidHub will lead to scrolling issues)
adapt the fish prompt accordingly (in my case, I replaced all special unicode chars with something simpler). It doesn't look that great, but scrolling simply works again.
And a completely different and unexpected solution to the problem: I am using iterm2 on my Mac, and iterm2 just added a "status bar" section. That can be easily configured, and of course, it already has a status bar component that tells you about git status.
Thus my solution: I changed the fish prompt to just give the PWD, and all the other things that the AcidHub prompt has to offer, are now "iterm2 status bar" components!
For reasons outside of my control I'm stuck using python 2.6.6 and IPython 0.10.2. I also normally use the tcsh shell, and have gotten quite used to completing a command from the history using <A-p> (i.e. pressing the ALT key and p). However, this doesn't work in IPython. I know I can press <C-r> and then start typing a command, but what inevitably is happening is that I start a command, press <A-p>, get a colon indicating some weird state, then exit out of that state, delete my command, press <C-r> then search for my command. It's getting rather irritating. Is there any way to make <A-p> complete my already started command by relying on the history?
Ouch, this is an old version of IPython, Python (and pip). The bad news is I don't have much experience with such an old version of IPython, the good new is; it was way simpler at that time.
Most of the shortcut and feature are provided using readline, and the python bindings of stdlib. Meaning that most likely what you are trying to configure is readline itself and not only IPython; so you can find more information on that outside of IPython !
The secret is to grep in the source-code for parse_and_bind, then you'll find the following example configuration, leading me to change the ~/.ipython/ipy_user_conf.py to be like so at around line 99 (all indented an extra 4 space to be in the main() function):
import readline
readline.parse_and_bind('set completion-query-items 1000')
readline.parse_and_bind('set page-completions no')
rlopts = """\
tab: complete
"\C-l": possible-completions
set show-all-if-ambiguous on
"\C-o": tab-insert
"\M-i": " "
"\M-o": "\d\d\d\d"
"\M-I": "\d\d\d\d"
"\C-r": reverse-search-history
"\C-s": forward-search-history
"\C-p": history-search-backward
"\C-n": history-search-forward
"\e[A": history-search-backward
"\e[B": history-search-forward
"\C-k": kill-line
"\C-u": unix-line-discard"""
for cmd in rlopts.split('\n'):
readline.parse_and_bind(cmd)
The repetition of commands make me think that what \C,\M or [e mean might be system dependant. I would bet on \C being Control, and \M being Meta (Alt, Opt), but at least one of these line did the trick for me (and also now tab allows to complete). See also man readline for the list of commands you can bind to what, and enjoy! Hoping you can upgrade to Python 3 and IPython 6 at some point.
[Edit]
See Eric Carlsen second comment under this answer for how it was resolved.
I am working on porting Google Cloud SDK command line auto completion feature to fish shell. When I have an unambiguous reply with multiple arguments:
A) Either the command is completed with all those arguments BUT spaces gets escaped (\ ) when I specify the function call in the complete command inside ''s or ""s, like: > complete ... -a '(__fun)'
B) or if I don't do that (just: -a (__fun)), then only the first argument of the reply gets into the completion and all the other arguments "get lost"
Is it possible to reply with multiple arguments at once in fish completion?
Could be done in a number of ways. You will have to hack it a bit, though, since as ridiculous_fish says it's not designed for this.
Easiest would be to ship your own wrapper function that can take the escaped output and pass it on in a way that works. Not very pretty, though, and would screw with autosuggestions unless you also go back and modify the history lines.
Here's something semi-hacky/semi-elegant I would propose:
If you have looked up a "sequence" of args you'd want to complete at once, at first invocation put the trailing args as the description to the first one. Once that one has been locked in, remove all other options but the first in this "description queue", keep going through it and it will simply be a matter of quickly pressing tab-tab-tab-tab.
Completions don't have to be perfect, they're mostly a lil help on the way until you have enough history lines that autosuggestions take over, imo.
With Emacs, if the current buffer is one that's "visiting" a normal file (for example), whose full pathname is /path/to/somefile, and one runs find-file (C-x C-f), the prompt that appears in the mini-buffer is something like
Find file: /path/to/▮
...with the cursor placed as indicated above by ▮. IOW, the suggested path shown by default is always to the directory containing the file that the current buffer is visiting.
If, however, the current buffer is an Emacs shell process, and one runs find-file, then, AFAICT, the path shown in the prompt remains fixed at the value of $PWD when the shell process was started, irrespective of the current value of $PWD:
Find file: /pwd/at/startup/▮
This behavior is not so useful, because the $PWD at startup often becomes irrelevant later on. It would be really nice if the directory shown in find-file's prompt were instead the shell process's current $PWD.
Is there a simple way to modify find-file to behave this way whenever the current buffer is a shell process?
You want "shell directory tracking". E.g. check dirtrack-mode or shell-dirtrack-mode.
shell-dirtrack-mode tries to parse "cd" commands, (event_jr: which in my experience does not work consistently). dirtrack-mode uses the prompt regexp, which works very well.
There are a number of ways to manage this. As Stefan notes, there are a couple of built in packages that manage it.
My preferred way is to alter your prompt (when in Emacs) to have the $PWD embedded in it, and then Emacs strips it out and uses it. This has the benefit of always being up to date. I've found that dirtrack-mode sometimes gets out of sync.
Check out my solution here, which is a modification of a similar implementation on the Emacs Wiki.
I am using emacs and the auto-newline feature is not working as expected. I have a pretty large number of customizations done to my emacs. So it would be no wonder if one of the other customizations is not what auto-line is expecting. I would like to know if there is a way to know the list of commands (list of emacs commands) executed by emacs at a particular point, for e.g. when ctrl-s ctrl-c or in my case when auto-line feature is called.
edit : I think you have misunderstood the question. I would like to know what command emacs calls 'internally'.
I believe view-lossage is what you're looking for -- M-x view-lossage, or C-h l.
If you want to know what a keystroke is bound to, consider using describe-key, which is usually bound to C-h k.
Basically at this point, you need to bite the bullet and learn some Emacs-lisp. The debugger is what you are looking for to dig further into your problem (I use edebug). It's not just about seeing what functions get called, you also need to see the values of the relevant variables when those functions are called.
If you feel you're not up to it, then you can bi-sect your init file until you find the culprit, but at that point you still need some Emacs-lisp to investigate further.
To add to what #event_jr said --
What you seem to be asking is the history of the functions called by the command you last invoked. (You speak of Emacs "internal commands", but it seems you just mean functions.)
To get that history for any given command you invoke (e.g., by a key), use M-x debug-on-entry and then enter the command name. The next time you use that command, you can walk through its execution in the Emacs debugger (hit d to step, c to continue past a step).