Repository navigation
Abbreviation "ap" about using the append command #17893
Description
Steps to reproduce
When a user-defined command starts with "ap" (e.g., ":apple"), Vim incorrectly interprets "ap" as an abbreviation for the "append" command inside a function body, producing a confusing error message. This behavior is inconsistent with how other commands that violate the "must start with an uppercase letter" rule are handled.
For example, consider two scenarios:
- Define a user command ":apple" in "apple.vim". When called inside a function, Vim throws a misleading error that confuses developers and makes debugging difficult.
- Define a user command ":peer" in "peer.vim". When called inside a function, Vim correctly reports that user-defined command names must start with an uppercase letter.
Root Cause Analysis:
The issue appears to stem from the "get_function_body()" function in "src/userfunc.c". Specifically, this line of code seems to be the cause:
“if (!vim9_function && ((p[0] == 'a' && (!ASCII_ISALPHA(p[1]) || p[1] == 'p'))“
This check, combined with the logic for
"vim9_function" ("int vim9_function = eap->cmdidx == CMD_def || eap->cmdidx == CMD_block;")
incorrectly identifies any command starting with "ap" as the "append" command within a legacy function body.
Expected behaviour
I would like to suggest adding a new option to disable this specific abbreviation parsing within functions.For example, a new option "set parsecommand" ,The check in "src/userfunc.c" could then be modified to respect this option:
"if (!vim9_function && !p_pcmd && ((p[0] == 'a' && (!ASCII_ISALPHA(p[1]) || p[1] == 'p')) "
Please see the screenshot below for a illustration:
Version of Vim
Vim Versions: All versions from 8.x to 9.x.
Environment
All operating systems.
Activity
habamax commentedon Aug 1, 2025
There is probably a better way to handle the issue other than creating a new
parsecommandoption.habamax commentedon Aug 1, 2025
The error is misleading here, indeed (
E1145):If you do the same in vim9script, it is better but still, I would expect
E183and thenE476:dkearns commentedon Aug 1, 2025
Thanks for the report. Your proposed solution seems rather outlandish. If it was generated by an LLM it would be a good idea to add that to the report.
I only skimmed the code but I suspect we can get away with using
checkforcmd()there to more accurately check for:appendand friends.h-east commentedon Aug 3, 2025
@habamax
In the case of the
deffunction in Vim9 script, this is expected because there are "side effects of compiling a function."See
:h vim9-user-commandh-east commentedon Aug 3, 2025
@dkearns You are self-assigning. Is that intended?
For now, I'll leave the patch here.--> It was a useless patch so I deleted it.dkearns commentedon Aug 3, 2025
Yes, I have a fix for this. Thanks.
dai475694450 commentedon Aug 6, 2025
@dkearns @h-east
That's great to hear. Thank you for looking into this and proposing a solution. Appreciate you taking this on!
h-east commentedon Aug 8, 2025
@dkearns Sorry. I submitted a pull request first.
Could you please review it?
If you don't like it, you can close my PR and submit your own.
patch 9.1.1607: :apple command detected as :append
vim-patch:9.1.1607: :apple command detected as :append
vim-patch:9.1.1607: :apple command detected as :append (#35237)
vim-patch:9.1.1607: :apple command detected as :append (#35237)
vim-patch:9.1.1607: :apple command detected as :append (#35237)
vim-patch:9.1.1607: :apple command detected as :append (neovim#35237)
patch 9.1.1607: :apple command detected as :append
vim-patch:9.1.1607: :apple command detected as :append (neovim#35237)
Args and tail comments break text-input command parsing in functions