Rebbe Malachi: March 2012

Saturday, March 31, 2012

Re: E365 hardcopy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/03/2012 17:03, Phil Dobbin wrote:

> On 31/03/2012 14:23, Tony Mechelynck wrote:
>
>> On 31/03/12 13:38, Phil Dobbin wrote:
>
>>> Out of the blue this morning my Debian Squeeze Vim (7.2.445
>>> console=huge GUI=gtk2+huge) has started throwing the hardcopy
>>> error:
>>>
>>> `E365: Failed to print Postscript file`
>>>
>>> this is on both the GUI & console Debian supplied Vims.
>>>
>>> Apt hasn't downloaded & installed any print updates recently &
>>> I can print the same test files from gedit, etc.
>>>
>>> Last time I had this on setting up Vim on Fedora it was a
>>> print preferences error (different name for the printer than
>>> specified in my vimrc) but this is not the case in this
>>> instance.
>>>
>>> I printed from this Vim on this machine a couple of days ago no
>>> problem & I haven't altered my runtime or machine settings in
>>> the meantime.
>
>> - Any recent changes in the PostScript / groff / other related…
>> packages on your system? - See also ":help print.txt" and in
>> particular: - :help print-intro - :help print-options

> No, nothing has changed on the system (only nagios has been
> installed & that came without the print monitor option) & I've read
> & re-read the above help files several times but nothing in there
> seems to be relevant.
>
> `h: E365` isn't much help either I find, so I'm stumped. I have
> exactly the same runtime files on my Vim in OS X & that's OK so
> that probably excludes a plugin problem.
>
> I'll have to run `dpkg -l` & sift through that to see if I can
> spot anything blindingly obvious but I'd've thought if that was the
> case all the other apps that I can print from would suffer too (lpr
> can print from the command line too).

I solved the hardcopy problem by commenting out the `pdev` line in my
vimrc. Why Vim decided it was no longer correct is a mystery. It
hadn't changed for months. I can only surmise that a fractional change
in something somewhere caused this but I haven't been able to trace it.

Before, Vim wouldn't print without it, now it won't print with it.

Cheers,

Phil...

- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.

Wm. Shakespeare - Much Ado About Nothing

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: Â§auto-key-locate cert pka ldap hkp://keys.gnupg.net
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPd5b5AAoJEKpMeDHWT5ADxO4IAIRf2K1GfTxl/xdKbD2Sklml
/wqZjzv0Hz2mOQzGKzyEQ438aB5nDH3TfgjW9T5bTlIkOepvkjA/B7F8++1twGr1
GliU35r+3KzazkqkZW3comHDbwct9t9XTXyRVKkZ0z4GZLOq3m1R8xDpemiKwojn
jAPxjuZPTaX2VQw9dUUyDDLIyO4+ilYWrrYKK93LHqMusU7zhmWrUa7e+HC41Qr/
MOsNjrne02msXY5Kf6SMvO9LDcWSfa3O4aaJ5OdnrC4+1xgGF27A7ibGSbMjkK93
oN5nK2Q7rcoNnujclJXHhXzkYJnLglRUd4LQL9Nbiua7g7XZQ9Pofb5/6ULC1nk=
=eup8
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: E365 hardcopy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/03/2012 14:23, Tony Mechelynck wrote:

> On 31/03/12 13:38, Phil Dobbin wrote:

>> Out of the blue this morning my Debian Squeeze Vim (7.2.445 console=huge
>> GUI=gtk2+huge) has started throwing the hardcopy error:
>>
>> `E365: Failed to print Postscript file`
>>
>> this is on both the GUI & console Debian supplied Vims.
>>
>> Apt hasn't downloaded & installed any print updates recently & I can
>> print the same test files from gedit, etc.
>>
>> Last time I had this on setting up Vim on Fedora it was a print
>> preferences error (different name for the printer than specified in my
>> vimrc) but this is not the case in this instance.
>>
>> I printed from this Vim on this machine a couple of days ago no problem
>> & I haven't altered my runtime or machine settings in the meantime.

> - Any recent changes in the PostScript / groff / other related… packages
> on your system?
> - See also ":help print.txt" and in particular:
> - :help print-intro
> - :help print-options

Hi, Tony.

No, nothing has changed on the system (only nagios has been installed &
that came without the print monitor option) & I've read & re-read the
above help files several times but nothing in there seems to be relevant.

`h: E365` isn't much help either I find, so I'm stumped. I have exactly
the same runtime files on my Vim in OS X & that's OK so that probably
excludes a plugin problem.

I'll have to run `dpkg -l` & sift through that to see if I can spot
anything blindingly obvious but I'd've thought if that was the case all
the other apps that I can print from would suffer too (lpr can print
from the command line too).

Cheers,

Phil...

- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.

Wm. Shakespeare - Much Ado About Nothing

iQEcBAEBAgAGBQJPdyrVAAoJEKpMeDHWT5ADz+sIALb6N7cSOuUKFXLcNgtQGGj/
OC8tGt6+LSBpZakg9I72tFcRaQk0qrjPyacEaLui1np3wtU9BPSbCMEj97+eNo04
J7cqwOY26Jj3O1zb7rjYb7v1NfURGlB2eRC8FpV3ZW6K6oibMryaUYxZkgRA/y+O
vk/IMbRaMG/K3ZYxesSbM63ylhlyPniURPyuioKknZ6liAaviV9H014CQY463jUe
glw07yE0tY/dXfI6lhCkEdLEgtRODrazrAh1t1uTFgkfz4bxvVnOAbaJaDR/R0ZC
O9OaKhw8vmagKVB/4DZf15NuB1R9YHw5W1UfKOI3+BjTQrClWC/G6eA1aWO/QpI=
=ufzp
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

Christian Brabandt wrote:

> On Fr, 30 Mär 2012, Bram Moolenaar wrote:
> > That leaves adding Yet Another Option...
>
> have you ever thought about providing some kind of a generic option
> setting, that could be easily extendible for such small settings.
>
> Something similar to the 'fo' and 'cpo' settings
>
> e.g. set generic=cursorline:screenline
> or something? And then when another new minor setting is needed, one
> could extend it to something like this:
>
> set generic=cursorline:screenline,foo:foobar
>
> Does that sound reasonable?

How is this better than adding an option?

--
He was not in the least bit scared to be mashed into a pulp
Or to have his eyes gouged out and his elbows broken;
To have his kneecaps split and his body burned away
And his limbs all hacked and mangled, brave Sir Robin.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: CTRL-X keybindings in insert mode (e.g. ragtag.vim)

Thanks for the responses Christian and Tony. I've looked at those 'timeout' options now and think I will possibly make a tweak.

It would appear though, that I wouldn't experience this problem had ragtag.vim used unambiguous key maps. It seems VIM is waiting for around a second to see if I'm going to type one of the sequences stipulated in ragtag.vim and then, if I haven't hit another key in time, putting me into CTRL-X sub-mode (:help -_CTRL-X).

Thanks again.

--
Mike.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: E365 hardcopy

On 31/03/12 13:38, Phil Dobbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, all.
>
> Out of the blue this morning my Debian Squeeze Vim (7.2.445 console=huge
> GUI=gtk2+huge) has started throwing the hardcopy error:
>
> `E365: Failed to print Postscript file`
>
> this is on both the GUI & console Debian supplied Vims.
>
> Apt hasn't downloaded & installed any print updates recently & I can
> print the same test files from gedit, etc.
>
> Last time I had this on setting up Vim on Fedora it was a print
> preferences error (different name for the printer than specified in my
> vimrc) but this is not the case in this instance.
>
> I printed from this Vim on this machine a couple of days ago no problem
> & I haven't altered my runtime or machine settings in the meantime.
>
> Any help appreciated,
>
> Cheers,
>
> Phil...
>

- Any recent changes in the PostScript / groff / other related… packages
on your system?
- See also ":help print.txt" and in particular:
- :help print-intro
- :help print-options

Best regards,
Tony.
--
Real computer scientists despise the idea of actual hardware. Hardware
has limitations, software doesn't. It's a real shame that Turing
machines are so poor at I/O.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

E365 hardcopy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all.

Out of the blue this morning my Debian Squeeze Vim (7.2.445 console=huge
GUI=gtk2+huge) has started throwing the hardcopy error:

`E365: Failed to print Postscript file`

this is on both the GUI & console Debian supplied Vims.

Apt hasn't downloaded & installed any print updates recently & I can
print the same test files from gedit, etc.

Last time I had this on setting up Vim on Fedora it was a print
preferences error (different name for the printer than specified in my
vimrc) but this is not the case in this instance.

I printed from this Vim on this machine a couple of days ago no problem
& I haven't altered my runtime or machine settings in the meantime.

Any help appreciated,

Cheers,

Phil...

- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.

Wm. Shakespeare - Much Ado About Nothing

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPduylAAoJEKpMeDHWT5ADxyUH+wUK7GfuaNtOmpeZ++bu+ezJ
qNuEQs8HWSDLdSUW34rfpjIcU/a/B/6er1DskU8LRFf/it4omAwk4RbxWyHELwtV
mJCeOO4dAnPwYdJRqPq4q70Ww85keSiGaKPfNCcWOCupstmdDSCMZUYTP/d3G0Jo
DIHQ9sApgsijcOcgxFBv7M7i/OvcC2E+wIkKfAZVmnP0OiFkWvnUHhVwGrfy963C
jCiLkFCCu7AJvg1u+wwa2LBQSrdmysOFIeac8Q06ZRAMcBWNNLErjEU0qu6hw+5a
Ylo+f+Ne0DJvw5AsruqZGIQjFcbaujbNW9w4Ohyk6UqzGyOMILePeyAt6SZNBa0=
=dCxs
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

Bram,

On Fr, 30 Mär 2012, Bram Moolenaar wrote:
> That leaves adding Yet Another Option...

have you ever thought about providing some kind of a generic option
setting, that could be easily extendible for such small settings.

Something similar to the 'fo' and 'cpo' settings

e.g. set generic=cursorline:screenline
or something? And then when another new minor setting is needed, one
could extend it to something like this:

set generic=cursorline:screenline,foo:foobar

Does that sound reasonable?

Mit freundlichen Grüßen
Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Still puzzling ove paste

Hi howardb21!

On Fr, 30 Mär 2012, howardb21 wrote:

> Call it aesthetics, but defining a new function and mapping to do
> abbreviations seems like quite a workaround. I have an almost
> `religious belief there should be a simple way to enable/disable paste
> in : command mode, or something similar. In other words: there just
> `must' be a way to `know' in a script wheny you are in and out of :
> mode.

There is no easier way to achieve what you want. You need at least a
function, that checks in what mode you are in. The second function was
there just to make it more easier to enter new abbreviations.

BTW: You can do it manually:
function! Abbreviate(lhs, rhs)
if getcmdtype() =~ '[/?]'
return a:rhs
else
return a:lhs
endif
endfu

cnorea foo <C-\>eAbbreviate('foo', 'foobar')<cr>

You can read about it at :h c_CTRL-\_e

And I don't think this is ugly. It is just the only way to make your
request work.

regards,
Christian
--
Sitzen 2 Rentner auf der Bank.
Erster: "Ja."
Zweiter: "Ja, ja."
Kommt ein dritter dazu.
Erster: "Ja."
Zweiter: "Ja, ja"
Dritter: "Ja, ja, ja."
Darauf der Erste zum Zweiten: "Komm wir gehen der redet mir zu viel."

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: CTRL-X keybindings in insert mode (e.g. ragtag.vim)

On 31/03/12 10:19, MikeM wrote:
> I recently downloaded Tim Pope's ragtag.vim (http://www.vim.org/scripts/script.php?script_id=1896) and note that most of the keybindings therein consist of CTRL-x, followed by another key (e.g. <C-x><CR> to create a pair of tags separated by a newline).
>
> One thing I've noticed is that if I type (in insert mode) CTRL-x and delay, say for a couple of seconds, the expected command invocations do not occur? I also not that, after such a delay, VIM displays a message in command buffer indicating that I'm in CTRL-x mode. Pressing any key, other than those listed in the command buffer message, results in the insertion of that character into the buffer as normal. This is perhaps to be expected as it accords with the description of CTRL-x mode in help, however, hitting CTRL-x and then a third key in rapid succession produces the desired result (i.e. ragtag.vim does what it's supposed to).
>
> Is this to be expected? Do others experience this?
>
>
>

Maybe a timeout could help you. See
:help 'timeout'
:help 'timeoutlen'
:help 'ttimeout'
:help 'ttimeoutlen'

The two -len settings are in milliseconds; the others are boolean. In
addition, if 'timeout' is on, 'ttimeout' is treated as on regardless of
its actual setting.

What I use (in my vimrc) is
set timeout timeoutlen=5000 ttimeoutlen=100

which means: timeout 5 seconds on mappings, 0.1 second on the bytes of a
multibyte keycode. Vary at will, depending on your typing speed and on
the speed of your keyboard interface; see the above-mentioned help tags
for details. (The default, which doesn't suit me, is 1 second on both
keycodes [too slow for me] and mappings [too fast for me].)

Best regards,
Tony.
--
... A booming voice says, "Wrong, cretin!", and you notice that you
have turned into a pile of dust.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: CTRL-X keybindings in insert mode (e.g. ragtag.vim)

Hi MikeM!

On Sa, 31 Mär 2012, MikeM wrote:

> I recently downloaded Tim Pope's ragtag.vim (http://www.vim.org/scripts/script.php?script_id=1896) and note that most of the keybindings therein consist of CTRL-x, followed by another key (e.g. <C-x><CR> to create a pair of tags separated by a newline).
>
> One thing I've noticed is that if I type (in insert mode) CTRL-x and delay, say for a couple of seconds, the expected command invocations do not occur? I also not that, after such a delay, VIM displays a message in command buffer indicating that I'm in CTRL-x mode. Pressing any key, other than those listed in the command buffer message, results in the insertion of that character into the buffer as normal. This is perhaps to be expected as it accords with the description of CTRL-x mode in help, however, hitting CTRL-x and then a third key in rapid succession produces the desired result (i.e. ragtag.vim does what it's supposed to).
>
> Is this to be expected? Do others experience this?

I guess this is expected. See :h 'timeoutlen' and :h 'ttimeoutlen'

regards,
Christian
--
Der Computer ist eine logische Weiterentwicklung des Menschen: Intelligenz
ohne Moral!

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Create own ALT+H mapping, disabling the help menu

Tim Chase wrote on 30-3-2012 22:38:
> On 03/30/12 15:03, Jeri Raye wrote:
>> I've put this line in mu vimrc
>> set winaltkeys=no
>>
>> But the window still responds on an ALT key.
>
>
> :set guioptions-=m
>
> I don't really lose much functionality (menus usually just replicate
> functionality available from the Ex prompt), and it gives me an extra
> line or two of content-height.
>
> -tim

Can it be a compiler options when gvim was compiled?

For full screen I use the shell.vim plugin
http://peterodding.com/code/vim/shell/

Rgds,
Jeri

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

CTRL-X keybindings in insert mode (e.g. ragtag.vim)

I recently downloaded Tim Pope's ragtag.vim (http://www.vim.org/scripts/script.php?script_id=1896) and note that most of the keybindings therein consist of CTRL-x, followed by another key (e.g. <C-x><CR> to create a pair of tags separated by a newline).

One thing I've noticed is that if I type (in insert mode) CTRL-x and delay, say for a couple of seconds, the expected command invocations do not occur? I also not that, after such a delay, VIM displays a message in command buffer indicating that I'm in CTRL-x mode. Pressing any key, other than those listed in the command buffer message, results in the insertion of that character into the buffer as normal. This is perhaps to be expected as it accords with the description of CTRL-x mode in help, however, hitting CTRL-x and then a third key in rapid succession produces the desired result (i.e. ragtag.vim does what it's supposed to).

Is this to be expected? Do others experience this?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: 'au InsertEnter * noh' doesn't work

Thanks for every one, Fritz's way just fit my need.

在 2012年3月31日上午1:12，Benjamin R. Haskell <vim@benizi.com>写道：

On Fri, 30 Mar 2012, Unknown wrote:

Hi everyone here, I'm just new to this mailing list. I want to automatically disable search highlight when entering insert mode, so I add the command in ~/.vimrc but it didn't work. Does anyone know what I did was wrong?

As pointed out, :noh[lsearch] doesn't work in autocmds. One common workaround is to do it from a mapping. I have the following in my ~/.vimrc:

" turn off highlighting when refreshing the screen
nn <silent> <C-l> :noh<CR><C-l>

(nn = nnoremap)

Seems like overkill, but you could use:

for key in ['i','I','o','O','a','A','gi','gI'] " any key that enters insert mode
exe 'nn <silent>' key ':noh<CR>'.key
endfor

Personally, the <C-l> trick works well for me, because I'm used to typing Ctrl+l to refresh Alpine.

--
Best,
Ben H

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Friday, March 30, 2012

Async to process some task in vim

dear all,

when i process creating tags, cscope, grep find in a large project, vim will suspend since this task finish.

it's very annoying! do you have some good idea?

--

Thanks and Best Regards！

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: How to do region syntax and avoid the effect of keywords.

On Fri, Mar 30, 2012 at 11:09 PM, Ben Fritz <fritzophrenic@gmail.com> wrote:
> On Friday, March 30, 2012 3:33:13 AM UTC-5, Yichao Zhou wrote:
>> Hi, everyone.
>>
>> I want to let vim use syntax to fold c's function in K&R like.
>>
>> int main()
>> {
>> return 0;
>> }
>>
>> So I write this:
>>
>> syntax region function start='^\h\+\_.\{-}\n\_^\ze{' end="}"
>> contains=ALLBUT,cCurlyError,@cParenGroup,cErrInParen,cCppParen,cErrInBracket,cCppBracket,cCppString,@Spell
>> fold keepend
>>
>> But I find that the "int" on the beginning of the file will stop this
>> syntax rule become effective. If I change "int main" to "aint main",
>> everything is OK. How to deal with this problem?
>
> You might be able to work around it, by using a zero-width look-behind like \@<=. Possibly \zs will work as well.
>
> I'm not sure if either will work, however. If two matches begin at the same place, keyword always takes precedence and there's no way around it beyond removing the keyword or making it contained. I'd expect \@<= to be more likely to work than \zs but may make the highlight much slower.
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

Em... This is too ugly and I don't success. Maybe I should hack into
vim's sources code and add a priority option for syntax?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

RE: MRU plugin

Tarlika wrote:
> http://www.vim.org/scripts/script.php?script_id=521
> I have been using this excellent plugin for some time, mainly
> with "Files->Recent Files" in gvim.
>
> There doesn't seem to be a user option for opening files in
> new tabs.

I don't use the menus in gvim. After entering :MRU
(or ':MRU pattern' to list paths matching the pattern)
a list of recently used files opens. In that list,
press t to open selected file in new tab.

John

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Still puzzling ove paste

On Mar 30, 2:55 am, "Christian Brabandt" <cbli...@256bit.org> wrote:

> What was wrong with the solution, I provided to you last time?

In response to Howard Schwartz's"
> Still puzzling over disabling abbreviations in : command line mode.

Call it aesthetics, but defining a new function and mapping to do
abbreviations seems like quite a workaround. I have an almost
`religious belief there should be a simple way to enable/disable paste
in : command mode, or something similar. In other words: there just
`must' be a way to `know' in a script wheny you are in and out of :
mode.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On Fri, 30 Mar 2012 15:32:59 -0400
Charles Campbell <Charles.E.Campbell@nasa.gov> wrote:

>Tarlika Elisabeth Schmitz wrote:
>> On Fri, 30 Mar 2012 13:17:44 -0400
>> Charles Campbell<Charles.E.Campbell@nasa.gov> wrote:
>>
>>
>>> Manpageview (see
>>> http://www.drchip.org/astronaut/vim/index.html#MANPAGEVIEW), which
>>> handles several kinds of help (vim, manpages, perl, php, and
>>> python), has a TMan command, which provides help in a separate tab.
>>>
>> Just installed (v24c).
>>
>> There doesn't seem to be a TMan though.
>>
>I've now loaded v24d on my website; its the one with TMan.

I installed v24d but the plugin/manpageviewPlugin.vim is from 16/9/2008
and doesn't define TMan. (unless I've done something dumb?)

Best Regards,
Tarlika Elisabeth Schmitz, Scotland

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Create own ALT+H mapping, disabling the help menu

On 03/30/12 15:03, Jeri Raye wrote:
> I've put this line in mu vimrc
> set winaltkeys=no
>
> But the window still responds on an ALT key.

While I'm not sure WHY it happens, my usual solution is just to
run without the menu ;-)

:set guioptions-=m

I don't really lose much functionality (menus usually just
replicate functionality available from the Ex prompt), and it
gives me an extra line or two of content-height.

-tim

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

MRU plugin

http://www.vim.org/scripts/script.php?script_id=521

I have been using this excellent plugin for some time, mainly with
"Files->Recent Files" in gvim.

There doesn't seem to be a user option for opening files in new tabs.

I have looked at the plugin and there are options for newtab/newwin but
I can't see how to apply this.

Has anyone tried this?

Best Regards,
Tarlika Elisabeth Schmitz, Scotland

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: ALT+ SHIFT mapping doesn't work

Thanks Ben, that does the trick

Ben Fritz wrote on 30-3-2012 17:06:
> On Friday, March 30, 2012 12:40:25 AM UTC-5, Jeri Raye wrote:
>> Hi,
>>
>> I have the following mappings:
>>
>> inoremap<M-S-7> _
>> inoremap<M-7> -
>>
>> When I do<M-7> I get - (the dash char), what is what I expected
>> When I do<M-S-7> I get | (the pipe char)
>> I would except _ (the underscore char)
>>
>> When I type :verbose map!<M-S-7>
>> Vim replies withL: I<S-.> *_-7>
>> Last set in c:… myfile
>>
>> Why do I still get the | (pipe char)?
>>
>>
>
> I don't know why, but try<M-&> instead. It seems to work here.
>

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Create own ALT+H mapping, disabling the help menu

Hi
I've put this line in mu vimrc
set winaltkeys=no

But the window still responds on an ALT key.
Why's that?

Rgds,
Jeri

Jan Larres wrote on 30-3-2012 8:19:
> Hi Jeri,
>
> Jeri Raye<jeri.raye@gmail.com>:
>> I would like to make a mapping to
>> ALT+H.
>> But this brings up the help menu in gvim on windows 7, as the H from
>> Help is the underlined key (don't know the right terminology)
>> Can you disable this in gvim, so that I can create my own ALT+H mapping?
>
> Yes, have a look at ":h 'winaltkeys'".
>
> Jan
>

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

Christian Brabandt wrote:

> On Fri, March 30, 2012 00:41, Gary Johnson wrote:
> > On 2012-03-29, Christian Brabandt wrote:
> >> Bram,
> >>
> >> On Mi, 28 Mär 2012, Abu Yoav wrote:
> >>
> >> [...]
> >> > I am editing a text file (latex). I prefer that each paragraph be a
> >> > long line, and that vim wrap the text. That's the usual behaviour, and
> >> > that works fine. An option that seems very helpful is cursorline, so I
> >> > set it (":set cul"). However, this does not do what I want. Namely,
> >> > instead of highlighting the *visual* line I am on, it highlights the
> >> > whole paragraph. Is there any way to highlight only the current visual
> >> > line I am on? Again, a workaround would be to instruct vim to have
> >> > lines of at most 80 characters (say), but I don't want that.
> >>
> >> The help for 'cursorline' says:
> >>
> >> ,----
> >> | Highlight the screen line of the cursor with CursorLine
> >> `----
> >>
> >> While 'cul' has always been highlighting complete lines. Do you think,
> >> this would warrant a new option, that changes 'cul' to only highlight
> >> screen lines or change the option 'cul' to a string option, that can be
> >> set to 'screen' or 'line'?
> >>
> >> This might be helpful for long lines (e.g. when editing csv files and
> >> wrap is set).
> >>
> >> If not, the documentation should be updated.
> >
> > Or declare it a bug and fix the behavior to match the documentation.
>
> Well, here is a patch, that fixes it. I am not sure, whether this
> is a bug and this patch certainly makes 'cul' behave unexpectedly.
>
> Would be good, if some people try it out,
> because the screen drawing code looks frightening to me ;)

I don't think we should change the current meaning of 'cursorline'.
What the original poster asked for is something else.

Since 'cursorline' is a boolean option we can't change it to be more
than an on/off switch.

That leaves adding Yet Another Option...

- Bram

--
A KNIGHT rides into shot and hacks him to the ground. He rides off.
We stay for a moment on the glade. A MIDDLE-AGED LADY in a C. & A.
twin-set emerges from the trees and looks in horror at the body of her
HUSBAND.
MRS HISTORIAN: FRANK!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

Tarlika Elisabeth Schmitz wrote:
> On Fri, 30 Mar 2012 13:17:44 -0400
> Charles Campbell<Charles.E.Campbell@nasa.gov> wrote:
>
>
>> Manpageview (see
>> http://www.drchip.org/astronaut/vim/index.html#MANPAGEVIEW), which
>> handles several kinds of help (vim, manpages, perl, php, and python),
>> has a TMan command, which provides help in a separate tab.
>>
> Just installed (v24c). I like K Map! Great for Vim and bash!
>
> There doesn't seem to be a TMan though.
>
> On vim help pages PgUp, PgDn work but on bash man pages and python help
> they don't; there I need to scroll using the scroll bars.
>
I've now loaded v24d on my website; its the one with TMan.

I'll have to look into PgUp and PgDn later...

Regards,
Chip Campbell

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On Fri, 30 Mar 2012 13:17:44 -0400
Charles Campbell <Charles.E.Campbell@nasa.gov> wrote:

>Manpageview (see
>http://www.drchip.org/astronaut/vim/index.html#MANPAGEVIEW), which
>handles several kinds of help (vim, manpages, perl, php, and python),
>has a TMan command, which provides help in a separate tab.

Just installed (v24c). I like K Map! Great for Vim and bash!

There doesn't seem to be a TMan though.

On vim help pages PgUp, PgDn work but on bash man pages and python help
they don't; there I need to scroll using the scroll bars.

Best Regards,
Tarlika Elisabeth Schmitz, Scotland

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Checkered background in terminal mode

Michael Ludwig schrieb am 20.03.2012 um 00:07 (+0100):
>
> On one of the two computers I work on, vim with Solarized now shows
> a checkered background; it looks like a mixture between Solarized
> and plain black colorscheme.

This discussion has been continued (and the issue solved) here:

Understanding the checkered background phenomenon
https://groups.google.com/d/topic/mintty-discuss/DfyN4TZ8nUU/discussion

Michael

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

Tarlika Elisabeth Schmitz wrote:
> This is one of my biggest bug bears and it drives me absolutely nuts:
>
> Is there a way to prevent :help from splitting the window?!
> I never, ever want a horizontal split. I'd just like to see the help
> text in a new tab.
>
>
> I mostly use gvim, sometimes vim. So I need a solution that works in
> both cases.
>

Manpageview (see
http://www.drchip.org/astronaut/vim/index.html#MANPAGEVIEW), which
handles several kinds of help (vim, manpages, perl, php, and python),
has a TMan command, which provides help in a separate tab. As a
variant, there's OMan, which saves your window(s) and opens the help
page in its stead (and a :q will restore your previous window(s)).

Regards,
Chip Campbell

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: 'au InsertEnter * noh' doesn't work

On Fri, 30 Mar 2012, Unknown wrote:

> Hi everyone here, I'm just new to this mailing list. I want to
> automatically disable search highlight when entering insert mode, so I
> add the command in ~/.vimrc but it didn't work. Does anyone know what
> I did was wrong?

As pointed out, :noh[lsearch] doesn't work in autocmds. One common
workaround is to do it from a mapping. I have the following in my
~/.vimrc:

" turn off highlighting when refreshing the screen
nn <silent> <C-l> :noh<CR><C-l>

(nn = nnoremap)

Seems like overkill, but you could use:

for key in ['i','I','o','O','a','A','gi','gI'] " any key that enters insert mode
exe 'nn <silent>' key ':noh<CR>'.key
endfor

Personally, the <C-l> trick works well for me, because I'm used to
typing Ctrl+l to refresh Alpine.

--
Best,
Ben H

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: 'au InsertEnter * noh' doesn't work

On 08:46 Fri 30 Mar , Ben Fritz wrote:
> On Friday, March 30, 2012 10:16:46 AM UTC-5, coot_. wrote:
> >
> > I think you want to use
> > au InsertEnter * setl nohl
> >
>
> Normally yes, but 'hlsearch' is a global option, there is no local value.
>
> Also note 'hl' is shorthand for 'highlight' not 'hlsearch' as desired (you could use 'hls' though). This is one reason I always use full option names in scripts and only use shorthand interactively.
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

Indeed you're right. Thanks,
Marcin

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: 'au InsertEnter * noh' doesn't work

On Friday, March 30, 2012 10:16:46 AM UTC-5, coot_. wrote:
>
> I think you want to use
> au InsertEnter * setl nohl
>

Normally yes, but 'hlsearch' is a global option, there is no local value.

Also note 'hl' is shorthand for 'highlight' not 'hlsearch' as desired (you could use 'hls' though). This is one reason I always use full option names in scripts and only use shorthand interactively.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: 'au InsertEnter * noh' doesn't work

On 21:56 Fri 30 Mar , Unknown wrote:
> Hi everyone here, I'm just new to this mailing list.
> I want to automatically disable search highlight when entering insert
> mode, so I add the command in ~/.vimrc but it didn't work. Does anyone
> know what I did was wrong?
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

I think you want to use
au InsertEnter * setl nohl

Best,
Marcin

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: 'au InsertEnter * noh' doesn't work

On Friday, March 30, 2012 8:56:39 AM UTC-5, 蓝星灿 wrote:
> Hi everyone here, I'm just new to this mailing list.
> I want to automatically disable search highlight when entering insert
> mode, so I add the command in ~/.vimrc but it didn't work. Does anyone
> know what I did was wrong?

:help :nohlsearch

*:noh* *:nohlsearch*
:noh[lsearch] Stop the highlighting for the 'hlsearch' option. It
is automatically turned back on when using a search
command, or setting the 'hlsearch' option.
This command doesn't work in an autocommand, because
the highlighting state is saved and restored when
executing autocommands |autocmd-searchpat|.
Same thing for when invoking a user function.

Note the "this command doesn't work in an autocommand" text.

I think you can achieve your desired result, with one of these:

au InsertEnter * set nohlsearch
au InsertLeave * set hlsearch

au InsertEnter * let s:sav_srch = @/ | let @/=""
au InsertLeave * let @/=s:sav_srch

(both untested)

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: How to do region syntax and avoid the effect of keywords.

On Friday, March 30, 2012 3:33:13 AM UTC-5, Yichao Zhou wrote:
> Hi, everyone.
>
> I want to let vim use syntax to fold c's function in K&R like.
>
> int main()
> {
> return 0;
> }
>
> So I write this:
>
> syntax region function start='^\h\+\_.\{-}\n\_^\ze{' end="}"
> contains=ALLBUT,cCurlyError,@cParenGroup,cErrInParen,cCppParen,cErrInBracket,cCppBracket,cCppString,@Spell
> fold keepend
>
> But I find that the "int" on the beginning of the file will stop this
> syntax rule become effective. If I change "int main" to "aint main",
> everything is OK. How to deal with this problem?

You might be able to work around it, by using a zero-width look-behind like \@<=. Possibly \zs will work as well.

I'm not sure if either will work, however. If two matches begin at the same place, keyword always takes precedence and there's no way around it beyond removing the keyword or making it contained. I'd expect \@<= to be more likely to work than \zs but may make the highlight much slower.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: ALT+ SHIFT mapping doesn't work

On Friday, March 30, 2012 12:40:25 AM UTC-5, Jeri Raye wrote:
> Hi,
>
> I have the following mappings:
>
> inoremap <M-S-7> _
> inoremap <M-7> -
>
> When I do <M-7> I get - (the dash char), what is what I expected
> When I do <M-S-7> I get | (the pipe char)
> I would except _ (the underscore char)
>
> When I type :verbose map! <M-S-7>
> Vim replies withL: I <S-.> *_-7>
> Last set in c:… myfile
>
> Why do I still get the | (pipe char)?
>
>

I don't know why, but try <M-&> instead. It seems to work here.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Origin or meaning of characters like "U\R\D\V" in GVIM tabs?

On Thursday, March 29, 2012 6:00:54 PM UTC-5, Rick B wrote:
> On Thu, Mar 29, 2012 at 5:36 PM, sfosparky
> wrote:
> > Per the attached screenshot, why do my GVIM tabs include characters such as ""U\R\D\V"?
> >
> > On other occasions / files, the tabs might include "\P\M\M\F\R\F\R\T".
> >
> > What are these characters?
> >
>
> The first letter of the directory names that lead up to that file :)
>

You can customize this with the 'tabline' or 'guitablabel' options. See the help for details, or here:

http://vim.wikia.com/wiki/Show_tab_number_in_your_tab_line

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On Friday, March 30, 2012 7:30:36 AM UTC-5, coot_. wrote:
>
> Hi,
>
> What about using an autocommand:
>
> au BufEnter * if &filetype == 'help' | :only | endif
>

This will wreck havoc if you ever intentionally split the help window, for example to view two help topics side by side.

I would lean toward something like this, were I to want an automatic method:

Probably I would tweak this to not actually switch the window but use a function to retrieve the option value without switching windows, but this seems to work fairly well in a few minutes of testing.

I normally just prefix the :tab though, and don't really feel the need for any automatic method.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

'au InsertEnter * noh' doesn't work

Hi everyone here, I'm just new to this mailing list.
I want to automatically disable search highlight when entering insert
mode, so I add the command in ~/.vimrc but it didn't work. Does anyone
know what I did was wrong?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30/03/2012 14:35, Tarlika Elisabeth Schmitz wrote:

> On Fri, 30 Mar 2012 14:39:33 +0200 Guido Van Hoecke
> <guivho@gmail.com> wrote:
>
>>> Is there a way to prevent :help from splitting the window?!
>> cabbrev h tab help
>
> Many thanks - works fine here.
>
> I've covered all options in .vimrc now:
>
> " always open help in new tab cabbrev help tab help cabbrev he tab
> help cabbrev h tab help

Very odd. Never mind, `:tab h topic` it is then...

Cheers,

Phil...

- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.

Wm. Shakespeare - Much Ado About Nothing

iQEcBAEBAgAGBQJPdbt8AAoJEKpMeDHWT5AD45EIAMtDgRTtTIaIA7ts6POay+5y
v8Oihnta51JJ/S+y6mDSjWE8vDSmr10+nl0SDioEx6Fs+hbEmnlyhco4xkci33hr
wcbGyerCTBJIgvW9ykf88mKU94dmmfXb2btBFl6JOMMgqkvvE2Z39Tjze3lvBWrh
+NigFm8Vdwss9hLhsFfl/iW4oY2Ou6etjwgcJ3mkt/7ZzRQjMQfp96EFZ8ktOtI8
jx77IZEjplplLTy61pN8u1cYAX3ip2vEd55cIaqMr27gIZOG8GiVzbSIB1OVoXlT
M3+GLivEhr1CtKVB2FxG0M/IFdmHhfltyt6QEvS2I57SjtF5HEX2BTBl8XzAiC0=
=7Sv7
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On Fri, 30 Mar 2012 14:39:33 +0200
Guido Van Hoecke <guivho@gmail.com> wrote:

>> Is there a way to prevent :help from splitting the window?!
>cabbrev h tab help

Many thanks - works fine here.

I've covered all options in .vimrc now:

" always open help in new tab
cabbrev help tab help
cabbrev he tab help
cabbrev h tab help

Best Regards,
Tarlika Elisabeth Schmitz, Scotland

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On Fri, Mar 30, 2012 at 15:09, Phil Dobbin <phildobbin@gmail.com> wrote:
> On 30/03/2012 13:39, Guido Van Hoecke wrote:
>> On Fri, Mar 30, 2012 at 13:51, Tarlika Elisabeth Schmitz
>> <vim@numerixtechnology.de> wrote:
>>> This is one of my biggest bug bears and it drives me absolutely nuts:
>>>
>>> Is there a way to prevent :help from splitting the window?!
>>> I never, ever want a horizontal split. I'd just like to see the help
>>> text in a new tab.
>> Same here
>>> I mostly use gvim, sometimes vim. So I need a solution that works in
>>> both cases.
>> I have this command abbreviation:
>>
>> " h open help in new tab
>> cabbrev h tab help
>>
>> So whenever I ask help with ':h' it just opens a new tab with it.
>
> Maybe it's just me but if I type:
>
> `:tab help topic` that works but the above abbreviation doesn't do anything.

`:h topic` should work equally well.

>
> Vim 7.2.445 huge with GTK2 GUI & the same console version on Debian
> Squeeze + Vim 7.3.462 huge no GUI & MacVim 7.3.353 huge with MacVim GUI
> on OS X.

Strange, I have this cabbrev in my .vimrc longer than I can remember.
Currently I use
:version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jan 2 2012 17:38:47)
MacOS X (unix) version
Included patches: 1-390
Compiled by Bjorn Winckler <bjorn.winckler@gmail.com>
Huge version with MacVim GUI.

So sorry I can't give any further assistance.
It's basic vim, can't think of any reason why it would not work.

With kind regards,

Guido

--
All I ask of life is a constant and exaggerated sense of my own
importance.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30/03/2012 13:39, Guido Van Hoecke wrote:

> On Fri, Mar 30, 2012 at 13:51, Tarlika Elisabeth Schmitz
> <vim@numerixtechnology.de> wrote:
>> This is one of my biggest bug bears and it drives me absolutely nuts:
>>
>> Is there a way to prevent :help from splitting the window?!
>> I never, ever want a horizontal split. I'd just like to see the help
>> text in a new tab.
>
> Same here
>
>>
>>
>> I mostly use gvim, sometimes vim. So I need a solution that works in
>> both cases.
>>
>
> I have this command abbreviation:
>
> " h open help in new tab
> cabbrev h tab help
>
> So whenever I ask help with ':h' it just opens a new tab with it.

Maybe it's just me but if I type:

`:tab help topic` that works but the above abbreviation doesn't do anything.

Vim 7.2.445 huge with GTK2 GUI & the same console version on Debian
Squeeze + Vim 7.3.462 huge no GUI & MacVim 7.3.353 huge with MacVim GUI
on OS X.

Cheers,

Phil...

- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.

Wm. Shakespeare - Much Ado About Nothing

iQEcBAEBAgAGBQJPdbCIAAoJEKpMeDHWT5ADxAsH/iPqXFjeRiJMGRHRLhw6EdEB
n3seaTxR1wxgVOk3FGoZb7x+erPeq+ygHtu6FqdTP+eMvnYBGNlKSOtcRIDn/I8S
wHfsOiWz2PTPf3WFZDc772i/RwlU0ASnlgGj7KniRZY3AO4CnKc6EjJglyIX1FJK
Jgp9X0xvYRVmFDCU7DcSenspU41IoncbA/MZMDd/tTW0VX7pzvngd4JU8TQWYPbA
yCgIeNTp187I+sO/tZmXjVGlDpVnfb67w7uCan44vEOadwKm0m6U7LUURqXcsSyp
+PxQG0VGH2K3NyXRnkzFcXTJSSo/F4sHARyK8Pdz2e/j1vkwsGKIUaH8BzqRW20=
=4SIZ
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On Fri, Mar 30, 2012 at 13:51, Tarlika Elisabeth Schmitz
<vim@numerixtechnology.de> wrote:
> This is one of my biggest bug bears and it drives me absolutely nuts:
>
> Is there a way to prevent :help from splitting the window?!
> I never, ever want a horizontal split. I'd just like to see the help
> text in a new tab.

Same here

>
>
> I mostly use gvim, sometimes vim. So I need a solution that works in
> both cases.
>

I have this command abbreviation:

" h open help in new tab
cabbrev h tab help

So whenever I ask help with ':h' it just opens a new tab with it.

HTH,

Guido

--
What I want is all of the power and none of the responsibility.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On Friday, March 30, 2012 2:24:48 PM UTC+2, jott...@googlemail.com wrote:
> Hi,
>
> Tarlika Elisabeth Schmitz wrote:
> > This is one of my biggest bug bears and it drives me absolutely nuts:
> >
> > Is there a way to prevent :help from splitting the window?!
> > I never, ever want a horizontal split. I'd just like to see the help
> > text in a new tab.
> >
> >
> > I mostly use gvim, sometimes vim. So I need a solution that works in
> > both cases.
>
> :tab help topic

I always use that method to read help pages. In fact I have added an abbreviation in my .vimrc for it:
cabbrev help tab help
Now whenever you start typing :help on the commandline and press the spacebar the enter the subject, it will automatically expand to 'tab help'.

Jeroen

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

On 12:51 Fri 30 Mar , Tarlika Elisabeth Schmitz wrote:
> This is one of my biggest bug bears and it drives me absolutely nuts:
>
> Is there a way to prevent :help from splitting the window?!
> I never, ever want a horizontal split. I'd just like to see the help
> text in a new tab.
>
>
> I mostly use gvim, sometimes vim. So I need a solution that works in
> both cases.
>
> --
>
> Best Regards,
> Tarlika Elisabeth Schmitz, Scotland
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

Hi,

What about using an autocommand:

au BufEnter * if &filetype == 'help' | :only | endif

See ':help :only' for how it works when 'hidden' is not set.

The drawback of it is that if you have several windows opened it will hide
them all, but it seems that you don't split windows in which case this doesn't
matter.

Best regards,
Marcin

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: :help WITHOUT split screen

Hi,

:tab help topic

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

:help WITHOUT split screen

This is one of my biggest bug bears and it drives me absolutely nuts:

Is there a way to prevent :help from splitting the window?!
I never, ever want a horizontal split. I'd just like to see the help
text in a new tab.

I mostly use gvim, sometimes vim. So I need a solution that works in
both cases.

Best Regards,
Tarlika Elisabeth Schmitz, Scotland

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

How to do region syntax and avoid the effect of keywords.

Hi, everyone.

I want to let vim use syntax to fold c's function in K&R like.

int main()
{
return 0;
}

So I write this:

syntax region function start='^\h\+\_.\{-}\n\_^\ze{' end="}"
contains=ALLBUT,cCurlyError,@cParenGroup,cErrInParen,cCppParen,cErrInBracket,cCppBracket,cCppString,@Spell
fold keepend

But I find that the "int" on the beginning of the file will stop this
syntax rule become effective. If I change "int main" to "aint main",
everything is OK. How to deal with this problem?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

On Fri, March 30, 2012 00:41, Gary Johnson wrote:
> On 2012-03-29, Christian Brabandt wrote:
>> Bram,
>>
>> On Mi, 28 Mär 2012, Abu Yoav wrote:
>>
>> [...]
>> > I am editing a text file (latex). I prefer that each paragraph be a
>> > long line, and that vim wrap the text. That's the usual behaviour, and
>> > that works fine. An option that seems very helpful is cursorline, so I
>> > set it (":set cul"). However, this does not do what I want. Namely,
>> > instead of highlighting the *visual* line I am on, it highlights the
>> > whole paragraph. Is there any way to highlight only the current visual
>> > line I am on? Again, a workaround would be to instruct vim to have
>> > lines of at most 80 characters (say), but I don't want that.
>>
>> The help for 'cursorline' says:
>>
>> ,----
>> | Highlight the screen line of the cursor with CursorLine
>> `----
>>
>> While 'cul' has always been highlighting complete lines. Do you think,
>> this would warrant a new option, that changes 'cul' to only highlight
>> screen lines or change the option 'cul' to a string option, that can be
>> set to 'screen' or 'line'?
>>
>> This might be helpful for long lines (e.g. when editing csv files and
>> wrap is set).
>>
>> If not, the documentation should be updated.
>
> Or declare it a bug and fix the behavior to match the documentation.

Well, here is a patch, that fixes it. I am not sure, whether this
is a bug and this patch certainly makes 'cul' behave unexpectedly.

Would be good, if some people try it out,
because the screen drawing code looks frightening to me ;)

regards,
Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Thursday, March 29, 2012

Re: Still puzzling ove paste

On Fri, March 30, 2012 03:31, howard Schwartz wrote:
> Still puzzling over disabling abbreviations in : command line mode. Not
> even
> sure of the terminology. In normal mode, hitting / ? or : puts you on the
> bottom of the screen, where you can execute 3 kinds of commands: / is a
> forward search ? is a backward search and : permits a special set of
> commands,
> partially left over from the old ed and ex editors. Then there is `ex'
> command line mode, which lets you execute more than one of these commands,
> before returning to normal or insert mode.
>
> It seems so reasonable to distinguish the : commands from the / and ?
> search
> commands. But there are no autocommands, or types of map or appreviations
> that
> do this. ``command line'' mode usually means all three of : / and ?
>
> I guess I could do something like this:
>
> map ^K :
> map : :set paste^M^K "using ^K to prevent infinite regress
>
> au insertEnter * set nopaste
>
>
> But then I would need to create maps for / and ? to set nopaste for these
> modes, in case someone when from a : command and then tried a search.
>
> Seems terribly messy. what I need is for entering : command mode to be an
> event, so I can use autocommands for it, like I could for cmdwin:
>
> au cmdwinEnter * set paste
> au cmdwinLeave * set nopaste
>
> Is there some obscure function that would permit me to use autocommands or
> maps that trigger when one enters and leaves : mode?
>

What was wrong with the solution, I provided to you last time?

regards,
Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Still puzzling ove paste

On 18:31 Thu 29 Mar , howard Schwartz wrote:
> Still puzzling over disabling abbreviations in : command line mode. Not even
> sure of the terminology. In normal mode, hitting / ? or : puts you on the
> bottom of the screen, where you can execute 3 kinds of commands: / is a
> forward search ? is a backward search and : permits a special set of commands,
> partially left over from the old ed and ex editors. Then there is `ex'
> command line mode, which lets you execute more than one of these commands,
> before returning to normal or insert mode.
>
> It seems so reasonable to distinguish the : commands from the / and ? search
> commands. But there are no autocommands, or types of map or appreviations that
> do this. ``command line'' mode usually means all three of : / and ?
>
> I guess I could do something like this:
>
> map ^K :
> map : :set paste^M^K "using ^K to prevent infinite regress
>
> au insertEnter * set nopaste
>
>
> But then I would need to create maps for / and ? to set nopaste for these
> modes, in case someone when from a : command and then tried a search.
>
> Seems terribly messy. what I need is for entering : command mode to be an
> event, so I can use autocommands for it, like I could for cmdwin:
>
> au cmdwinEnter * set paste
> au cmdwinLeave * set nopaste
>
> Is there some obscure function that would permit me to use autocommands or
> maps that trigger when one enters and leaves : mode?
>
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

Sure there are functions to do that, see ':help command-line-functions', in
particular ':help getcmdtype()'.

Best,
Marcin

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Create own ALT+H mapping, disabling the help menu

Hi Jeri,

Jeri Raye <jeri.raye@gmail.com>:
> I would like to make a mapping to
> ALT+H.
> But this brings up the help menu in gvim on windows 7, as the H from
> Help is the underlined key (don't know the right terminology)
> Can you disable this in gvim, so that I can create my own ALT+H mapping?

Yes, have a look at ":h 'winaltkeys'".

Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
When I look down, I miss all the good stuff. When I look up, I just trip
over things.
-- Ani Di Franco

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Create own ALT+H mapping, disabling the help menu

Hi,

I would like to make a mapping to
ALT+H.
But this brings up the help menu in gvim on windows 7, as the H from
Help is the underlined key (don't know the right terminology)
Can you disable this in gvim, so that I can create my own ALT+H mapping?

Rgds,
Jeri

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

ALT+ SHIFT mapping doesn't work

Hi,

I have the following mappings:

inoremap <M-S-7> _
inoremap <M-7> -

When I do <M-7> I get - (the dash char), what is what I expected
When I do <M-S-7> I get | (the pipe char)
I would except _ (the underscore char)

When I type :verbose map! <M-S-7>
Vim replies withL: I <S-.> *_-7>
Last set in c:… myfile

Why do I still get the | (pipe char)?

I'm using gvim on windows 7

Rgds,
Jeri

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Still puzzling ove paste

Still puzzling over disabling abbreviations in : command line mode. Not even
sure of the terminology. In normal mode, hitting / ? or : puts you on the
bottom of the screen, where you can execute 3 kinds of commands: / is a
forward search ? is a backward search and : permits a special set of commands,
partially left over from the old ed and ex editors. Then there is `ex'
command line mode, which lets you execute more than one of these commands,
before returning to normal or insert mode.

It seems so reasonable to distinguish the : commands from the / and ? search
commands. But there are no autocommands, or types of map or appreviations that
do this. ``command line'' mode usually means all three of : / and ?

I guess I could do something like this:

map ^K :
map : :set paste^M^K "using ^K to prevent infinite regress

au insertEnter * set nopaste

But then I would need to create maps for / and ? to set nopaste for these
modes, in case someone when from a : command and then tried a search.

Seems terribly messy. what I need is for entering : command mode to be an
event, so I can use autocommands for it, like I could for cmdwin:

au cmdwinEnter * set paste
au cmdwinLeave * set nopaste

Is there some obscure function that would permit me to use autocommands or
maps that trigger when one enters and leaves : mode?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Origin or meaning of characters like "U\R\D\V" in GVIM tabs?

The first letter of the directory names that lead up to that file :)

On Thu, Mar 29, 2012 at 5:36 PM, sfosparky <phrawm48@gmail.com> wrote:
> Per the attached screenshot, why do my GVIM tabs include characters such as ""U\R\D\V"?
>
> On other occasions / files, the tabs might include "\P\M\M\F\R\F\R\T".
>
> What are these characters?
>
> Cheers & thanks,
> sfosparky
> SFO
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

On 2012-03-29, Christian Brabandt wrote:
> Bram,
>
> On Mi, 28 Mär 2012, Abu Yoav wrote:
>
> [...]
> > I am editing a text file (latex). I prefer that each paragraph be a
> > long line, and that vim wrap the text. That's the usual behaviour, and
> > that works fine. An option that seems very helpful is cursorline, so I
> > set it (":set cul"). However, this does not do what I want. Namely,
> > instead of highlighting the *visual* line I am on, it highlights the
> > whole paragraph. Is there any way to highlight only the current visual
> > line I am on? Again, a workaround would be to instruct vim to have
> > lines of at most 80 characters (say), but I don't want that.
>
> The help for 'cursorline' says:
>
> ,----
> | Highlight the screen line of the cursor with CursorLine
> `----
>
> While 'cul' has always been highlighting complete lines. Do you think,
> this would warrant a new option, that changes 'cul' to only highlight
> screen lines or change the option 'cul' to a string option, that can be
> set to 'screen' or 'line'?
>
> This might be helpful for long lines (e.g. when editing csv files and
> wrap is set).
>
> If not, the documentation should be updated.

Or declare it a bug and fix the behavior to match the documentation.

Regards,
Gary

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Origin or meaning of characters like "U\R\D\V" in GVIM tabs?

Per the attached screenshot, why do my GVIM tabs include characters such as ""U\R\D\V"?

On other occasions / files, the tabs might include "\P\M\M\F\R\F\R\T".

What are these characters?

Cheers & thanks,
sfosparky
SFO

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

Hi Christian,

> That is because it waits until the CursorHold/CursorHoldI triggers,
> which by default triggers after 'updatetime' seconds (e.g. 4 seconds, if
> you haven't tuned it yourself). So try decreasing the 'updatetime'
> setting.
Oh, now I see. I tried changing the last line of the script to
au CursorMoved,CursorMovedI * :call CursorLine()
but now the cursor movement is too slow. I'll find the best option and stick with that.

Thanks again for all the help,

Abu

On Thu, Mar 29, 2012 at 12:13 PM, Christian Brabandt <cblists@256bit.org> wrote:

Hi Abu!

On Do, 29 Mär 2012, Abu Yoav wrote:

> First, thank you very much for the reply!
>
> On the one hand, your solution does indeed work. On the other hand, the
> time it takes for the underline to update itself to the correct line is
> really slow. On my machine, about 5 seconds (with the !hlexists("CL")
> correction, on a very small file). Do you know if there is a parameter I
> can tune to get this working faster, or is this due to the fact that a
> script is inherently slow?

That is because it waits until the CursorHold/CursorHoldI triggers,
which by default triggers after 'updatetime' seconds (e.g. 4 seconds, if
you haven't tuned it yourself). So try decreasing the 'updatetime'
setting.

See also the help at
:h 'updatetime'
:h 'CursorHold'

regards,
Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

Bram,

On Mi, 28 Mär 2012, Abu Yoav wrote:

[...]
> I am editing a text file (latex). I prefer that each paragraph be a
> long line, and that vim wrap the text. That's the usual behaviour, and
> that works fine. An option that seems very helpful is cursorline, so I
> set it (":set cul"). However, this does not do what I want. Namely,
> instead of highlighting the *visual* line I am on, it highlights the
> whole paragraph. Is there any way to highlight only the current visual
> line I am on? Again, a workaround would be to instruct vim to have
> lines of at most 80 characters (say), but I don't want that.

The help for 'cursorline' says:

,----
| Highlight the screen line of the cursor with CursorLine
`----

While 'cul' has always been highlighting complete lines. Do you think,
this would warrant a new option, that changes 'cul' to only highlight
screen lines or change the option 'cul' to a string option, that can be
set to 'screen' or 'line'?

This might be helpful for long lines (e.g. when editing csv files and
wrap is set).

If not, the documentation should be updated.

regards,
Christian
--
Der Furchtsame erschrickt vor der Gefahr, der Feige in ihr, der Mutige
nach ihr.
-- Jean Paul (eig. Johann Paul Friedrich Richter)

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

Hi Abu!

On Do, 29 Mär 2012, Abu Yoav wrote:

> First, thank you very much for the reply!
>
> On the one hand, your solution does indeed work. On the other hand, the
> time it takes for the underline to update itself to the correct line is
> really slow. On my machine, about 5 seconds (with the !hlexists("CL")
> correction, on a very small file). Do you know if there is a parameter I
> can tune to get this working faster, or is this due to the fact that a
> script is inherently slow?

That is because it waits until the CursorHold/CursorHoldI triggers,
which by default triggers after 'updatetime' seconds (e.g. 4 seconds, if
you haven't tuned it yourself). So try decreasing the 'updatetime'
setting.

See also the help at
:h 'updatetime'
:h 'CursorHold'

regards,
Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cursorline and long lines

Hi Christian,

First, thank you very much for the reply!

On the one hand, your solution does indeed work. On the other hand, the time it takes for the underline to update itself to the correct line is really slow. On my machine, about 5 seconds (with the !hlexists("CL") correction, on a very small file). Do you know if there is a parameter I can tune to get this working faster, or is this due to the fact that a script is inherently slow?

On Wed, Mar 28, 2012 at 10:42 PM, Christian Brabandt <cblists@256bit.org> wrote:

On Thu, March 29, 2012 07:40, Christian Brabandt wrote:
> if !exists("CL")

that should have been if !hlexists("CL")

regards,
Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cmdwin is passing strange

On 03/29/12 09:16, Ben Fritz wrote:
> On Thursday, March 29, 2012 4:09:12 AM UTC-5, howardb21 wrote:
>> Would it not be more reasonable, to put the user in : mode, if he gets there
>> from the : command line?
>
> Maybe insert mode would be reasonable. But I like the current functionality better. My uses of command-line mode are usually:
>
> 1. start a command line
> 2. realize I need to do complicated edits or go back to the middle somewhere
> 3. open the command window and execute 2 or 3 normal-mode commands
> 4. run the command
>
> If I want insert mode, I'll just stay on the command-line. If
> I use the command window, I usually want the power of normal
> mode. Occasionally I just want insert-mode completion, but
> that's relatively rare.

My usage pattern is much like Ben's, so defaulting to Insert mode
would just mean one more step of hitting <esc> when I got there.
Most often it stems from some :substitute command where I
either need to globally change a term that appears multiple
times, or I want to duplicate something (such as when writing a
regexp for finding things in particular columns of delimited
data) where the ability to yank and paste to/from various
registers saves a world of time.

My other big use-case is using "q:" (or slash or question-mark
for those histories) and then searching backwards for a command
to execute (after optionally editing it). And here again,
starting in Insert mode would only slow me down with the need to
hit <esc> before using / or ? to find the line I need.

-tim

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Cool error message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/03/2012 17:02, Magnus Woldrich wrote:

>> Guru Meditation:
>
> Good old Amiga... :-)

Ah, I see :-)

- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.

Wm. Shakespeare - Much Ado About Nothing

iQEcBAEBAgAGBQJPdIh5AAoJEKpMeDHWT5ADN5sH/0w0bY3myjiJxc34vtISpcVY
DMNiBMWsAr0f2GAs3RTELjZY/1ZAR9A1M0YKXBXnsEJFeFJhR2LOUDYR2zNGGZug
RqueLa1AKrmSH2ApYw+cBFeRW+0O8Jj9lNYDWcjt6tCngaqX7l1zCGEO6imG1MbJ
fNNBLhOXDyZU5LE/NCroygaaoT+zjhZBg3pdbbVaJBo9l0/7VeQ57VpCkwWj2KYQ
6NsrvW0Srh3RZRwzwIXxhM85GbFuhfJEcYrNGyfNv+LbjB0VWS6amMVaB8NIoMkZ
DqfaLQ/M7lDkXIsUki+U/OH5JsHhPvJy/otrNJ+QkZZx/8UDAWIweonobnWZQ40=
=lo7A
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Cool error message

>Guru Meditation:

Good old Amiga... :-)

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

wildignorecase

Hi,

Is the wildignorecase feature supposed to work on buffer changes? I
built the latest version of vim (7.3.487), and I can only get it to
work on opening new files.

Thanks!

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Cool error message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all.

Great error message in the Download section of <www.vim.org>

`Service Unavailable
Guru Meditation:

XID: 1794358973

Varnish cache server`

Cheers,

Phil...

- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.

Wm. Shakespeare - Much Ado About Nothing

iQEcBAEBAgAGBQJPdHLxAAoJEKpMeDHWT5ADSOgH/i6TMpCrfJ6CmUhSUZ4coTi5
dV5AMrN/CyRCvXSgwPUTHZu1eCYEEcxauE65THEQ3vKWrgyOtXtA0CJd3Lo2IFUR
VPzrLeYUISXPpogD9bncfdUYfSRsWlkrlnMENG/nFwHLpGCW9rbvjTu6MgUomz0G
8GpWag1S9x3oUnapx09Xk1mkClrObETR0Gvl9xF6OS0kUBX0VdHhsIaZbOSpCFeK
HYA6fJmIFa1kKdO6B4scLHVNlCwn6HpkNdLL/T9K5KMwOYNI+3MHgvzoUo+yQKIJ
VWMuKW06Ut/10uKgX++JGir1TIqi8UkJb+FFTKEHZa1pyegPWy70OgM7MoCsdXE=
=8Rpx
-----END PGP SIGNATURE-----

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: executing a recording on a selected block

On Thursday, March 29, 2012 12:48:25 AM UTC-5, sinbad wrote:
> how to execute a recording on a selected visual block.
>
> -sinbad

I'm assuming you have a macro that does some work on a single line, and you want to apply it to every line in a visual selection. Assuming the macro is in the 'q' register, there are two good ways to do this:

1. Take your existing macro, and run it on every line in the selection, using :'<,'>normal! @q
2. Rather than operating on a visual selection:
a. count the number of lines you wish to run the command on. 'relativenumber' is a good option to help with this.
b. make your macro move to the next line when it is done; if you already have a macro which does work but doesn't move, you can add the movement to the end. Just type qQjq to append a 'j' command to the end of the q register.
c. execute the macro with a count equal to the number of lines to operate on. For example, to operate on 10 lines starting at the cursor, type 10@q

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: cmdwin is passing strange

On Thursday, March 29, 2012 4:09:12 AM UTC-5, howardb21 wrote:
> Toying with the command line window (cmdwin), I noticed that, if you
> are in the : command line and hit ctrl-F to enter the command window,
> you enter it in normal command mode, even though the line starts with a :
>
> That is, you can not type anything unless you hit i to enter insert text mode,
> or - strangely - if you hit another : -- well that puts you in command line
> mode, in the command window so you can go ahead and type, for instance,
> a command like set textwidth=75 or whatever.
>
> Would it not be more reasonable, to put the user in : mode, if he gets there
> from the : command line?

Maybe insert mode would be reasonable. But I like the current functionality better. My uses of command-line mode are usually:

1. start a command line
2. realize I need to do complicated edits or go back to the middle somewhere
3. open the command window and execute 2 or 3 normal-mode commands
4. run the command

If I want insert mode, I'll just stay on the command-line. If I use the command window, I usually want the power of normal mode. Occasionally I just want insert-mode completion, but that's relatively rare.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: How to create a mapping that makes vim go into selec-mode

Hi Christian

Thanks

Rgds,
Jeri

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: map colon

On Thu, 29 Mar 2012 13:49:37 +0800
"andy" <zbandyulihc@gmail.com> wrote:

> Map <SPACE> to ":" maybe is a good idea, semicolon is fairly usefull
> too, after all

Many thanks everyone for their suggestions and explanations.

I am trying the space bar to-day. But old habits die hard: I'm still
hitting <shift>colon most of the time.

Best Regards,
Tarlika Elisabeth Schmitz, Scotland

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

cmdwin is passing strange

Toying with the command line window (cmdwin), I noticed that, if you
are in the : command line and hit ctrl-F to enter the command window,
you enter it in normal command mode, even though the line starts with a :

That is, you can not type anything unless you hit i to enter insert text mode,
or - strangely - if you hit another : -- well that puts you in command line
mode, in the command window so you can go ahead and type, for instance,
a command like set textwidth=75 or whatever.

Would it not be more reasonable, to put the user in : mode, if he gets there
from the : command line?

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Re: Abbreviations do not work with

I answered my own question, but will share for the benefit of others.

The AutoPair plugin had wreaked a bit of havoc with space bar. Once I disabled this plugin, the space bar worked fine with abbreviations.

I discovered this by :verbose imap <space>, which pointed it out quickly.

JT Mitchum
On Mar 29, 2012, at 2:01 AM, jtmitchum wrote:

> Hello,
>
>
> I wanted to add an abbreviation for my email, but I found that none of
> my abbreviations work the way I expect them to.
>
> example.
>
> :ab jjm example@gmail.com
>
> when I type jjm in insert mode - after I hit space, nothing happens.
> If I use any other key after this, then the abbreviation expands as
> expected (I can use <CR>, ', ' , '\' and many others)
>
> Why won't my abbreviations work with space bar?
>
> Using MacVim - vim 7.3
> (.vimrc file follows)
> syntax on
> "Highlights matching bracket pairs.
> set showmatch
>
> set backspace=indent,eol,start
> set nocompatible
>
> "Set Colorscheme - I like this one because I can read comments
> colorscheme vividchalk
> au FocusGained * :colorscheme vividchalk
> au FocusLost * :colorscheme wombat
>
> "Experimental Justin Shit
> set statusline=%F\ \ %m%r%h%w\ \ \ \ TYPE=%{&ff}:%Y\ \ \ \ BUF=%n\ %=\
> [ASCII=\%03.3b\ :\ HEX=\%02.2B]\ \ \ \ [COL=%v\ :\ LINE=%l\ :\ %L\
> lines\ :\ %p%%]\ \
> "This option is for Tex I believe
> filetype off
>
>
> " Set preview program for PDF's
> let g:Tex_ViewRule_pdf = 'Preview'
>
>
> "Turn on Conceal feature which I thought would be cool.
> set cole=2
> hi Conceal guibg=black guifg=white
>
> "This loads my plugins for me - by default stored in bundles/
> call pathogen#infect()
> filetype plugin indent on
> set modelines=0
> set encoding=utf-8
> set scrolloff=3
> set autoindent
> set showmode
> set showcmd
> set hidden
> set wildmenu
> set wildmode=list:longest,full
> set visualbell
> set cursorline
> set ttyfast
> set ruler
> set laststatus=2
>
> "Line numbers are relative from cursor position - Not sure if I like
> it yet or
> "not!
> set relativenumber
> set undofile
>
> "If I change focus, save the file - even if temporarily
> au FocusLost * :wa
> au FocusLost * silent! wa
>
>
> "Set mapleader to , - surely faster than \
> let mapleader = ","
>
> "Make a new vertical split window
> nnoremap <leader>w <C-w>v<C-w>l
>
> nnoremap / /\v
> vnoremap / /\v
> set ignorecase
> set smartcase
> set gdefault
> set incsearch
> set showmatch
> set hlsearch
> nnoremap <leader><space> :noh<cr>
> nnoremap <leader>nt :NERDTree<cr>
> ""nnoremap <tab> %
> ""vnoremap <tab> %
> nnoremap j gj
> nnoremap k gk
> nnoremap <leader>q gqip
> inoremap ii <ESC>
> let tlist_tex_settings = 'latex;s:sections;g:graphics;l:labels'
> let tlist_make_settings = 'make;m:makros;t:targets'
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Saturday, March 31, 2012

Friday, March 30, 2012

Thursday, March 29, 2012

Blog Archive

About Me