Neovim bug with lh-brackets

[at8i]

Describe the bug I am switching to neovim. I don't know it your plugins are supposed to be working with neovim or not. If ther are , then this is a bug. if not you can close the issue. Thanks for the Plugins it made working in vim much easier. **** This is not a bug in vim but in neovim ***** To Reproduce Steps to reproduce the behavior:

1. After installing lh-refactor thus installing lh-brackets
2. If you open any .cpp or . tex file and write anything and press enter in insert mode (I tried with .cpp and .tex files not sure about the others)
3. It writes a function from lh-brackets
4. The function is : lh#mapping#_switch(''' ''', [{'action': 'lh#brackets#_add_newline_between_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])

Expected behavior I did not want anything to happen. It was supposed to go to next line. If I remove the bracket plugin, the refactor is actually working at least for getters and setters.

Context

• NeoVim v0.05.0-dev
• I have lots of plugins installed but they all work just fine in vim 8.1

Additional context The only Plugin that I use in neovim and I don't have it in vim is coc.vim which might be causing some problems. If you think that it is a problem from neovim, I will open an issue there as well.

[LucHermitte]

Could you tell me what :message shows?

And also the result of strtrans(execute('imap <cr>')). For instance, in my case (I use COC from Vim), it returns:

^@^@i  <CR>        * lh#mapping#_switch('complete_info()[''selected''] != -1 ? coc#_select_confirm() : "\<C-G>u\<CR>"', [{'action': 'lh#brackets#_add_newline_between_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])

[at8i]

The response to :message:

Error detected while processing function UltiSnips#TrackChange[1]..provider#python3#Call:
line   18:                                                                                                                                                                                                
Error invoking 'python_execute' on channel 9 (python3-script-host):
Traceback (most recent call last):
  File "/home/at8i/.config/nvim/bundle/ultisnips/pythonx/UltiSnips/err_to_scratch_buffer.py", line 18, in wrapper
    return func(self, *args, **kwds)
  File "/home/at8i/.config/nvim/bundle/ultisnips/pythonx/UltiSnips/snippet_manager.py", line 899, in _track_change
    inserted_char = vim_helper.eval("v:char")
  File "/home/at8i/.config/nvim/bundle/ultisnips/pythonx/UltiSnips/vim_helper.py", line 122, in eval
    return vim.eval(text)
  File "/usr/lib/python3/dist-packages/pynvim/plugin/script_host.py", line 207, in eval
    obj = self.request("vim_eval", expr)
  File "/usr/lib/python3/dist-packages/pynvim/api/nvim.py", line 182, in request
    res = self._session.request(name, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/pynvim/msgpack_rpc/session.py", line 104, in request
    raise self.error_wrapper(err)
pynvim.api.common.NvimError: Keyboard interrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/at8i/.config/nvim/bundle/ultisnips/pythonx/UltiSnips/err_to_scratch_buffer.py", line 52, in wrapper
    vim_helper.new_scratch_buffer(msg)
  File "/home/at8i/.config/nvim/bundle/ultisnips/pythonx/UltiSnips/vim_helper.py", line 155, in new_scratch_buffer
    vim.command("botright new")
  File "/usr/lib/python3/dist-packages/pynvim/api/nvim.py", line 287, in command
    return self.request('nvim_command', string, **kwargs)
  File "/usr/lib/python3/dist-packages/pynvim/api/nvim.py", line 182, in request
    res = self._session.request(name, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/pynvim/msgpack_rpc/session.py", line 104, in request
    raise self.error_wrapper(err)
pynvim.api.common.NvimError: Vim(new):E523: Not allowed here
fatal_too_many_errors: Too many errors emitted, stopping now
type-alias T
unknown type name 'lh'
unknown type name 'lh'

Hmm, seems to be a Ultisnips problem, let me see what happens if I remove ultisnips . Would I still get the same result or not. I use coc-snippets and I linked to my ultisnips directory. All seems to work when I remove lh-brackets which is weird. I will update after removing ultisnips. And the result of execute('imap <cr>'): i <CR> lh#mapping#_switch('''<CR>''', [{'action': 'lh#brackets#_add_newline_between_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])<SNR>43_DiscretionaryEnd<Plug>CloserClose

[at8i]

Update: Removed Ultisnips and the response for:message

1 change; before #2  12 seconds ago
unknown type name 'lh'
1 change; before #1  58 seconds ago
unknown_typename: Unknown type name 'lh'
unknown type name 'lh'
unknown type name 'lh'
unknown type name 'lh'
expected_unqualified_id: Expected unqualified-id
expected unqualified-id
empty character constant [-Winvalid-pp-token]

Result of execute('imap <CR>') is the same. i <CR> lh#mapping#_switch('''<CR>''', [{'action': 'lh#brackets#_add_newline_between_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])<SNR>42_DiscretionaryEnd<Plug>CloserClose

It seems to go into an infinite loop , result looks like this and this is with me stopping it in just a second: lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''lh#mapping#_switch('''')«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»'«»)«»

[LucHermitte]

With my full config and nvim 0.4.4 (appimage on ubuntu), I don't see any issue :/

Something is fishy in the mapping on <cr>. Have you also used strtrans() to avoid control sequences that often make mappings unreadable?

Also, it seems lh-brackets doesn't try to wrap the same initial mapping on CR as the one I have for COC. Which is this script(name) 43?

If you could hack into lh-brackets/plugin/common_brackets.vim lines 221-225 to show how CR mapping is transformed -- and restart nvim (sorry) --, this should be insightful.

" to know where the previous definition comes from
verbose imap <cr>
call lh#...enrich_imap(..)
" I guess it isn't changed either -- which could be controlled with a ":verbose imap <cr>" once nvim has started.
let g:cr_after = strstrans(execute('imap <cr>'))

Note that it's possible that if the previous mapping on CR isn't an expression mapping, the error could come from here as I did not know how I could improve a non-expression insert mode mapping with an expression mapping. I'd have to investigate how I could do so.

[at8i]

These are the lines from 221-225:

if lh#option#get('cb_newline_within_empty_brackets', 1)
  call lh#brackets#enrich_imap('<cr>',
        \ {'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"',
        \   'action': 'lh#brackets#_add_newline_between_brackets()'},
        \ 0
        \ )
endif

This is what I did . I added line below after line 228:

" to know where the previous definition comes from
verbose imap <cr>
call lh#...enrich_imap(..)
" I guess it isn't changed either -- which could be controlled with a ":verbose imap <cr>" once nvim has started.
let g:cr_after = strstrans(execute('imap <cr>'))

If you want me to do something else, please let me know. And After restarting nvim I got the following message:

Error detected while processing /home/at8i/.config/nvim/bundle/lh-brackets/plugin/common_brackets.vim:
line  227:
E480: No match: #mapping#_switch('''
line  228:
E492: Not an editor command: ''', [{'action': 'lh#brackets#_add_newline_between_brackets()', 'condition':
 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])
i  <CR>        * lh#mapping#_switch('''<CR>''', [{'action': 'lh#brackets#_add_newline_between_brackets()'
, 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])
        Last set from ~/.config/nvim/bundle/lh-brackets/autoload/lh/brackets.vim line 389
line  230:
E121: Undefined variable: lh#
line  232:
E117: Unknown function: strstrans
E15: Invalid expression: strstrans(execute('imap <cr>'))

If I press in .vim file, I get this printed:

lh#mapping#_switch('''
''', [{'action': 'lh#brackets#_add_newline_between_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])

The reason I did not do strstrans()is because it was not working and I got a response saying that it was not an editor command. As you can see in the error as well that starstrans is not recognized.

[LucHermitte]

Sorry I made a typo. Would you mind reverting this change, and pull the last version of lh-brackets.

Then, you'll have to set the default value for verbose to 1 in autoload/lh/brackets.vim, l 161. This would display everything I detect and change as messages.

[at8i]

This is what I get after the change:

inoremap <silent> <expr> <bs> lh#mapping#_switch('''\<bs\>''', [{'action': 'lh#brackets#_delete_empty_bra
cket_pair()', 'condition': 'lh#brackets#_match_any_bracket_pair()'}])
Enriching imaping on <cr>
...previously ^@^@No mapping found
inoremap <silent> <expr> <cr> lh#mapping#_switch('''<cr>''', [{'action': 'lh#brackets#_add_newline_betwee
n_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])
New i-mapping on <cr> is ^@^@i  <CR>        * lh#mapping#_switch('''<CR>''', [{'action': 'lh#brackets#_ad
d_newline_between_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])^@^ILast set fr
om ~/.config/nvim/bundle/lh-brackets/autoload/lh/brackets.vim line 389
inoremap <silent> <expr> ( lh#brackets#opener("(",0,"","(",")",0,'')
inoremap <silent> <expr> ) lh#brackets#closer(")",")","")
xnoremap <silent> (  <c-\><c-n>@=lh#map#surround("(", ")", 0, 0, '`>ll', 1)^M
nmap <silent> ( viw(
inoremap <silent> <expr> [ lh#brackets#opener("[",0,"","[","]",0,'')
inoremap <silent> <expr> ] lh#brackets#closer("]","]","")
xnoremap <silent> <leader>[  <c-\><c-n>@=lh#map#surround("[", "]", 0, 0, '`>ll', 1)^M
nmap <silent> <leader>[ viw<leader>[
inoremap <silent> <expr> " lh#brackets#opener("\"",0,"","\"","\"",1,'')
xnoremap <silent> ""  <c-\><c-n>@=lh#map#surround("\"", "\"", 0, 0, '`>ll', 1)^M
nmap <silent> "" viw""
inoremap <silent> <expr> ' lh#brackets#opener("'",0,"","'","'",1,function('lh#ft#is_text'))
xnoremap <silent> ''  <c-\><c-n>@=lh#map#surround("'", "'", 0, 0, '`>ll', 1)^M
nmap <silent> '' viw''
xnoremap <silent> <localleader><  <c-\><c-n>@=lh#map#surround("<", ">", 0, 0, '`>ll', 1)^M
nmap <silent> <localleader>< viw<localleader><
inoremap <silent> <expr> { lh#brackets#opener("{",0,"","{","}",0,'')
inoremap <silent> <expr> } lh#brackets#closer("}","}","")
xnoremap <silent> {  <c-\><c-n>@=lh#map#surround("{", "}", 0, 0, '`>ll', 1)^M
nmap <silent> { viw{
xnoremap <silent> <leader>{  <c-\><c-n>@=lh#map#surround("{!cursorhere!", "}!mark!", 1, 1, '', 1, "<leade
r>{")^M
nmap <silent> <leader>{ V<leader>{

[LucHermitte]

Given that there is no mapping on <CR> before lh-brackets file is sourced, that the definition of lh-brackets mapping on CR is dumped in insert mode, and the extra <SNR>43_DiscretionaryEnd<Plug>CloserClose, I highly suspect that this script # 43 (you can have its complete name thanks to :scriptnames) tries to override my mapping with its own -- you can also have a more direct reference with :verbose imap <cr> I guess.

The problem is that it assumes that previous mappings on CR are not expression mappings. lh-brackets suffers from the opposite bug. I may be able to provide a workaround on my side to trick this plugin, but I wonder if this faulty plugin is really required since you're using lh-brackets? IMO it'd be best to use only a single auto-pairing plugin.

[at8i]

OK, Thank you for taking time off your day to answer these trivial questions. The only other pairing plugin I am using is tpope's surround. Just one question, will lh-refactor work witout lh-brackets ? If not, I guess I have to give other plugins that are interfering with lh-refactor. lh-refactor is the only good plugin out there not gonna lie. Thanks for the plugin.

[LucHermitte]

Thank you for taking time off your day to answer these trivial questions

Don't worry about it.

The only other pairing plugin I am using is tpope's surround.

Isn't this script # 43 something like coc-pair? Could you tel me its name and may be where it comes from?

Just one question, will lh-refactor work witout lh-brackets ?

Yes and ... no. lh-refactor uses functions from lh-brackets, but not the auto-pairing part. This means you can disable it through a global option that I don't remember the name (you can hit <F9> to toggle lh-brackets activation state, and see the name of this option). The CR mapping can also be inhibited independently of the other mappings.

lh-refactor is the only good plugin out there not gonna lie.

Thanks :)

[at8i]

I was able to find the problem, it is actually tpope's endwise. I don't know it actually matters or not but it seems lh-brackets is not compatible with endwise. Removed endwise. no problem at all , happy with the setup. And lh-refactor best refactor out these for c and c++. You can close the issue or if you want any othere information , you can let me know. Thanks for the efforts

[LucHermitte]

Indeed, the issue seems known at endwise side. See https://github.com/tpope/vim-endwise/issues/22

I'll see if I can help somehow. Thank you.

PS: There is another C++ refactoring in lh-cpp: :Modernize that replaces multiple typedefs with aligned using type definitions.

[LucHermitte]

Now you should be able to have both plugins, on the condition endwise is declared before lh-brackets in your plugin manager.

[at8i]

Now the problem is conditional: In files where endwise should be working like .cpp or .py : same problem In files like tex or no extension or files where endwise should not be working : no problem. I made sure in vundle endwise is declared before lh-brackets (cleaned and installed again). And the result of verbose:

i  <CR>          lh#mapping#_switch('''<CR><Plug>DiscretionaryEnd''', [{'action': 'lh#brackets#_add_newline_between_brackets()', 'condition': 'getline(".")[col(".")-2:col(".")-1]=="{}"'}])<Plug>CloserClose
    Last set from ~/.config/nvim/bundle/vim-closer/autoload/closer.vim line 21

I hope it helps.

[LucHermitte]

I forgot that endwise could add specializations on the fly for ft-specific cases (IIRC). I'd have to define the mapping on <CR> through an indirection to have endwise not messing up previous mappings.

I guess I'll provide this feature through a new option.

[at8i]

Hey, sorry about the delay: Your solution with tpope's endwise does work with no problem thank you for that. The problem I mentioned was because of vim-closer abother plugin that I was trying at the time . Sorry about the delay, I realized my mistake just now and thank you.

[LucHermitte]

Don't worry. As you see, I also takes my time :)

Given vim-closer and lh-brackets are both doing the same thing (if I understand correctly; but quite differently), no need to active both IMO. Bracketing mappings from lh-brackets can be completely removed if you prefer using vim-closer, whilst still providing the API vim-refactor needs from lh-brackets.

[at8i]

I was trying out other plugin to see which one can satisfy me : lh-brackets + vim-endwise is awesome!

[minhduc0711]

@LucHermitte This might be a bit silly to ask, but how do I config lh-brackets to work similarly to vim-closer, i.e. completing a pair only when <CR> is hit? I have some problems with vim-closer, so I want to give this one a try.

[LucHermitte]

@minhduc0711 While I maintain the list of existing pairs registered for a given filetype, I haven't implemented any way to detect unbalanced pairs. Mainly because I was expecting it to be complex, and likely quite expensive with pre-vim9 vimscript.

The question has been discussed on reddit a few years back: https://www.reddit.com/r/vim/comments/5ws9tg/does_vim_have_a_plugin_using_tab_to_close_and_get/

With lh-brackets, we would need to find the current context (see s:outer_blocks() for instance), and then cleanse it from balanced subblocks and non-pairs related test to see what is still opened. Plus there are some corner cases when mixing templates and comparisons in C++. Any way, I'm sorry but I'm currently trying to focus on the improvement of lh-cpp :GOTOIMPL, :MOVEIMPL and :Constructor in my spare time.

[minhduc0711]

@LucHermitte I see, thanks for the detailed answer!