Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
auto_remove_slash feature from zsh #3253
Often when tab-completing directories, a trailing slash is added at the end of said completion. If the next character is a word delimiter, the said trailing slash should be removed (ideally configurable) - this behaviour would be exactly the same as in zsh when auto_remove_slash option is enabled.
Ultimately a purely cosmetic enhancement, but imho will make the output less ugly and more readable.
➜ 0 ~ find .config/fish/ -type f
(notice the unsightly double slash in the output)
No. It doesn't really seem unreasonable or super spooky:
So it's cleaning up after an often unpleasant completion artifact, for the most part, I think.
That's really the thing - "often" unpleasant. Sometimes pleasant. For varying values of "often" and "sometimes".
Sometimes you want the slash, other times you don't. We don't know which is which, and not removing the slash is the more obvious thing to do - you get what you type, and if you type a space, you get a space. Not "remove the last character, then add a space".
If you want the slash, and space removes it, then you need to press space, go back, readd the slash and then move right again (or typing a space should hopefully work).
If you don't want the slash, you can press backspace to remove it and then press space (or whatever else you want to do next), just like with everything else. Slashes aren't special in this situation, completion isn't special here, you just press the keys to edit the text. That's what I'm talking about when I say "magic". This is a sometimes-optimization for a quite specific thing, and quite non-obvious (unless you've already used it with zsh).
In addition, not everything that ends in a slash is a path, so this would need to be added to the file completion code (and everything that completes files).
In case you haven't guessed, this is a
You probably want a different example, @needmoreram, because the example you provided illustrates that the find command you're using needs an enhancement — not that fish needs to be changed. The macOS (BSD derivative)
I agree with @faho and vote no
Hi guys, thanks for jumping on this right away, and for your thoughts so far! To answer some of the questions above:
@zanchey yes, but only if that slash was inserted as a result of a completion (@faho it does not always remove them as your binding commands to the space-key do). Additionally, zsh highlights (just) the trailing slash if its removal is imminent upon inputting a delimit character. To keep said slash, you simply key in an additional '/' before the delimiter.
In practice, the keystrokes
The penalty you incur for this is one extra keystroke (slash) (@faho rather than the sequence you described involving going back and moving right). You still incur the same one stroke penalty today, when you want to remove the trailing slash (in the case of rsync/cp'ing the directory itself).
@krader1961 did not know that, thanks! :) Sure, another example where this would matter is when manipulating soft symlinks (symlink inode vs dir inode).
I suppose, in the end, it comes down to which action a majority of the community prefers/uses more regularly. Of course, not to shove such a feature down everyones throats, an option to turn it on (with default being off) would satisfy both sides :)
@faho Can you clarify in which cases a completion ending in a '/' won't be a path?
Yes, that's a wart of the simple hack I came up with. But my point regarding the "magic" stands - you press something that usually only inserts a character and a character disappears.
dbus has things that look like paths.
Another thought I had would be to not insert the trailing "/" in the completions in the first place. I need to think about that some more.
Well, there is the paragraph on how "Configurability is the root of all evil" in our design document.
In general we try to not be like zsh. They add everything and hide it behind an option. We try to add sensible things and enable them by default.
@faho Thanks for the link, and after reading it over, I realized that this was one of the main reasons I started to use fish in the first place! And so I agree, making this an option will be big compromise without justifiable improvement in workflow/productivity.
True, this crossed my mind when typing out the sequence in my previous comment.
Thanks again everyone and especially @faho for your patience in taking the time to explain things :)
Coming from zsh, I started using fish yesterday and I've already made a mess with
Putting #3253 (comment) in a function and binding it with
I am now using a function to strip trailing slashes just for rsync, similar to the one in the archlinux wiki.
is equivalent to
Which is entirely unexpected imo but I don't think we can get
I'm not sure what the best solution to this is, but we can be more liberal with a solution because of fish 3.