fish-shell icon indicating copy to clipboard operation
fish-shell copied to clipboard

abbr doesn't kick in after tab

Open mqudsi opened this issue 5 years ago • 4 comments
trafficstars

I'm opening an issue rather than committing a fix directly because I'm not entirely certain what the default behavior should be in this scenario.

If you have abbr camcontrol "sudo camcontrol" and then start a command with camcontrol , the prompt will update to $ sudo camcontrol , but if you instead type in part of the command name and let it autocomplete the rest,† e.g. camcontrol<tab> the prompt will change to $ camcontrol with the abbreviation not kicking in.

I know there are basically two use cases for abbr, one for "shortcuts" and the other for typo corrections. I personally discourage the use of abbr for shortcuts and think that functions should be used, but I can see how completions wouldn't be taking abbr into account in that case. However for "typo" correction (gti -> git, foo -> sudo foo), I think we might want to check the abbr list post-completion for the sake of uniformity?

† here for the sake of reducing completion ambiguity the entirety of the command name will be typed in before completing

mqudsi avatar Oct 03 '20 15:10 mqudsi

I know there are basically two use cases for abbr, one for "shortcuts" and the other for typo corrections.

I don't think abbr is for typo correction. You'd have to set up the list of mistakes beforehand, which seems fairly awful.

So... shortcuts remain, and I think they're brilliant for that, as a replacement for those shortcut aliases that nobody can remember (gs, gc, grm style git aliases especially).


if you instead type in part of the command name and let it autocomplete the rest,† e.g. camcontrol the prompt will change to $ camcontrol with the abbreviation not kicking in.

But if you then press space and it kicks in, no?

We could of course expand the abbreviation after the completion has been picked if the completion entry was an abbreviation (we should always be careful if people add abbrs that have the same name as existing commands),

faho avatar Oct 03 '20 15:10 faho

You'd have to set up the list of mistakes beforehand, which seems fairly awful.

Maybe, but if you take into account that most are going to be infrequent, you're only left with the repeat offenders. You'd be surprised: mkae -> make and fgfg -> fg just about cover it for me! mkae is, I think, an artifact of the Dvorak layout, and as for the latter, it happens when I quickly ^Z out of something, type in fg, get caught perusing something in my terminal history, then blindly type in fg again before actually hitting Enter - weird, I know.

But if you then press space and it kicks in, no?

Yup. That's the reason for filing the PR, as the inconsistency seems off.

mqudsi avatar Oct 25 '20 22:10 mqudsi

Yeah, igt and sl cover the mistakes I make 90% of the time.

zanchey avatar Oct 26 '20 13:10 zanchey

We could of course expand the abbreviation after the completion has been picked if the completion entry was an abbreviation (we should always be careful if people add abbrs that have the same name as existing commands),

I would be glad. A big use case for abbr for me is transparently providing default arguments to commands, e.g.

  abbr rm 'rm -i'
  abbr cp 'cp -i'
  abbr mv 'mv -i'
  abbr funced 'funced -s'

Functions/aliases would make it hard to occasionally modify the flags on the fly (while also remembering me what the 'real' defaults of the tools are).

The current behavior seems a bit inconsistent to me. If the added complexity would be reasonable, I'd be strongly in favor for reconciling that behavior.

t-nil avatar Sep 01 '23 11:09 t-nil