It's unclear how to jump to placeholders

[fwsmit]

The placeholders that get inserted by lh-brackets after typing brackets characters seem to not work in the way they're supposed to. I can't find any shortcuts to jump to a placeholder, nor do they get deleted when I go from insert mode to normal mode. So for me the placeholder characters don't seem to do anything and only get in the way. There isn't a lot of documentation that can help me with this. So my question is: How are you supposed to work with these placeholder characters?

[LucHermitte]

Damn. I though I provide mappings compatible with terminal vim by default, but it's not the case -- supporting META-mappings with terminal is a nightmare, and they are the ones I use everyday...

Also the documentation is quite light on the subject: I've hidden in lh-cpp :h lh-cpp-first-steps, step 2 information about the placeholders and the keybindings meant to be defined with vim. Also, in lh-brackets, I provide only the keybindings available with gvim.

In all cases, you can always get rid of the marker just behind the closing character that this just after the cursor by typing that closing character.

If you have several consecutive things that can be closed, you an type <m-end> with gvim to close everything. In C and C++ case, hitting ; can also close many things.

Stuff I usually type is

• find(v +CTRL-Xbe+ ,[](auto e){ + META-r (gvim is required here) + f(e + META-DEL + META-DEL
• or f(g(y;

You know what? I still recommend to provide <C-J> by default to jump to next marker. But I have ideas for the other mappings (jump-backward, insert-marker, close-and-jump-to-last, and jump-outside), let me know.

[LucHermitte]

Let me know if the new defaults for terminal instances of vim work for you, or if you prefer some other keybindings (I just rather avoid <tab> which is already overused by other plugins which would require to provide compatible implementations.

[fwsmit]

Yep the mapping and work very well.
I have a few things to note however

• Sometimes when using templates like if\ the cursor will move to the wrong place (in this case i\f () {
• You're saying that most of the bugs are because I use terminal vim and you use gvim, but it seems like they behave the same in all cases I tested.
• What are the <m-..> and <s-..> bindings?
• When creating a function you don't want the placeholders and it's annoying to remove them. Perhaps going to normal mode or saving a file should remove all placeholders. When you don't remove them, the file won't compile.
• It would be nice to point to the :h lh-cpp-first-steps in the readme of lh-cpp (and perhaps also add some documentation to lh-brackets). I could help with this.

[LucHermitte]

Sometimes when using templates like if the cursor will move to the wrong place (in this case if () {

You mean the abbreviation? (not the template from mu-template). That's odd. Can you determine the sequence of operations that lead to that bug? Also, Have you changed your marker characters? What's your file encoding? And what's the encoding of your Vim instance?

You're saying that most of the bugs are because I use terminal vim and you use gvim, but it seems like they behave the same in all cases I tested.

What I meant is that I seldom use terminal vim, and that my terminal mappings for lh-brackets were in another file. That's why I missed the fact that I did not provide terminal-friendly mappings

What are the <m-..> and <s-..> bindings?

M stands for meta (alt key nowadays), and S for shift. See :h <m- and :h <s-

When creating a function you don't want the placeholders and it's annoying to remove them. Perhaps going to normal mode or saving a file should remove all placeholders. When you don't remove them, the file won't compile.

Good point. I save my files more often than required, removing the placeholders would defeat their purpose. Regarding compilation, you're right. I could implement this feature as a pre-compile hook that BuildToolsWrapper, but I'm one of the few that could profit from that. What you suggest could be done through an option: "(bpg):maker_auto_remove = always, never, ask-if-found"

It would be nice to point to the :h lh-cpp-first-steps in the readme of lh-cpp (and perhaps also add some documentation to lh-brackets). I could help with this.

You're right, and you'd be welcomed :)

[fwsmit]

You mean the abbreviation? (not the template from mu-template). yeah Can you determine the sequence of operations that lead to that bug? in the file foo.cpp you have

int main{
<cursor>
}

if you then type if you get

int main(){
i<cursor>f () {
«»  
}   
«»  
}

set encoding? return utf-8

---

I think in some general cases you don't want placeholders to be inserted. The cases I can think of are class definitions and function definitions.

EDIT: no I haven't changed my marker characters

[LucHermitte]

That's definitively odd. I guess I'll need the extensive list of scripts loaded (:let @+ = execute(':scriptnames') + paste into this issue), the current options (:let @+ = execute(':set')).

Regarding classes and functions, it's may be quite hard to recognize automatically. May be I could add a --placeholder=0 option (or --placeholder=someoption) to :Bracket and let the end-user either override { mappings, or set the someoption in the .vimrc or a local vimrc. Another possibility is to have the mapping on <cr> remove the placeholder when hit within a pair of curly brackets.

[fwsmit]

Sorry for the delay, but here it is: I have a feeling this bug is related to the indentation, but here are the results of the commands. I made a custom vimrc which only consists of the lh-cpp plugins. It gives a slightly different (but still wrong) result when using abbreviations

:let @+ = execute(':scriptnames') gives: https://pastebin.com/YyncAtC5

:let @+ = execute(':set') gives: https://pastebin.com/jfCDUey1 It'd be nice if you looked at this.

[LucHermitte]

Sorry for the delay. I've been quite busy as well lately.

Unfortunately I fail to reproduce the problem. At best, while editing some LaTeX documents in a VM, sometimes I see the cursor blinking in the wrong position, yet when I start typing, the text goes in the right place.

Let's start some debugging then.

Could you tell me what the following displays?

:iab
:echo strtrans(lh#cpp#snippets#def_abbr('if ', '\<c-f\>if(!cursorhere!){!mark!}!mark!'))
"it should be typed from the context where you'd type `if<space>`

And also

:LHLog file /tmp/vim-if.log
call lh#map#verbose(1)
call lh#style#verbose(1)

And then type if<space>, and send me the /tmp/vim-if.log file generated. Thanks :)

For reference, I obtain:

~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:ignored: /{\w\+}/, hows: {\w\+}
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:empty_braces: /{\_s*}/, hows: {\_s*}
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:curly-braces: /\(\%(\<\%(if\|while\|switch\|for\)\>\s*(.\{-})\|\<do\|else\>\|\<\%(namespace\|class\|struct\|union\|enum\).\{-}\S\>\)\s*\|^\)\@<!{/, hows: \(\%(\<\%(if\|while\|switch\|for\)\>\s*(.\{-})\|\<do\|else\>\|\<\%(namespace\|class\|struct\|union\|enum\).\{-}\S\>\)\s*\|^\)\@<!{
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:curly-braces: /};\@!/, hows: };\@!
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:curly-braces: /{/, hows: {
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:curly-braces: /};/, hows: };
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:curly-braces: /}/, hows: }
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:curly-braces: /\%(\<\%(if\|while\|switch\|for\)\>\s*(.\{-})\|\<do\|else\>\|\<\%(namespace\|class\|struct\|union\|enum\).\{-}\S\>\)\zs{/, hows: \%(\<\%(if\|while\|switch\|for\)\>\s*(.\{-})\|\<do\|else\>\|\<\%(namespace\|class\|struct\|union\|enum\).\{-}\S\>\)\zs{
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:spaces.brackets.cf.before: /\<\%(if\|while\|switch\|for\|catch\)\>\zs\s*(/, hows: \<\%(if\|while\|switch\|for\|catch\)\>\zs\s*(
~/.vim/addons/lh-style/autoload/lh/style.vim:164: grp:spaces.brackets.cf.before: /\%(\<\%(if\|while\|switch\|for\|catch\)\>\)\@<!\s*(/, hows: \%(\<\%(if\|while\|switch\|for\|catch\)\>\)\@<!\s*(
~/.vim/addons/lh-brackets/autoload/lh/map.vim:323: ^Fif (^R=lh#map#_cursor_here()^M) {^@^R=lh#marker#txt()^M^@}^@^R=lh#marker#txt()^M^R=lh#map#_goto_mark()^M
~/.vim/addons/lh-brackets/autoload/lh/map.vim:533: Using mark ['''R', [1, 0, 0, 0]]
~/.vim/addons/lh-brackets/autoload/lh/map.vim:539: Record cursor  with mark 'R: |   indent=4
~/.vim/addons/lh-brackets/autoload/lh/map.vim:552: Returning to mark 1 @ 
~/.vim/addons/lh-brackets/autoload/lh/map.vim:556: fix indent <- 0 (old_indent:4 - crt_indent:4)
~/.vim/addons/lh-brackets/autoload/lh/map.vim:574: Restore cursor to 2normal! 9|

[fwsmit]

Even when I try to type the cursor will still be in the wrong place.

:iab https://pastebin.com/RhakrcTr

:echo strtrans(lh#cpp#snippets#def_abbr('if ', '\<c-f>if(!cursorhere!){!mark!}!mark!')) ^Fif (^R=lh#map#_cursor_here()^M) {^@^R=lh#marker#txt()^M^@}^@^R=lh#marker#txt()^M^R=lh#map#_goto_mark()^M (no idea what that means)

/tmp/vim-if.log

Somehow after I did the call commands the next few if's, the cursor went to the right place, but the indentation was zero.
FYI this is the vimrc I used for testing

[LucHermitte]

The strtrans result displays (in a human readable form) how this mapping is actually executed.

I've just updated lh-vim-lib and lh-brackets -- I've improved (&fixed) the log produced (oddly there was an error that never triggered anything, which is odd). Could you replay the test only with

call lh#map#verbose(1)
LHLog file /tmp/vim-if.log

please?

Thanks.

[fwsmit]

I updated the plugin, but it still has the same result when typing if, so here's the log file vim-if.log

[LucHermitte]

It seems related to 'noexpandtab' + the default value for 'sw'. I'm always working with tab expanded into spaces, and 'sw' set to 4.

Now that I can reproduce the problem, I should be able to find a solution. Can you confirm my analysis? (i.e. that :set noexpandtab fixes the problem?)

[fwsmit]

Noexpandtab is already set by default for me. Before I updated I set expandtab and that indeed solved the problem. I see you made the commit on another branch, so I switched to that branch and updated. After updating It works with noexpandtab and with expandtab. Great work! You can merge the branch and close this issue now if you want.

[LucHermitte]

Unfortunately other things are now broken :(

IIRC, I've already struggle in the past with this function because there isn't any simple way to restore cursor on a virtual column which exact value will change after automatic reindentation. I'll first have to add new tests that check the behaviour of the multi-line snippets on:

• insert mode expansion
• visual mode surrounding

with:

• expandtab / noexpandtab
• &sw == 1 &tabstop, 0.5 &tabstop
• multibyte characters before the text inserted

[fwsmit]

Oh it's more complicated than I thought. I'll stay on the noexpandtab branch and I'll report any bugs I find to you

[LucHermitte]

So far, I'm aware of the one reported through the integration with travis-CI. :)

[LucHermitte]

What an headache! It should be better now.

But I still need to provide a lot of tests to be sure everything works correctly.

• [x] w/ MB characters
• [x] when line is wrapped in insert mode
• [ ] surround + no expand tab (previously incorrectly indented)
• [x] insert mode + noexpandtab
• [x] insert mode + expandtab
• ...

[fwsmit]

If you help me a bit I can maybe write those tests. Can't be too hard right?

[LucHermitte]

Well. I'd glad of any help. But I have to be honest, this is quite cumbersome to write and to test locally.

These tests should be written in spec/cpp_spec.rb -- it should have been spec/c_spec.rb, but I'll fix that another time. If you check my commits in that branch, you'll see a few changes in that file. The cumbersome part, regarding test writing, is that the file will need to have some mixed-indentation to test all the possible situations. You shouldn't have to much trouble to understand what happens here. You'll start from a stable situation, you should not encounter one of these impossible to investigate test failures I keep experimenting with the stack I've chosen.

Right now, the tests are surrounding tests that use the visual mapping from spec/support/c-snippet.vim. I should also copy the abbreviation from lh-cpp on if to that file to test the case you've observed.

The cumbersome part regarding testing is that one need to install ruby + rake + bundle + vim_runner + vim-flavor + vim-UT locally. But that's not enough, I usually trick vim-flavor with symlink in ~/.vim-flavor/repos/:

LucHermitte_lh-vim-lib -> ~/.vim/addons/lh-vim-lib/
LucHermitte_vim-UT -> ~/.vim/addons/UT/
LucHermitte_lh-style ->  ~/.vim/addons/lh-style/
...

A part of the process is described in https://github.com/LucHermitte/vim-UT/blob/master/doc/rspec-integration.md

So. If you feel like it, I'll welcome any help, but don't feel obliged to contribute on that part.

[LucHermitte]

A few tests to go (&sw == 2 * &tabstop), and most unusual cases should be covered. :)

[fwsmit]

Thanks for the explaination. I'll look into it some time. In the mean time I'll keep myself busy with discorvering bugs and thinking of enhancements.