[limitation] ​global abbreviations do not support leading and/or trailing whitespace

[5A6F65]

Is there an existing issue for this?

• I have searched the existing issues

Update the issue title

• I have updated the title

Expected Behavior

​Global abbr with space prefixes should indeed expand, as user abbr with space prefixes expand correctly; their behaviors ought to be consistent.​
I'm unsure whether this is a bug or the intended behavior. However, since I'm working on supporting f-sy-h highlighting of multi-word abbreviations, this behavior directly affects how I should handle global abbreviations. Therefore, I've opened an issue to inquire about this matter.
If it's determined to be a bug, I may attempt to open a pr to fix it after completing my current work.

Actual Behavior

​Global abbr with space prefixes cannot be expanded.

Steps To Reproduce

abbr 'test0'='Test0'
abbr ' test1'='Test1'
abbr -g 'test2'='Test2'
abbr -g ' test3'='Test3'

test0[Space]     # expands to `Test0`
 test0[Space]    # expands to ` Test0`
test1[Space]     # does not expand
 test1[Space]    # expands to `Test1`
test2[Space]     # expands to `Test2`
 test2[Space]    # expands to ` Test2`
test3[Space]     # does not expand
 test3[Space]    # does not expand, but should expand to `Test3`

test && test0[Space]     # does not expand
test &&  test0[Space]    # does not expand
test && test1[Space]     # does not expand
test &&  test1[Space]    # does not expand
test && test2[Space]     # expands to `test && Test2`
test &&  test2[Space]    # expands to `test &&  Test2`
test && test3[Space]     # does not expand
test &&  test3[Space]    # does not expand, but should expand to `test && Test3`

Environment

zsh-abbr version 6.2.1
zsh 5.8.1 (x86_64-ubuntu-linux-gnu)
OSTYPE linux-gnu

Installation method

Plugin manager

Installation method details

zdharma-continuum/zinit v3.14.0

Anything else?

No response

[5A6F65]

In fact, user and global abbr behave inconsistently when there are space suffixes.

Would it be a better idea to prohibit abbreviations from having space prefixes and suffixes? I can't think of any situation where using space prefixes or suffixes in abbreviations is necessary. If we were to support space prefixes and suffixes, parsing global abbreviations would become a rather challenging task.
Moreover, in zsh, aliases do not support space prefixes or suffixes.
I believe aligning the behavior of abbreviations with that of aliases is a good idea.

Additionally, when pressing enter, only global abbreviations located before the cursor are expanded. This behavior is inconsistent with how zsh handles global aliases. May I ask if this is by design?

[olets]

Thanks for the questions.

Making sure I understand the original report. Is the following the minimal scenario, or does it miss something?

% abbr ' space-prefixed-regular'=a
% abbr -g ' space-prefixed-global'=b
%  space-prefixed-regular[space] # note the space prefix. expands to `a`
%  space-prefixed-global[space] # note the space prefix. does not expand to `b`. bug?

 

//

 

Would it be a better idea to prohibit abbreviations from having space prefixes and suffixes? I can't think of any situation where using space prefixes or suffixes in abbreviations is necessary.

I hadn't before considered abbreviations which start with a space, and off the top of my head I'm not sure how much work it would take. I don't think prohibition is necessary. This issue and a flag in the docs would be sufficient. In five years of zsh-abbr, this is the first time I've heard of someone wanting to start an abbreviation with a space, and apparently even you don't need it 😄 Still, interesting question, worth thinking about supporting abbreviations with start with a space.

 

//

 

In fact, user and global abbr behave inconsistently when there are space suffixes.

Do you mean regular and global? Or maybe user and session? Say more about the inconsistent behavior. Maybe you're getting tripped up by some effect of the ABBR_REGULAR_ABBREVIATION_GLOB_PREFIXES default ( ' ' )?

 

//

 

Additionally, when pressing enter, only global abbreviations located before the cursor are expanded. This behavior is inconsistent with how zsh handles global aliases. May I ask if this is by design?

Are you talking about something like this?

% abbr a=b
% abbr -g c=d
% a[ctrl space]c[enter] # expands to and runs `a d`, not `b d`

If so, yes that's by design, and moreover a fundamental part of the both the UX and code. Your asking makes me wonder whether there'd be value in supporting suffixes, similar to prefixes (docs). Will think about that. Can imagine something like a glob suffix ?., and expanding c to d with a first space and then expanding a to b on a second space or on enter. (But I have a bunch of other things going on right now, and don't know when I'll get to thinking it through, let alone implementing it if I decide I like it.)

[5A6F65]

The answers to these questions directly impact the ideal highlighting behavior for abbreviations, which is why I’ve brought up so many details.
Thank you for taking the time to clarify them!

---

Making sure I understand the original report. Is the following the minimal scenario, or does it miss something?

% abbr ' space-prefixed-regular'=a
% abbr -g ' space-prefixed-global'=b
% space-prefixed-regular[space] # note the space prefix. expands to a
% space-prefixed-global[space] # note the space prefix. does not expand to b. bug?

Yes, your understanding is completely correct. We can test those four commands directly in the terminal, and I get the same results as you described.
In the abbr‑expand function, because it splits LBUFFER with words=( ${(z)LBUFFER} ), the word used to match global abbreviations never includes any space prefixes or suffixes, whereas user abbreviations aren’t parsed in this way for BUFFER. Hence the behavioral difference.

---

Would it be a better idea to prohibit abbreviations from having space prefixes and suffixes? I can't think of any situation where using space prefixes or suffixes in abbreviations is necessary.

I hadn't before considered abbreviations which start with a space, and off the top of my head I'm not sure how much work it would take. I don't think prohibition is necessary. This issue and a flag in the docs would be sufficient. In five years of zsh-abbr, this is the first time I've heard of someone wanting to start an abbreviation with a space, and apparently even you don't need it 😄 Still, interesting question, worth thinking about supporting abbreviations with start with a space.

Regarding effort: we should only need to improve the parsing flow for global abbreviations. It’s somewhat tricky, but I believe it’s doable.
However, if this isn’t a short‑term goal, perhaps I should first implement highlighting based on the current parsing logic?

---

In fact, user and global abbr behave inconsistently when there are space suffixes.

Do you mean regular and global? Or maybe user and session? Say more about the inconsistent behavior. Maybe you're getting tripped up by some effect of the ABBR_REGULAR_ABBREVIATION_GLOB_PREFIXES default ( ' ' )?

I’ve already explained the reason for this discrepancy in detail above, so I won’t repeat it here.

---

Additionally, when pressing enter, only global abbreviations located before the cursor are expanded. This behavior is inconsistent with how zsh handles global aliases. May I ask if this is by design?

Are you talking about something like this?

% abbr a=b
% abbr -g c=d
% a[ctrl space]c[enter] # expands to and runs a d, not b d
If so, yes that's by design, and moreover a fundamental part of the both the UX and code.

No, I’m referring to a different issue:
When reading the zsh‑abbr source code, we can find the following parsing method in the abbr‑expand function:

words=( ${(z)LBUFFER} )
# first check the full LBUFFER, then trim words off the front
while [[ -z $expansion ]] && (( i < ${#words} )); do
  abbreviation=${words:$i}
  expansion=$(_abbr_global_expansion "$abbreviation" 1)
  (( i++ ))
done

In fact, this code only ever checks whether the last word in LBUFFER is a global abbreviation. We can easily verify this:

word='g1 g2'
words=( ${(z)word} )
print ${words:0}    # print 'g1 g2'
print ${words:1}    # print 'g2'

If the goal is merely to inspect the final word, this entire loop is unnecessary.

As you mentioned, this behavior seems more akin to suffix handling rather than global abbreviation expansion, so I’m inclined to consider it a bug.
I guess the intended behavior was to check g1 first, then g2. To achieve that, we should use ${words:$i:1} instead of ${words:$i}.
Moreover, even with that fix, the code would still only ever expand the first matching global abbreviation—it would need further adjustments to handle multiple matches correctly.

If this behavior is indeed by design, then the code could be made more efficient.
We could simply attempt to expand ${words:${#words}-1:1} rather than iterating unnecessarily.
And that's the suffix, isn't it?

---

Your asking makes me wonder whether there'd be value in supporting suffixes, similar to prefixes (docs). Will think about that. Can imagine something like a glob suffix ?., and expanding c to d with a first space and then expanding a to b on a second space or on enter. (But I have a bunch of other things going on right now, and don't know when I'll get to thinking it through, let alone implementing it if I decide I like it.)

Sounds good, maybe it can be enhanced in the future.

[olets]

Got it, the bug is leading and trailing whitespace isn't supported in global abbreviations. Thanks for the report!

# leading
abbr -g  -S ' a'=b
 a[space] # expected: ` b `. actual: ` a `
x a[space] # expected: `x b `. actual: `x a `

# trailing
abbr -g -S 'c '=d
c[space][space] # expected: `d `. actual: `c  `
x c[space][space] # expected: `x d `. actual: `x c  `

# both
abbr -g -S ' e '=f
 e[space][space] # expected: ` f `. actual: ` e  `
x  e[space][space] # expected: `x  f `. actual: `x  e  `

Compare to regular abbreviations:

# to prevent any misleading results
ABBR_REGULAR_ABBREVIATION_GLOB_PREFIXES=( )

# leading
abbr -S ' g'=h
 g[space] # ` h `

# trailing
abbr -S 'i '=j
i[space][space] # `j `

# both
abbr -S ' k '=l
 k[space][space] # `l `

(responses to the side conversations are in the next comment)

[olets]

(bug is discussed in previous comment, responses to the side conversations are in this one)

perhaps I should first implement highlighting based on the current parsing logic

I think that's the right way to go. Excited for what you come up with!

 

//

 

In fact, user and global abbr behave inconsistently when there are space suffixes.

Do you mean regular and global? Or maybe user and session? Say more about the inconsistent behavior. Maybe you're getting tripped up by some effect of the ABBR_REGULAR_ABBREVIATION_GLOB_PREFIXES default ( ' ' )?

I’ve already explained the reason for this discrepancy in detail above, so I won’t repeat it here.

Gotcha, I thought you were flagging some additional possible bug.

 

//

 

In fact, this code only ever checks whether the last word in LBUFFER is a global abbreviation.

That's incorrect. This iterating work checks whether the full LBUFFER is a global abbreviation, then trims off the first word and checks whether that string is a global abbreviation, and so on until the last word. Starting with more words than in your example makes the effect clearer. Running

typeset -i i
# i === 0
words=( a b c d )
while (( i < ${#words} )); do echo ${words:i}; (( i++ )); done

outputs

a b c d
b c d
c d
d

only ever expand the first matching global abbreviation

Yes, only one abbreviation per expansion event, so there's no need to continue looking for matches after one is found.

 

//

 

And that's the suffix, isn't it?

The suffix support our conversation got me thinking about would make something like this possible

scalar_suffixes=( x )
abbr a=b
ax[space] # `bx `