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.