Implement global abbreviations

[admirabilis]

fish, version 2.7.1

It would be best if abbr would expand after sudo. So typing something like sudo mv<SPACE> would expand to sudo mv -i . Maybe a way to implement that would be hardcoding abbr to work specifically after the sudo command too...

Currently, I have a function that wraps other functions so they may work with sudo. But abbr is much safer in that you see what additional arguments are being given.

^{Another blocking issue for my own reference #3233}

[ridiculousfish]

fish should not establish an abbreviation-savvy whitelist, which users and new commands can't participate in.

IMO we ought to simply implement global abbreviations. These would be abbreviations which work everywhere, not just in command position. I think this would solve most of the pain around sudo, and also enable e.g. !! which we could even ship by default.

[mig-hub]

I agree with @ridiculousfish because it is quite a common thing to have commands taking commands as argument like sudo but also bundle exec, time, dotenv to name a few and it is also quite common to write functions which take a command as an argument. Keeping a white list would be limiting and also they can be nested.

[mqudsi]

@ridiculousfish that would also address the questions we get about aliases that can trigger redirects or piping, which are possible under bash (and zsh?) thanks to the substitution of aliases prior to evaluation.

[crabdancing]

I think the option to whitelist/blacklist for global abbreviations would be super useful though -- for example, let's say I abbreviate youtube-dl to ytdl. That's fine. And then I'm cding into my git repo for ytdl, perhaps a wrapper around youtube-dl, and oh no. It just tried to cd to youtube-dl instead. That's not helpful at all.

Edit: so, in my opinion, each global abbreviation should have a whitelist option, and a blacklist option -- and if neither are used, then it can apply everywhere default. This lets the user set their own sane behavior profile for their shell environment, and should cover every use case very nicely without increasing code complexity too much.

Personally, I'd probably just use whitelisting for sudo and a few other commands, as I tend to use a lot of abbreviations and I can imagine that'll translate to a lot of false positives if they're global abbreviations.

[faho]

so, in my opinion, each global abbreviation should have a whitelist option, and a blacklist option -- and if neither are used, then it can apply everywhere default.

Well... that just means you need to spend a whole bunch of time tweaking (and re-tweaking) this behavior.

I'd rather just we use a different binding for expanding global abbrs. E.g. ctrl-space.

[crabdancing]

@faho Not really. Personally, I'd probably just start with a whitelist for sudo, and add a few others as time goes by. I don't see how it wouldn't be helpful. Something like gabbr --whitelist=sudo sctl systemctl would be pretty common-sense and easy.

Edit: whitelist could take an array, so if you want multiple abbreviations with the same whitelist, just define an array and pass it to all of them.

Edit 2: So, it'd look like...

set wl sudo su ssh
gabbr -w "$wl" jctl journalctl
gabbr -w "$wl" sctl systemctl
gabbr -w "$wl" vim nvim

Edit 3: thinking about it, though, this wouldn't solve my example problem without explicitly blacklisting file manipulation commands -- and, adapting to that problem would be prohibitively complicated. "Configurability is the root of all evil" and all that.

Soooo, in my case, I'd probably end up having an extensive blacklist... which surely isn't ideal either.

And I should point out with your key combo idea, that won't mesh with all workflows well. Honestly, I'd probably end up just typing enough of the thingy I wanted to get a tab autocomplete suggestion, and ignoring the entire feature, if that's the only way it worked. Press-and-hold key presses are more time-expensive than tap key presses, in my experience. (And it adds cognitive expense to the user to have to decide when to trigger completion, when ideally they shouldn't have to worry about it...)

Edit 4:

So, after thinking about all those caveats, I think maybe the solution is to have the abbreviation expansion work after sudo for the first argument, but if something after that happens, it won't expand it. So, for example, sudo sctl poweroff expands to sudo systemctl poweroff, but sudo mv sctl ~ won't expand to sudo mv systemctl ~ -- it implicitly encapsulates the syntactic logic using only the context and needing minimal cues from the user. I think that's pretty in-line with FISH's design goals.

[admirabilis]

I'm more inclined to the whitelisting approach too, because if I forget to press Ctrl+Space after an abbr, it would defeat the purpose of setting aliases like rm -i, and I would need to keep using functions instead (which have the disadvantage of not showing explicitly what has been modified).

[manfredlotz]

Is there a chance it will be implemented? IMHO, it should be implemented in a way that it is a new option to use with abbr. Then it would be backward compatible which makes many people happy.

[faho]

Is there a chance it will be implemented?

It's still open, so yes.

[manfredlotz]

For the time being I have implemented my own stuff https://gitlab.com/Lotz/fish_globabbr (taken code from #731) which works fine for me but I'm sure it doesn't fully cover the existing abbr functionality.

So, let's hope it will be implemented.

[ridiculousfish]

Yeah I definitely think we should do something here. I want to expand abbreviations so that they can run arbitrary code like completions can, and also improve the pager.

[rajashekar007]

I really look forward to have this functionality.
@manfredlotz I tried with your change, it didn't work for me. Do I have to do something more than what is mentioned in README.

[manfredlotz]

Hm. I have no abbr statements in use but only globabbr. Perhaps you have also some other abbr statements which do interfere.

Just to make sure: you have a bind for ' '?

I have

$ bind | grep globab
bind ' ' '__fish_expand_globabbreviation; commandline -i " "'

[scooter-dangle]

+1 for opt-in (either by requiring an extra flag to abbr or using a different key-binding) rather than opt-out (all existing abbrs now expand everywhere).

That said, I don't know that this is a feature I've ever really desired. In the cases where I've been already in a command and realized I need something I've defined an abbreviation for, I do <ctrl-U>, type the abbreviation, and then type <space><ctrl-a><c-y><space><ctrl-e>. That's not super ergonomic, but I'm usually grabbing+editing more complicated commands from my history anyway rather than writing them out in a way that abbreviations would help.

Maybe it would be useful to have people use something like what @manfredlotz provided for awhile and see what effect it has on their workflow? E.g., how many global abbrevs do they end up defining? How many do they end up using frequently?

In the cases I currently use abbreviations, I would hesitate to make them global for fear of accidentally attempting to use them as arguments. It would force me to remember all my global abbreviations at all times, whereas with the current abbreviations, I can instead limit my thinking about them to the few contexts where they expand.

It's possible though that I'm just not being very imaginative about the benefits global abbreviations could provide to my workflow.

[faho]

#9313 is merged, closing this.