Make recursive global abbreviations a bit nicer?

[henrebotha]

I've got something kinda neat going, but it needs just a little bit extra to really be great.

I have the following abbreviations defined.

"a"="apt"
"@a"="apt" (global)
"apt i"="apt install"
"@apt i"="apt install" (global)
"s"="sudo @%"

So on a fresh command line, I can type a i which expands first to apt i then apt install. I can also type s a which expands first to sudo @a then sudo apt. However, I can't type s a i to get sudo apt install, because by the time we've expanded to sudo apt, there's no longer an "@" anywhere in the line, and so the @apt i abbreviation can't match it.

I can work around this in a naive way, by exhaustively creating abbreviations for every combination of apt parameters and sudo; but I am wondering if there's a way to get what I want without going down that road. (I could also just define apt i as a global abbreviation, but I really want to avoid "automatic" global abbreviations messing with me just trying to type normal things (hence my custom of prefixing global abbreviations with "@").)

[olets]

Interesting. This helps me understand your #99

• Mark certain commands to allow expansion of regular abbreviations following them #99

and the fact that it's still a frustration for you makes me want to hack on it.

This reaches me at almost a great time: just wrapped up a side project. But in fact it reaches me at a bad time, because with that side project wrapped I'm determined to not let development side projects eat up discretionary time for a while.

 

If you or someone else wants to take a stab…

Maybe we could have an array of ABBR_PREFIXES (what you proposed calling modifiers — "prefix" to me sounds less like it's going to have some side effect than "modifier" does). ABBR_ABBREVIATION_PREFIXES? Something?

I think the change will be in abbr-expand.

For command abbreviations (now misnamed but oh well!) we'll need to see if the LBUFFER is in the prefix array. For global abbreviations we'll need to see if the LBUFFER ends in something in the prefix array.

👀 Might be able to modify what's currently the while (( i < ${#words} )) loop? (That the core of the multi-word abbreviation lookup: it works its way back along the LBUFFER's words looking for matches.) That could be nice conceptually, and so good for maintainability — "prefixes are words stuck onto the front of abbreviations, but do it for me".

If that doesn't pan out, the regex-| joining in the zsh-syntax-highlighting snippets might point towards a useful pattern. (Or even if it does pan out? Maybe there's even a way to eliminate the existing while (( i < ${#words} )) loop. I've never noticed a performance problem, but that bit of the multi-word support has risk of being slow. But! That's outside the scope of this feature's MVP)

[olets]

Ha ok!

Give the branch regular-abbreviation-prefixes a try.

Session abbreviations are supported. Regular abbreviation prefixes don't have to be followed by a space (and any trailing space must be made explicit), and they can have quotation marks in them.

By default, there's one regular abbreviation prefix: 'sudo ', to support sudo <any abbreviation>.

Configure regular abbreviation prefixes with ABBR_REGULAR_ABBREVIATION_PREFIXES.

Can add to the default

# .zshrc

ABBR_REGULAR_ABBREVIATION_PREFIXES+=( 'watch ' 'which ' )
# ABBR_REGULAR_ABBREVIATION_PREFIXES is `( 'sudo ' 'watch ' 'which ' )`

or override it

# .zshrc

ABBR_REGULAR_ABBREVIATION_PREFIXES=( 'watch ' 'which ' )
# ABBR_REGULAR_ABBREVIATION_PREFIXES is `( 'watch ' 'which ' )`

# also
ABBR_REGULAR_ABBREVIATION_PREFIXES+=( ' ' ) # regular abbreviations will play nice with zsh's `hist_ignore_space`!
ABBR_REGULAR_ABBREVIATION_PREFIXES+=( 'nospace' )
ABBR_REGULAR_ABBREVIATION_PREFIXES+=( '"double quotation marks" ' )
ABBR_REGULAR_ABBREVIATION_PREFIXES+=( "'single quotation marks' " )

[henrebotha]

Works great so far. I'll keep trying it out.

Side note: noglob is another nice one to use like this.

[olets]

Speaking of globs, this has me thinking it'd be nice to support globbing.

is there a way to get zsh-abbr to work with arbitrarystring.l.a and expand the ‘l.a’ with NO SPACE before it

— https://mastodon.sdf.org/@jbsegal/112456662665099604

Maybe a separate array

ABBR_REGULAR_ABBREVIATION_GLOB_PREFIXES=( [:digit:] )

or maybe with a marker

ABBR_REGULAR_ABBREVIATION_PREFIX_GLOB_MARKER=%TREAT_AS_GLOB%
ABBR_REGULAR_ABBREVIATION_PREFIXES=( ${ABBR_REGULAR_ABBREVIATION_PREFIX_GLOB_MARKER}[:digit:] )

Leaning towards the former. Will explore…

[olets]

Also would be nice to support stringing prefixes together. prefix1 prefix2 abbreviation -> prefix1 prefix2 expansion. Possible that's as small as adding a recursive call. If so, could be part of an initial release.

Here's hoping to not think of any more enhancements to this 😆

[olets]

Branch prefixes/prefixes has literal regular abbreviation prefixes in the array ABBR_REGULAR_ABBREVIATION_SCALAR_PREFIXES, glob regular abbreviation prefixes in the array ABBR_REGULAR_ABBREVIATION_GLOB_PREFIXES, and support for stringing prefixes together (% prefix1prefix2prefix3abbreviation[SPACE]).

The feature is in beta. Its tests are passing, but there may be bugs, and I'm not putting it in a zsh-abbr beta release yet.

The branch may be force-pushed in the future.

[mainrs]

Just to see if I understand this feature correctly. It seems most useful for nested abbreviations. Like gc = git commit, gca=git commit --amend. And one could be able to type gc to get git commit and then a single a to turn it into git commit --amend. It basically works like abbreviations with contexts, is that right?

[olets]

You could use a prefix for that. But I'd recommend a multi-word abbreviation.

Prefixes are shared across all abbreviations. In the current beta API, a prefixed-based solution to your example would be

# .zshrc
ABBR_REGULAR_ABBREVIATION_PREFIXES+=( 'git commit ' )

abbr gc="git commit"
abbr a="--amend"

Then you'd be able to

% gc[SPACE]a[ENTER] # expands to `git commit --amend`, and runs

but you'd also be able to

% a[SPACE] # expands to `--amend`
% sudo a[SPACE] # expands to `sudo --amend`

and

% abbr x=[something…]
% git commit x[SPACE] # expands to `git commit [the expansion of x]`

which might be okay, but might be more powerful than you want.

Compare to a multi-word abbreviation solution, which is already supported (abbr add docs)

# .zshrc
# no change to ABBR_REGULAR_ABBREVIATION_PREFIXES

% abbr -g gc="git commit"
% abbr -g "git commit a"="git commit --amend" # <-- multi-word abbreviation
% gc[SPACE]a[ENTER] # expands to `git commit --amend`, and runs
% foo bar gc[SPACE]a[ENTER] # expands to `foo bar git commit --amend`, and runs

//

I personally would do something like

# .zshrc
# no change to ABBR_REGULAR_ABBREVIATION_PREFIXES

% abbr git a="commit --amend" # `a`, `git a`, `foo bar git a` *
% abbr -g ga="git commit --amend" # `ga`, `foo bar ga`
% abbr -g "git commit a"="git commit --amend" # `git commit a`, `foo bar git commit a`
% abbr git c="commit" # `c[SPACE]a`, `git c[SPACE]a`, `foo bar git c[SPACE]a`
% abbr -g gc="git commit" # `gc[SPACE]a`, `foo bar gc[SPACE]a`
% abbr -g g=git # `g[SPACE]a`, `foo bar g[SPACE]a`, `g[SPACE]commit a`, `g[SPACE]c[SPACE]a`, `foo bar g[SPACE]commit a`, `foo bar g[SPACE]c[SPACE]a`

* abbr git a=bcd is a shorthand for abbr a="git bcd" && abbr -g "git a"="git bcd" (abbr git docs)

[mainrs]

% abbr -g gc="git commit"
% abbr -g "git commit a"="git commit --amend" # <-- multi-word abbreviation
% gc[SPACE]a[ENTER] # expands to `git commit --amend`, and runs
% foo bar gc[SPACE]a[ENTER] # expands to `foo bar git commit --amend`, and runs

This seems like it is harder to create position independent abbreviations. Let's stick with the git example:

% abbr -g gc="git commit"
% abbr -g "git commit a"="git commit --amend"
% abbr -g "git commit ra"="git commit --reset-authors"
% abbr -g "git commit <both?>"="git commit --amend --reset-authors"

Basically I need to add n(n-1)/2 abbreviations for n flags. Solution 1 would work in this case. But I'd rather not have the flag abbreviations globally available. I often do typos :(