[vim/vim] fullcommand({name}, true) returns incorrect result for five commands (EX_WHOLE missing from them in ex_cmds.h) (Issue #20032)

2 views
Skip to first unread message

Peter Kenny

unread,
Apr 21, 2026, 4:08:14 PM (10 days ago) Apr 21
to vim/vim, Subscribed
kennypete created an issue (vim/vim#20032)

fullcommand({name}, true) will return the full commands for endclass, endenum, endinterface, public, and static. All these should return "...an empty string if [it] cannot be shortened this way." (builtin.txt)

To illustrate:

image.png (view on web)

As this shows, enu and inter cannot be used as shortened forms of enum and interface in Vim9 script - they return empty string, which is correct. However, the others, endc, ende, endin, pub, stat misleadingly are shown as valid shortenings of endclass, endenum, endinterface, public, and static respectively. That's not right: all those commands give E1065 if you attempt to use shortened forms. E.g.:

image.png (view on web)

It appears the cause is EX_WHOLE missing from the related entries in ex_cmds.h, which says, #define EX_WHOLE 0x10000000 // command name cannot be shortened in Vim9. E.g., here is endinterface:

EXCMD(CMD_endinterface,	"endinterface",	ex_wrongmodifier,
	EX_EXTRA|EX_TRLBAR|EX_CMDWIN|EX_LOCK_OK,
	ADDR_NONE),

...which should have |EX_WHOLE added after EX_LOCK_OK, like it is for the other commands that give E1065 when shortened, like interface:

EXCMD(CMD_interface,	"interface",	ex_class,
	EX_EXTRA|EX_CMDWIN|EX_LOCK_OK|EX_WHOLE|EX_EXPORT,
	ADDR_NONE),

I'm not sure whether this is the only place needing changes so I'm raising this as an issue rather than just making a PR for ex_cmds.h only.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20032@github.com>

Christian Brabandt

unread,
Apr 30, 2026, 7:32:13 AM (yesterday) Apr 30
to vim/vim, Subscribed
chrisbra left a comment (vim/vim#20032)

I think this is the right thing to do. Can you create a PR for this?


Reply to this email directly, view it on GitHub, or unsubscribe.

Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20032/4352084482@github.com>

Peter Kenny

unread,
Apr 30, 2026, 5:33:12 PM (20 hours ago) Apr 30
to vim/vim, Subscribed
kennypete left a comment (vim/vim#20032)

I think this is the right thing to do. Can you create a PR for this?

Yes, I am doing that, literally as I type. It is quite significant as it also applies to runtime/syntax/generator/vim.vim.base, runtime/syntax/generator/gen_syntax_vim.vim, src/testdir/test_vim9_class.vim, src/testdir/test_vim9_script.vim, and some incidental corrections to doc/repeat.txt, doc/userfunc.txt, and eval.txt. Hopefully not too far away - it's going to be a big improvement as the "WHOLE" treatment has several issues, which I expect will all be resolved. And this was a sidetrack from vim9.txt - I only came across these issues when fullcommand() was returning misleading info, and that led me down the 'fix it' rabbit hole - nearly there though!


Reply to this email directly, view it on GitHub, or unsubscribe.

Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20032/4356298171@github.com>

Reply all
Reply to author
Forward
0 new messages