abbr: Allow restricting to a specific command's arguments

[faho]

This is very much a nice-to-have, it does not need to be in the initial release with "Mega abbr".

One of the examples in #9313:

function git_c
    string match --quiet 'git c ' -- (commandline -j); or return 1
    echo checkout
end
abbr -a git_c --position anywhere --regex c --function git_c

This is supposed to allow adding abbreviations for git subcommands. It would be cool if this could be

abbr --add --command git c checkout

Which allows us to save the regex, makes for easier and more correct matching and allows arbitrary transformations with arbitrary regexen without marking everything as not-an-error.

(Currently abbr hahaha --regex '.*' --function false will cause commands to always be marked as valid because the regex matches and it can't know that the function would fail. This is probably correct - I don't think we can run the function before and marking things as invalid even tho they could still match an abbr feels weird?)

Note that this would always be restricted to a command argument - because otherwise the command won't match. I don't think we need to add --position argument or require --position anywhere just for this. I also don't think we'd need to walk a command's wrap chain (i.e. function g; git $argv; end would need to have the abbrs specified again).

[lgarron]

I would also really like to see this.

I have a file with git abbreviations that I use heavily: https://github.com/lgarron/dotfiles/blob/a8c29fc157394e699b49f1fd8d37089475c23d64/dotfiles/fish/.config/fish/git.fish

For example:

abbr -a gcp   "git cherry-pick"
abbr -a gm
abbr -a gr

These can take --continue and --abort commands. So I've also added additional versions:

abbr -a gcpa  "git cherry-pick --abort"
abbr -a gcpc  "git cherry-pick --continue"
abbr -a gma   "git merge --abort"
abbr -a gmc   "git merge --continue"
abbr -a gra   "git rebase --abort"
abbr -a grc   "git rebase --continue"

However, this doesn't feel like a good general solution — it feels like the second dimension of a Cartesian explosion.

I'd love to use something like this:

abbr -a gcp   "git cherry-pick"
abbr -a gm
abbr -a gr

abbr -a con --position anywhere -- --continue
abbr -a ab --position anywhere -- --abort

However, this is risky because:

• I can't pass --position argument, so ab is expanded to --abort even though ab is a binary in my $PATH.
• In general, this is an uncomfortable footgun — these expansions are only limited to a specific subset of git, but they can be accidentally applied even if I meant to input files or strings. con and ab are reasonably likely to be used as file names or codes in computing, while making them any longer would diminish the convenience that this feature is supposed to provide in the first place.

I would be very glad to restrict these expansions to the git command, or ideally to certain subcommands. If the expansion function received the current command text, this might be one way forward, although I acknowledge that this can still produce undesired behaviour if the cursor is in the middle of the command while expanding.

function con_function
  if [ $argv[1] = "git" -a $argv[2] = "rebase" ]
       echo "--continue"
    else
      echo "con"
    end
end

abbr -a con --position anywhere --function con_function

git rebase con[cursor here, press space] # yiss

[krobelus]

you can use abbr --regex

[lgarron]

you can use abbr --regex

Hmm, I don't see how I can?

With --regex, the abbreviation matches using the regular expression given by PATTERN, instead of the literal NAME. The pattern is interpreted using PCRE2 syntax and must match the entire token. If multiple abbreviations match the same token, the last abbreviation added is used.
https://fishshell.com/docs/current/cmds/abbr.html#add-subcommand

[krobelus]

nevermind, I thought that the regex applies to the entire commandline but it doesn't

[faho]

Even if you could match the entire commandline, writing a regex that properly covers all cases is extremely difficult, if it's possible at all.

You need to cover

foo "$(bar | command git 

but not ls git. (we'd only care about syntactic commands here, so sudo git is out of scope - because sudo -D git shouldn't count "git" as a command but sudo -E git should)

If you allow the abbr anywhere you can approximate this, but it's still quite difficult - you need commandline --current-process --tokenize, and then you need to remove all the decorations (time, command, not, and, or) yourself, and when we add more everyone needs to add them to all their abbreviations.

(also if you allow the abbr "anywhere" that always highlights the abbr as a valid command even tho it won't expand - this is more of a case for a "argument" position of course)

[faho]

Note, @lgarron:

If the expansion function received the current command text

The current command text is available via commandline, so you can do

function con_function
  set -l cmd (commandline -op)
  if [ "$cmd[1]" = git -a "$cmd[2]" = rebase ] # <- (quotes on the variables, not the literals)
       echo "--continue"
    else
      echo "con"
    end
end

abbr -a con --position anywhere --function con_function

git rebase con[cursor here, press space] # yiss

Also, you probably want to return 1 instead of printing "con" - this allows other abbreviations to be attempted.

Of course it'll be tricky to handle this:

command git -C /path/to/my/repo rebase con[space]

This issue is about making the "command git" part of that easy, the rest essentially requires something like we do in the git completions with argparse. You need to partially do the command's argument parsing, at least enough to figure out that -C takes an argument and so the /path/to/my/repo isn't the subcommand.

[lgarron]

@faho Thanks, that's very handy. 😻

All those caveats make wish #9412 had landed so I could just do abbr --command git con -- --continue, but your code sample makes me feel comfortable enough about being able to use argument completions in safely scoped situations!

[lgarron]

Also, you probably want to return 1 instead of printing "con" - this allows other abbreviations to be attempted.

Could I ask for help with getting this to work?

This doesn't seem to do the trick:

abbr -a c "code"

set git_reentrant rebase merge cherry-pick
function _complete_continue
    set -l cmd (commandline -op)
    if [ "$cmd[1]" = git ]
        if contains -- "$cmd[2]" git_reentrant
            echo "--continue"
        else
            return 1
        end
    else
        return 1
    end
end
abbr -a c --position anywhere --function _complete_continue

Using abbr -a --position command c "code" doesn't seem to make a difference.

[faho]

Could I ask for help with getting this to work?

This line:

   if contains -- "$cmd[2]" git_reentrant

Is missing a $ - $git_reentrant.

And this line:

set git_reentrant rebase merge cherry-pick

should explicitly specify a scope - set -g.

[lgarron]

Thanks! Sorry, I hadn't finished debugging that part. The bigger problem for me is that this abbreviation does not work, despite your suggested use of return 1 for the other abbreviation.

abbr -a c "code"

Is there something else I'm missing, or any other workaround (other than making _complete_continue a consolidated logic tree with every completion for c that I want under any circumstances)?