[vim/vim] Adding <silent> to a working cnoremap <expr> causes remapping to break (Issue #11501)
C.D. MacEachern
Steps to reproduce
vim --clean:cnoremap <silent><expr> <C-p> wildmenumode() ? '<C-p>' : '<Up>':cnoremap <silent><expr> <C-n> wildmenumode() ? '<C-n>': '<Down>':edit <Tab>- 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
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> ### 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.
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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
C.D. MacEachern
Yeah, I've just left it out as a workaround, just wanted to report the unexpected behaviour, in case it's an easy fix.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
Why is this unexpected? Isn't this exactly what <silent> is intended to do?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
C.D. MacEachern
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>
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
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.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #11501 as completed via 698a00f.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
C.D. MacEachern
Well that was quick, thank you very much!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.