Adding <silent> to a working cnoremap <expr> causes remapping to break

[craigmac]

Steps to reproduce

1. vim --clean
2. :cnoremap <silent><expr> <C-p> wildmenumode() ? '<C-p>' : '<Up>'
3. :cnoremap <silent><expr> <C-n> wildmenumode() ? '<C-n>': '<Down>'
4. :edit <Tab>
5. Move around with <C-n/p> and see the command-line string grow with added ... (periods).

Expected behaviour

Adding <silent> shouldn't do this. If you try the mappings without it:

:cnoremap <expr> <C-p> wildmenumode() ? '<C-p>' : '<Up>'
:cnoremap <expr> <C-n> wildmenumode() ? '<C-n>': '<Down>'

No periods are appended to the command-line string.

Version of Vim

9.0.0049

Environment

macOS 12.6.1
Alacritty latest
$TERM is 'alacritty'

Logs and stack traces

No response

[brammool]

### Steps to reproduce 1. `vim --clean` 2. `:cnoremap <silent><expr> <C-p> wildmenumode() ? '<C-p>' : '<Up>'` 3. `:cnoremap <silent><expr> <C-n> wildmenumode() ? '<C-n>': '<Down>'` 4. `:edit <Tab>` 5. Move around with `<C-n/p>` and see the command-line string grow with added `...` (periods). ### Expected behaviour Adding `<silent>` shouldn't do this. If you try the mappings without it: ```vim :cnoremap <expr> <C-p> wildmenumode() ? '<C-p>' : '<Up>' :cnoremap <expr> <C-n> wildmenumode() ? '<C-n>': '<Down>' ``` No periods are appended to the command-line string.

I think the periods are the result of showing that the completion is pending. Normally they are cleared later, but the <silent> apparently prevents that (blocks updating the command line). So then why do you add <silent>? Why not just leave it out?

…

-- Giving a commit hash to refer to a patch is like giving longitude and lattitude to refer to a city. /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[craigmac]

Yeah, I've just left it out as a workaround, just wanted to report the unexpected behaviour, in case it's an easy fix.

[zeertzjq]

Why is this unexpected? Isn't this exactly what <silent> is intended to do?

[craigmac]

My docs say:

					                             *:map-<silent>* *:map-silent*
To define a mapping which will not be echoed on the command line, add
"<silent>" as the first argument.  Example: >
	:map <silent> ,h /Header<CR>
The search string will not be echoed when using this mapping. 

I interpreted that to apply to my mapping above as well, so maybe the docs should make a note that it doesn't always apply, and that it is possible a mapping triggers a 'completion pending' state, which will append '...' to the command-line, regardless of the <silent>

[brammool]

That the dots show up is because this happens to only check the msg_silent flag, but in this case the cmd_silent flag is set.
I can also check the cmd_silent flag, with the results that the dots are not displayed.

However, this doesn't make it work: Since your command to move up/down in the list of matches has "silent" applied, the command line won't be updated. Thus the "silent" does not only apply to evaluating the expression, it also applies to where the result of the expression (the CTRL-P or key) is used.

What you probably want is that the redraw of the command line is not suppressed. If I reset cmd_silent before calling redrawcmd() then the dots are also cleared. But that's just for this specific case. Normally cmd_silent is cleared when getting the next character, not while still working on the previous one. Or someway halfway working on the previous one.
And then there is the possibility that this wasn't the last character of the mapping, it really was intended to be done silently, and perhaps another one is following.

So, I don't really know how to make a change that fixes this without breaking something else. I'll see if adding something to the help makes it clearer.

[craigmac]

Well that was quick, thank you very much!