Suggested alternative keybindings cause issues

[henk84]

The suggested alternative keybindings don’t work too well for me. I’m talking about what is suggested in https://github.com/LucHermitte/lh-brackets/blob/master/doc/lh-map-tools.txt#L584:

If you'd rather use other keybindings, then add into your |.vimrc| something
like: >
        imap <C-J>      <Plug>MarkersJumpF
         map <C-J>      <Plug>MarkersJumpF
        imap <C-K>      <Plug>MarkersJumpB
         map <C-K>      <Plug>MarkersJumpB
        imap <C-<>      <Plug>MarkersMark
        nmap <C-<>      <Plug>MarkersMark
        xmap <C-<>      <Plug>MarkersMark
Note: all default mappings can be disabled by setting
|g:marker_define_jump_mappings| to 0.

What happens is that e.g. when editing my ~/.vimrc pressing <C-<> does what I expect and inserts

<>«»

and places the cursor between < and >.

Editing a .tex file has a different result, though: pressing <C-<> inserts a literal <.

Changing the binding to use <C-n> instead makes it work correctly in .tex files as well.

To Reproduce
Steps to reproduce the behavior:

1. I use the package vim-nox from debian stable for this.
2. put the following in ~/.vimrc, which sets up vim-addon-manager as recommended in their instructions to install lh-brackets as recommended in its instructions:

" put this line first in ~/.vimrc
set nocompatible | filetype indent plugin on | syn on

fun! SetupVAM()
  let c = get(g:, 'vim_addon_manager', {})
  let g:vim_addon_manager = c
  let c.plugin_root_dir = expand('$HOME', 1) . '/.vim/vim-addons'

  " Force your ~/.vim/after directory to be last in &rtp always:
  " let g:vim_addon_manager.rtp_list_hook = 'vam#ForceUsersAfterDirectoriesToBeLast'

  " most used options you may want to use:
  " let c.log_to_buf = 1
  " let c.auto_install = 0
  let &rtp.=(empty(&rtp)?'':',').c.plugin_root_dir.'/vim-addon-manager'
  if !isdirectory(c.plugin_root_dir.'/vim-addon-manager/autoload')
    execute '!git clone --depth=1'
        \       'https://github.com/MarcWeber/vim-addon-manager'
        \       shellescape(c.plugin_root_dir.'/vim-addon-manager', 1)
  endif

  " This provides the VAMActivate command, you could be passing plugin names, too
  call vam#ActivateAddons([], {})
endfun
call SetupVAM()

" ACTIVATING PLUGINS

" OPTION 1, use VAMActivate
VAMActivate lh-brackets

" " OPTION 2: use call vam#ActivateAddons
" call vam#ActivateAddons([PLUGIN_NAME], {})
" " use <c-x><c-p> to complete plugin names
"
" " OPTION 3: Create a file ~/.vim-scripts putting a PLUGIN_NAME into each line (# for comments)
" " See lazy loading plugins section in README.md for details
" call vam#Scripts('~/.vim-scripts', {'tag_regex': '.*'})

" we disable those because they conflict with C-L from vim-sensible which does
" nohlsearch and diffupdate, etc.
let g:marker_define_jump_mappings = 0
" but I still want those functions on some keys
imap <C-J>      <Plug>MarkersJumpF
 map <C-J>      <Plug>MarkersJumpF
imap <C-K>      <Plug>MarkersJumpB
 map <C-K>      <Plug>MarkersJumpB
imap <C-<>      <Plug>MarkersMark
nmap <C-<>      <Plug>MarkersMark
xmap <C-<>      <Plug>MarkersMark
imap <C-$>      <Plug>MarkersCloseAllAndJumpToLast
nmap <C-$>      <Plug>MarkersCloseAllAndJumpToLast
vmap <C-$>      <Plug>MarkersCloseAllAndJumpToLast
imap <C-)>      <Plug>MarkersJumpOutside
nmap <C-)>      <Plug>MarkersJumpOutside
vmap <C-)>      <Plug>MarkersJumpOutside

3. open ~/.vimrc and press C-<: it should insert

<>«»

4. open ~/foo.tex and press C-<: it should insert

<

which is not the expected result. Also, in an existing .tex file, the same happens.
5. Change the mappings for <Plug>MarkersMark in ~/.vimrc:

imap <C-n>      <Plug>MarkersMark
nmap <C-n>      <Plug>MarkersMark
xmap <C-n>      <Plug>MarkersMark

6. Repeat step 3, result should be the same.
7. Repeat step 4, result should be:

«»

8. Open an existing .tex file, result is:

<++>

Expected behavior
Explained above.

Context (please complete the following information):

• Vim version:

% vim --version
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled May 04 2023 10:24:44)
Included patches: 1-1378, 1499

• Other plugins installed: only VAM, as mentioned above

Additional context
Curiously, even with the mapping changed to <C-<>, when I press that keycombo in my ~/.vimrc, it still inserts:

<>«»

even though the command :imap <C-<> says No mapping found.
EDIT: I think this is explained by the mapping for a single < having almost the same effect as <Plug>MarkersMark, so please disregard this comment, unless my interpretation is wrong.

Everything in this report seems to apply equally to neovim, which is my usual editor.

The comment about mapping conflict with vim-sensible comes from my neovim config but is irrelevant here because for reproducing the issue in "proper" vim, I did not install that plugin.

I’m happy to provide more information if you let me know what is needed to find the cause for this unexpected behaviour.

Thank you very much.

[LucHermitte]

Hello,

Sorry for the delay in my answer. What you describe is quite strange, and, I think, not an issue with lh-brackets.

Given the mapping on <c-<>, pressing those two keys should display «», not <|>«» (I use the pipe to represent the cursor). It looks like the mapping on < as been triggered instead.

I wonder... could it be that <c-<> is not where you think it is? The control keys on anything that doesn't belong to a-z may not be where you expect (with vim). They are expected where they would have been on a qwerty keyboard. On my French AZERTY keyboard, they are^Wused to be in place I can never remember.

You can try to find the keybinding you would like to use by typing in command mode: CTRL+V and then the CTRL+whatyouwant. May be, the configurations of your terminal&vim don't permit to access these keys.

---

In case I've misunderstood the issue, you can check the active mappings with :verbose map <c-<>

[LucHermitte]

Also, you can check if <c-<> is really want is bound thanks to `:nnoremap <c-<> :echo "this works!"

[henk84]

Hi

Sorry for the delay in my answer.

Why am I even paying for premium support … oh wait, I’m not, so thanks for responding at all. And for the free software.

What you describe is quite strange, and, I think, not an issue with lh-brackets.

You seem to be right there, details below.

Given the mapping on <c-<>, pressing those two keys should display «», not <|>«» (I use the pipe to represent the cursor). It looks like the mapping on < as been triggered instead.

Agreed.

I wonder... could it be that <c-<> is not where you think it is? The control keys on anything that doesn't belong to a-z may not be where you expect (with vim). They are expected where they would have been on a qwerty keyboard. On my French AZERTY keyboard, they are^Wused to be in place I can never remember.

Yeah, that might be (one part of) the issue. But since it also happens with setxkbmap us it cannot be all.

May be, the configurations of your terminal&vim don't permit to access these keys.

Something like this seems to be the case. Or even some problem with XOrg.
In both rxvt-unicode and xterm both plain < and Ctrl+< return the same character.
xev also does not show much of a difference other than in the state:

with my usual layout setxkbmap de bone:

KeyPress event, serial 33, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190141655, (1470,652), root:(1471,701),
    state 0x0, keycode 51 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190142239, (1470,652), root:(1471,701),
    state 0x80, keycode 30 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XmbLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190142311, (1470,652), root:(1471,701),
    state 0x80, keycode 30 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190143230, (1470,652), root:(1471,701),
    state 0x80, keycode 51 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190146919, (1470,652), root:(1471,701),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190147223, (1470,652), root:(1471,701),
    state 0x4, keycode 51 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190148270, (1470,652), root:(1471,701),
    state 0x84, keycode 30 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XmbLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190148342, (1470,652), root:(1471,701),
    state 0x84, keycode 30 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190149039, (1470,652), root:(1471,701),
    state 0x84, keycode 51 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3600001,
    root 0x3f2, subw 0x0, time 1190149479, (1470,652), root:(1471,701),
    state 0x4, keycode 37 (keysym 0xfe0a, ISO_Prev_Group), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

with setxkbmap us:

KeyPress event, serial 36, synthetic NO, window 0x3800001,
    root 0x3f2, subw 0x0, time 1190208878, (1470,652), root:(1471,701),
    state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XmbLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3800001,
    root 0x3f2, subw 0x0, time 1190208982, (1470,652), root:(1471,701),
    state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x3800001,
    root 0x3f2, subw 0x0, time 1190210150, (1470,652), root:(1471,701),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x3800001,
    root 0x3f2, subw 0x0, time 1190210654, (1470,652), root:(1471,701),
    state 0x4, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XmbLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3800001,
    root 0x3f2, subw 0x0, time 1190210910, (1470,652), root:(1471,701),
    state 0x4, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x3800001,
    root 0x3f2, subw 0x0, time 1190211646, (1470,652), root:(1471,701),
    state 0x4, keycode 37 (keysym 0xfe0a, ISO_Prev_Group), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

In any case: this does not seem to be related to or caused by this vim plugin, so the issue should probably be closed.
I do wonder whether other people using this plugin with non-GUI (n)vim have similar issues, though. If so, it might be a good idea to change the suggested mappings, e.g. to Ctrl+n.

I will be digging further into XOrg and terminal emulators for now.

Thank you very much!

[LucHermitte]

I mostly never use vim (as I prefer gvim). I remember some distant time back with other machines where I was able to access <c-<> from vim. I don't know what have changed with my new (and your) configuration(s). I must admit this is the reason why I gave up on vim (and why I'm using gvim).

Regarding the proposition of using <c-n>. I'm really not into it as the standard i_CTRL-N can be quite useful. Also, this will require a special note as plugin like CoC.nvim regularly have recommendations to override i_CTRL-N. This will open the door to more troubles for a feature not many use -- Even I from time to time I manually insert placeholders, but it's still rare. I think I've proposed CTRL-< out of idea as everything else is used.

Nevertheless, I'll give it a though, and at least add a word about it in the documentation.

Thank you for your feedback.

[henk84]

Regarding the proposition of using <c-n>. I'm really not into it as the standard i_CTRL-N can be quite useful. Also, this will require a special note as plugin like CoC.nvim regularly have recommendations to override i_CTRL-N. This will open the door to more troubles for a feature not many use -- Even I from time to time I manually insert placeholders, but it's still rare. I think I've proposed CTRL-< out of idea as everything else is used.

Oh, right, that’s already used. Then I don’t have a sensible suggestion.

Nevertheless, I'll give it a though, and at least add a word about it in the documentation.

That would be good, thanks.

I’ll report back when I figure out under which circumstances it fails.