lh-map-tools: Customizable Surround() behavior

[GoogleCodeExporter]

I often like this kind of behavior:
Select a few lines in visual mode, hit '{' which surrounds the code
with braces, but also two newlines (one before and one after the
selected lines). Additionally, the selected lines should be shifted to
the right (as if you would do '>' in visual mode). And possibly put
the cursor before the opening '{' :)

Original issue reported on code.google.com by ngaloppo@gmail.com on 26 Feb 2008 at 8:56

[GoogleCodeExporter]

The correction of this defect will require profound modifications in the kernel 
of
the venerable common_brackets.vim.

Original comment by luc.herm...@gmail.com on 3 Mar 2008 at 4:10

• Changed title: lh-map-tools: Customizable Surround() behavior
• Changed state: Started

[GoogleCodeExporter]

Does the latest version of map-tools (with the relevant c_brackets ftplugin) 
answer
your need ?
If not, we can still play with -nl, and \n in :Brackets call, but I'm afraid the
easiest solution will be to directly define the mapping by hand with:
{{{
xnoremap <buffer> { <C-\><C-N>@=Surround('!cursorhere!\n{', '}\n!mark!', 1, 1, 
'', 1,
'{')<CR>
nmap     <buffer> { V{
}}}
NB: I'd rather not add another -reindent or whatever option. If all the actual
parameters to Surround need to be passed to :Brackets, it is, IMHO, better to
directly pass them to Surround().

Note: r71 of misc_map.vim is required to fix a bug in Surround() that prevented 
the
previous mappings to correctly place the cursor once the expansion is done.
I'll also add a word about this in a pseudo-FAQ.

Original comment by luc.herm...@gmail.com on 27 Mar 2008 at 10:26

[GoogleCodeExporter]

Hi, I'm a little bit confused. I fetched the unstable map-tools (1.0.0) and the
latest lh-vim trunk. 

First of all, I occasionally get these errors when loading a cpp file: 

Unknown function: lh#vim#brackets#dquotes
Unknown function: lh#vim#brackets#lt

Then, the bracketing system seems to work somehow, but I am confused by the 
syntax in
c_brackets ftplugin. I thought it defines bracketing such that it would add 
newlines
when I do visual-mode or normal-mode '{'. This is not the case when I try it 
out. It
surrounds the visual selection (or the word that the cursor is standing on in 
normal
mode), iow. it looks like v_iw is used instead of 'V'. From the docs, I thought 
to
understand that the -nl in c_brackets ftplugin should give the other behavior. 
I am
confused :)

Thanks,

--nico

Original comment by ngaloppo@gmail.com on 10 Apr 2008 at 3:58

[GoogleCodeExporter]

Regarding the two unknown functions, I guess you meant you have the errors when 
you
open a _vim_ file. My mistake, I forgot to upload one file in this branch.

Regarding the default behaviour of { in visual mode, 
- the documentation is not up-to-date, 
- { indeed transforms "fooselectedbar" into "foo{selected}bar", with the cursor 
in
normal mode on the '}'
- <localleader> however transforms the same text into 
"foo{\nselected\n}<marker>bar"
with the cursor in insert mode after the opening '{' -- depending on your
configuration, <localleader> will be '\' by default, or ',' if you have 
installed lh-cpp

If you want to change this default behaviour, the best is probably to add a
{rtp}/after/ftplugin/c/c_my_brackets.vim that changes the definitions of the 
visual
mode {-mappings by playing with "--trigger" option.

Original comment by luc.herm...@gmail.com on 10 Apr 2008 at 9:35

[GoogleCodeExporter]

Sorry, I don't understand. <localleader> doesn't do anything in my setup. Could 
you
give me the exact steps of what I should try to do? What you said about visual 
mode
'{' indeed works as described. However, I can't get the behavior with \n to 
work.

Thanks!

Original comment by ngaloppo@gmail.com on 10 Apr 2008 at 1:14

[GoogleCodeExporter]

(My mistake, I missed a character in my previous comment.)

As <leader>, <localleader> designs a character that is \ by default [1] ; the
difference being that <localleader> can be different in each buffer. It is 
typically
used in ftplugins.

This means, the behaviour you are looking for is either mapped to '\{', or to 
',{' --
because lh-cpp (if installed) sets <localleader> to ',' in C and C++ 
vim-buffers.

[1] Unfortunatelly, vim does not provide any direct way to ask for its value. 
Either
the variable maplocalleader exists and is set to a sequence of keys, or it does 
not
exist, and vim uses '\' to define mappings containing <localleader>.

Original comment by luc.herm...@gmail.com on 10 Apr 2008 at 1:52

[GoogleCodeExporter]

Super! This works as desired. FWIW, this should close this issue for me. 

Thanks!

Original comment by ngaloppo@gmail.com on 10 Apr 2008 at 1:59

[GoogleCodeExporter]

Wonderful!
I'll definitively close it as soon as I update the documentation relative to 
this topic.

Original comment by luc.herm...@gmail.com on 10 Apr 2008 at 3:21

• Changed state: Fixed