FWIW, The edit:small-word-abbr behavior is based on, but not identical to, the Fish shell abbr behavior. It was a compromise between myself and the Elvish project owner; especially with regard to not treating pressing Enter the same as Space. Having said that, it does seem like the expansion should only occur if the prefix is whitespace (or start of line); not just the definition of a "small word". That would fix another annoyance I experience with this abbreviation:

set edit:small-word-abbr['l'] = 'less'

If I type ls -l then press Space the l is converted to less which is incredibly annoying and not how Fish handles that situation. I've just been living with that unwanted behavior. It's probably long past time to fix it.

expansion should only occur if the prefix is whitespace (or start of line)

I thought it was what edit:small-word-abbr intended to achieve (which was not with edit:abbr),

Fish abbr seems to expand only at "start of command" and it is quite nice. (Haven't looked at implementation details yet)

1, 3 expands 2 not.

If I type ls -l then press Space the l is converted to less which is incredibly annoying and not how Fish handles that situation. I've just been living with that unwanted behavior. It's probably long past time to fix it.

+1

Can we at least make it a configuration option? I wouldn't mind trying my hands at a PR if the solution would be accepted.

From my comment in issue #1540 for anyone who stumbles upon this issue and wants to look at the implementation to understand why small word abbreviations behave like they do:

expanded upon typing a trigger character, which is currently a space or semicolon

Close, but not correct. See the implementation, but the short answer is that the trigger char simply has to be in a different category than the last character of the abbreviation; see the definition of CategorizeSmallWord. Consider this abbreviation: set edit:small-word-abbr['l'] = 'less'. If you type echo -l- the ell will be expanded to less because l is an alphanum and - is not.

I'm coming over from #1540, which does not seem like a great idea upon seeing the implementation (thanks @krader1961).

I see two potential changes/features in this thread:

If I type ls -l then press Space the l is converted to less which is incredibly annoying

Fish abbr seems to expand only at "start of command" and it is quite nice

As I see it there are really 3 options for a "fix":

1. Introduce configuration options somewhere under $edit:... that allow these two behaviours.
2. Change the behaviour of small-word abbreviations.
3. Add a third type of abbreviation that behaves this way.

Option 3 in interesting as simple abbreviations and small-word abbreviations have a behaviour that is orthogonal to what we are describing here, which are really abbreviations that behave the same way as Fish abbreviations. We likely do not want 3 different kinds of abbreviations, so that may not be the best solution. I also agree with the following, which is a solution more like option 2:

If I type ls -l then press Space the l is converted to less which is incredibly annoying and not how Fish handles that situation. I've just been living with that unwanted behavior. It's probably long past time to fix it.

Is the intention of small-word abbreviations not to handle abbreviations in the same way as Fish? What is a use case for how Elvish handles small-word abbreviations where they are expanded like this?

Is the intention of small-word abbreviations not to handle abbreviations in the same way as Fish?

No, it was meant to be more flexible by allowing expansion anywhere on the command line subject to the "small word" matching restriction. In contrast to the "simple" expansions created by edit:abbr which expand regardless of the preceding char and has no trigger char. The question is whether that flexibility is actually desirable.

Looking at my abbreviations I have only two "simple" abbreviations:

set edit:abbr['>dn'] = ' 2>/dev/null'
set edit:abbr['||'] = ' | less'

I have twenty small word abbreviations and every single one is only meant to be expanded in the command position; i.e., the Fish behavior. Which is why I'm sometimes annoyed when the expansion occurs at some other position of the command line.

I'm in favor of adding a third type of abbreviation that is only expanded in the command position; ala Fish. Perhaps named edit:command-abbr. There's probably no reason to remove the existing edit:small-word-abbr var even if, as I suspect, it would seldom be used given that most people would use edit:abbr or edit:command-abbr. Since we've already paid the cost of implementing small word abbreviations we might as well keep it just in case someone finds it useful.