expand regular abbreviations in command position anywhere in a line

[Tuncay]

I am using zsh-abbr for a while now and have an issue. And I just updated it from git directly; also zsh --version: "zsh 5.8 (x86_64-pc-linux-gnu)".

For me the abbreviations won't triggered or expanded after a pipe |. Like in this case: x expands to chmod +x, but chmod +x | x does not. This can be solved with a global option -g. The only problem is, that the abbr is really global and will even get triggered as an argument, like there: grep x file to grep chmod +x file. I would like to have an option that is less global and only affects as a command name, even after a pipe.

[Henry Bley-Vroman]

Thanks for submitting the idea @thingsiplay! It makes sense. That's how zsh aliases work

% alias hello="echo world"
% echo hello; hello
hello
world

and how fish abbreviations work

> abbr --add w="echo world"
> echo hello; w
hello
world

I'll consider it but I'm not sure if it will be feasible. A naive version would use command abbreviations at the start of the line, and after at least &&, ||, ;, |, [, and [[; and test when that follows or word boundary or one of the delimiters I just listed. But there are probably important edge cases that would take truly parsing the command, and that's not in this project's scope.

I don't plan to start new abbr features soon. (I am getting close to launching some abbr updates though!) In the meantime you can create a global abbreviation and opt out of using it in certain circumstances

% abbr -g x="chmod +x"
% grep chmod +x[ctrl space] file

or choose an abbreviation that doesn't conflict with things you type:

% abbr -g cx="chmod +x"

[Tuncay]

"I thought it wouldn't be easy, but better report than not to. I didn't know about the manual opt out, but this is still not the solution with a lot of abbreviations. Because I would need to make them all global in order to be able to use in pipes, at least those that make sense.

Another idea would be to act the shortcut "[ctrl space]" as opposite if global option is not set. Meaning it would force to expand, if I manually do "[ctrl space]".

[Henry Bley-Vroman]

"[ctrl space]" as opposite if global option is not set

Interesting idea. That would not be as hard as parsing for command beginnings. I'll consider it. But I'm leaning towards not adding it— feels like a niche need that can be avoided with careful abbreviation naming. I'll leave this open though.

[Tuncay]

Thanks for considering it, it's just an idea and I get why you won't add or change every niche idea. But in my personal opinion (I speak for myself) don't see this as such niche problem. This plugin itself is relatively niche, so you won't get too many reports on that. Maybe people are not aware that it's a problem, if they use the -g option and the command gets triggered at any point in the arguments. The first time it happened to me, I had weird results and didn't notice the expansion at all! It is not the pipe only, also when using && or ; in example are affected.

Careful naming won't change the problem, it will make it less likely to happen. But if I start making complex names, then the abbreviations lose their meaning. There is already a system how I name my abbreviations. My best workaround to ignore abbr when using global option currently is to put the arguments into quotation marks.

[Henry Bley-Vroman]

I don't plan to work on this (wontfix) but I'll consider contributions (help wanted).

I imagine it would entail adding (or perhaps splitting abbr-expand-and-space into) abbr-expand-command-and-space and abbr-expand-global-and-space

Anyone intending to take this on: please discuss here first.

If you'd like to see this feature, give the original comment a 👍