-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't suppress abbr expansion when executing command with no args #8423
Comments
Tbh I don't think execute should expand the abbreviations, and I think the binding shouldn't do it by default either. I kept that when I introduced expand-abbr because it was hardcoded on space and \r before, and I didn't want to change the behavior as part of that. (also it shouldn't be expanded if there's a space after - the idea was that you could press ctrl-space to insert a space and then do whatever, but I see that still triggers the expansion) |
The default Anyone who wants return to not expand can then rebind it. I just wish we could do Ctrl-Return to execute without expanding, but return is already |
With If e.g. you made "ls" an abbreviation for "exa", with This breaks the notion that abbreviations change what is written in the commandline and, unlike aliases, allow you to change and inspect it before execution. An alternative is to not execute if an abbreviation expands, so This would be bound like |
100% of my usage of If we change the |
I on the other hand have been surprised and annoyed by this.
And if we don't, anyone who wants this behavior can add the expand-abbr. Or press space. |
How about we do the uncoupling first and then discuss whether to change the default separately? |
I agree that |
Likewise. |
Okay, let's keep it then. Guess I have some customization to do! |
On a commandline like "ls arg" (cursor at end) we do not expand abbrevations on enter. OTOH, on "ls " we do expand. This can be frustrating because it means that the two obvious ways to suppress abbrevation expansion (C-Space or post-expansion C-Z) cannot be used to suppress expansion of a command without arguments. (One workaround is "ls #".) Only expand-on-execute if the cursor is at the command name (no space in between). This is a strict improvement for realistic scenarios, because if there is a space, the user has already expressed the intent to not expand the abbreviation. (I hope no one is using recursive abbreviations.) Closes fish-shell#8423
On a commandline like "ls arg" (cursor at end) we do not expand abbrevations on enter. OTOH, on "ls " we do expand. This can be frustrating because it means that the two obvious ways to suppress abbrevation expansion (C-Space or post-expansion C-Z) cannot be used to suppress expansion of a command without arguments. (One workaround is "ls #".) Only expand-on-execute if the cursor is at the command name (no space in between). This is a strict improvement for realistic scenarios, because if there is a space, the user has already expressed the intent to not expand the abbreviation. (I hope no one is using recursive abbreviations.) Closes fish-shell#8423
I made it so we don't expand if there is a space, I think that makes sense? I got a very spooky CI failure with asan, adding more sleeps helped.. |
Version: fish, version 3.3.1
I have an abbreviation
abbr -a -g -- ls exa
. If I want to run e.g.ls -a
by itself, I can press Ctrl+Space to insert a space without expanding the abbreviation. Unfortunately there's no equivalent for "execute without expanding abbreviation". Even adding the space (e.gls
) still expands it when I execute.I'm also not sure if it's even possible for me to write my own binding here. The binding for
\r
is justexecute
, which implies that execution implicitly expands abbreviations (whereas if it wereexpand-abbr execute
then I could have a binding toexecute
that skips the abbreviations).The text was updated successfully, but these errors were encountered: