Hmm. This is interesting. Here's what get saved as the command (:com Test0
):
nnoremap <NL> :echom "c-j"<CR>
(<C-J>
is equivalent to <NL>
in Vim)
So what do we know about the <>
format? That it can be used in mappings and abbreviations as a substitute for the represented keys/chars. That it can be used in exe
command arguments the same way but only if escaped (e.g. \<Tab>
).
If that command is entered directly it works. It would make sense that it should do the same when run by the operation generated by com
. But it doesn't. Instead the <NL>
is acting like Enter key and when Test0
is run it submits the nnoremap
alone, immediately. And, actually, we can't assume that something executed indirectly follows the exact same documented behavior as for the directly entered equivalent and obviously it's not here.
Without diving into the code (which I might just do) I can only surmise. There is something that makes <NL>
different from other key(codes). Along with <CR>
it is the only thing that can submit commands for execution (:h c_<NL>
: "start entered command"). I'd assume that's a crucial detail here with respect to why other special keycodes (e.g. <c-h>
) don't behave differently than expected. Note that if you skim through the results of, for example, :helpgrep <NL>
you'll see there are various places where <CR>
and <NL>
have exceptional behavior and/or are treated differently than most other special characters. So I don't think what we're seeing here, while a head-scratcher, is totally unexpected or unprecedented.
Anyways, for now I at least can offer a working version. This successfully escapes the mapped key...
com! Test0 exe 'nnoremap \<c-j> :echom "c-j"<cr>'
Funny things is, this just adds to the mystery, really. Now we're sort of doing double indirection/interpretation and it works the way we'd expect! Interesting.
|
and<bar>
etc. (essentially one more variation of the same problem.)