Can't suppress abbr expansion when executing command with no args

[lilyball]

Version: fish, version 3.3.1

I have an abbreviation abbr -a -g -- ls exa. If I want to run e.g. ls -a by itself, I can press Ctrl+Space to insert a space without expanding the abbreviation. Unfortunately there's no equivalent for "execute without expanding abbreviation". Even adding the space (e.g ls ) still expands it when I execute.

I'm also not sure if it's even possible for me to write my own binding here. The binding for \r is just execute, which implies that execution implicitly expands abbreviations (whereas if it were expand-abbr execute then I could have a binding to execute that skips the abbreviations).

[faho]

Tbh I don't think execute should expand the abbreviations, and I think the binding shouldn't do it by default either.

I kept that when I introduced expand-abbr because it was hardcoded on space and \r before, and I didn't want to change the behavior as part of that.

(also it shouldn't be expanded if there's a space after - the idea was that you could press ctrl-space to insert a space and then do whatever, but I see that still triggers the expansion)

[lilyball]

The default \r binding definitely should expand abbreviations, otherwise ls<return> and ls<space><return> would do different things and that would be very confusing. Also it breaks the notion of "abbreviations are for changing how interactive input is interpreted, without changing behavior from scripts or hiding this change in behavior from the log as aliases do".

Anyone who wants return to not expand can then rebind it. I just wish we could do Ctrl-Return to execute without expanding, but return is already \cM so that doesn't work.

[faho]

With ls<return> what is shown in the commandline and what is executed differ. That's also confusing.

If e.g. you made "ls" an abbreviation for "exa", with ls<space> you would see it change to "exa" before you execute it, with ls<return> you wouldn't - it would look like you're executing "ls".

This breaks the notion that abbreviations change what is written in the commandline and, unlike aliases, allow you to change and inspect it before execution.

An alternative is to not execute if an abbreviation expands, so ls<return> would turn into ls --color=auto and a second return would execute it.

This would be bound like bind \r expand-abbr or execute.

[lilyball]

100% of my usage of abbr expects foo<return> to expand the abbreviation. Yes, it does mean that what I typed and what gets executed is different, but I can see that it expanded when looking at the output. And hopefully I know my own abbreviations too, so I know what to expect!

If we change the \r binding to be expand-abbr execute then users who want different behavior certainly can rebind it to e.g. expand-abbr or execute. But please let's not break the current behavior of abbreviations.

[faho]

100% of my usage of abbr expects foo to expand the abbreviation

I on the other hand have been surprised and annoyed by this.

If we change the \r binding to be expand-abbr execute then users who want different behavior certainly can rebind it to e.g. expand-abbr or execute. But please let's not break the current behavior of abbreviations.

And if we don't, anyone who wants this behavior can add the expand-abbr. Or press space.

[faho]

How about we do the uncoupling first and then discuss whether to change the default separately?

[floam]

I agree that abbreviation<ENTER> should transform and execute.

[zanchey]

100% of my usage of abbr expects foo<return> to expand the abbreviation.

Likewise.

[faho]

Okay, let's keep it then. Guess I have some customization to do!

[krobelus]

I made it so we don't expand if there is a space, I think that makes sense?

I got a very spooky CI failure with asan, adding more sleeps helped..