Hmm. This is interesting. Here's what get saved as the command (
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.
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
<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.