Re: alt keys in bash
On Tue, 20 Jun 2006, Vincent Wang wrote: Gerald Lai wrote: On Mon, 19 Jun 2006, Mike wrote: I am switching from windows to linux for my development environment, and working on 'porting' my .vimrc file. I have tons of Alt key remappings, but I am having trouble getting them working in plain vim (i.e. not gvim) from a bash shell. For instance, the mapping :inoremap a-b foo does not work because vim does not seem to recognize the alt key. If I use the 'Ctrl-V Alt-b' approach, I end up with this: :noremap ^[b foo which does work, but the :map command show that it really maps to escb However, this is really annoying, because when I want to escape from insert mode, vim hesitates for a second to make sure that I really want just 'esc', rather than 'escb'. Is there a way I can get vim to use alt key remappings, without mapping them to the esc key? If this is really an XWindows or KDE config problem rather than a vim problem, then please point me to the appropriate list/newsgroup/forum. I am running Vim 6.4.7 in Fedora Core 5. My shell is KDE Konsole, but I see the same problem from xterm. I've addressed this issue of how to make keycodes more responsive a few times on this mailing list: http://groups.yahoo.com/group/vim/message/66414 http://groups.yahoo.com/group/vim/message/66451 http://groups.yahoo.com/group/vim/message/69148 HTH :) -- Gerald Hi, Gerald If you can post this tip to vim's homesite, that will be Great! :) BR Vincent Done :) It's a long one: Mapping fast keycodes in terminal Vim http://www.vim.org/tips/tip.php?tip_id=1272 -- Gerald
Re: Using tags to quick complete funtion names
On Sat, 24 Jun 2006, Hari Krishna Dara wrote: [snip] I did try this to store the complete func and restore it after c-xc-u fun DoCompleteRegex() let cf = completefunc set completefunc=CompleteWithSimpleRegex normal c-xc-u set completefunc=cf return endfun It didn't work. How would you do this? Marc I don't know why the normal command wouldn't work in your case, but you could try to set the completion results immediately by calling the complete() function, instead of fiddling with 'completefunc'. Try exe normal \C-x\C-u instead. -- Gerald
RE: Script to create automatic case statements
On Fri, 23 Jun 2006, Max Dyckhoff wrote: If there are many values for the enum then I will generally jump to the tag and do as you do; copy the values and do an :s on them. What I was wondering though was basically can I make vim insert every entry from the ^N popup menu?, which is listing all the values that I want to enter. [snip] I don't think there's a way to capture the current results from a popup completion menu. This is required to do what you want. Perhaps Bram could include a function that would return a List of entries from the current popup menu. -- Gerald
Re: No-echo for shell command from vim.
On Thu, 22 Jun 2006, Ajay Gupta wrote: (Re-sending because it didnt appear the first time) Hello all. I have included the following function in my .vimrc: function! CScope_Refresh() set nocsverb cs kill 0 Following find searches for .c and .h files !find $PWD -name \*.[ch] files cscope -b -i files This one searches for cpp files as well. !find $PWD| grep [\\.p][chp]$ files cscope -b -i files cs add . set csverb endfunction The problem is that when I execute this function (thru some shortcut key), after 'find' the shell waits for me to press 'Enter' to continue. I just want to return to vim to where I was (Lets assume that the command always succeeds). Is there anything I can do to effect this? Append silent in front of ! as in silent !find $PWD -name \*.[ch] files cscope -b -i files See :help :silent HTH. -- Gerald
Re: after :vert sba hide all windows again except the active on
On Thu, 22 Jun 2006, Johannes Schwarz wrote: J?rgen Kr?mer [EMAIL PROTECTED] 22.06.2006 10:22 Hi, Johannes Schwarz wrote: I just realized the :sba or even better the :vert sba command. Is it possible to hide all windows again except the active one, which the cursor is in? have a look at :help :only This is exactly what I was looking for. [snip] I believe ZoomWin would also do what you want: http://www.vim.org/scripts/script.php?script_id=508 HTH. -- Gerald
Re: Differences in the gf command between Windows and Linux
On Wed, 21 Jun 2006, A.J.Mechelynck wrote: Tom Purl wrote: I've become a very big fan of using the pyGTD http://96db.com/pyGTD/ script from within Vim 7. pyGTD creates file output that looks similar to this: 3.61 1:00 Get your hair cut C=0 P=4 CRC=33B0 I=4 U=4 T=1H [EMAIL PROTECTED],@Work ID=5 [./inboxes/Shopping-Errands.txt] 3.61 1:00 Cancel Comcast cable internet service C=0 P=4 CRC=A32D I=4 U=4 T=1H D=2006-06-21 [EMAIL PROTECTED],@Work ID=7 [./inboxes/Shopping-Errands.txt] On Linux, I'm able to place my cursor over the file names between brackets and navigate to them using the `gf` command. On Windows, however, I get the following error: E447: Can't find file [./inboxes/Shopping-Errands.txt] in path `gf` works without the brackets on Windows, so I guess I need to find a way to filter out the brackets when I use that command. Does anyone have a clue as to how I can do this? Or would this be considered a bug? Thanks in advance! Tom Purl It's not a bug: [] are 'isfname' characters on W32 but not on Unix. IOW, on Windows (but not on Linux), brackets can be part of a filename. The quick and dirty solution is :set isf-=[ isf-=], but it might break something else. A possibly less dirty solution would be yi[ (in Normal mode: yank inner [] block) followed by :e Ctrl-REnter (edit the file whose name is in the unnamed register). If you want a mapping: :map F6 yi[:e C-RCR Actually, vi[gf would do just fine. If you'd like a count of 3 for 'gf', then do vi[3gf See :help v_gf :help i[ :help i] HTH. -- Gerald
Re: Backspace and Delete working same way. delete after cursor
On Mon, 19 Jun 2006, Sushmit Khanna wrote: Hi, I was initially having some problems with backspace key, specially in insert mode. In insert mode I was getting the ^? signs when backspace is pressed. This got fixed by :fixdel Now the issue is that the backspace is not deleting chars *before* the cursor, but after the ones after it, be it insert mode or command mode. :help backspace was not helpful in this matter. Can you help me in this getting around this. My $TERM in shell is set as xterm (correctly). And stty erase is also correct (which should not matter if fixdel has been invoked) Have you tried what was described in :help :fixdel ? That is, if term == xterm set t_kb=^VBS fixdel endif where ^VBS is Ctrl-v + Backspace. -- Gerald
filename completion ignorecase for Vim 7
Hi all, For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e FTab matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? -- Gerald
Re: filename completion ignorecase for Vim 7
On Sat, 17 Jun 2006, Bram Moolenaar wrote: Gerald Lai wrote: For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e FTab matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? What system? On MS-Windows case of filenames is ignored, on Unix it matters, on Mac it depends. I'm on Windows for Vim 7, Linux for Vim 6 :) That explains it. I guess this is a matter of discrepancy between what the user wants to match, and what the OS cares to read. IMHO, what the user wants to match should take priority over whether the OS cares about the case of its filenames. Perhaps for Windows, we could have a 'smartcase' setup for filename completion matching where it's ignorecase only when all the characters are lowercase. Thanks. -- Gerald
Re: filename completion ignorecase for Vim 7
On Sat, 17 Jun 2006, A.J.Mechelynck wrote: Gerald Lai wrote: On Sat, 17 Jun 2006, Bram Moolenaar wrote: Gerald Lai wrote: For Vim 7, it seems that filename completion in the :cmdline ignores case when searching for matches. For example, :e FTab matches both foo.txt Foo.txt This is different from Vim 6 where it only matches Foo.txt Is there any way to revert back to the old behavior? What system? On MS-Windows case of filenames is ignored, on Unix it matters, on Mac it depends. I'm on Windows for Vim 7, Linux for Vim 6 :) That explains it. I guess this is a matter of discrepancy between what the user wants to match, and what the OS cares to read. IMHO, what the user wants to match should take priority over whether the OS cares about the case of its filenames. Perhaps for Windows, we could have a 'smartcase' setup for filename completion matching where it's ignorecase only when all the characters are lowercase. Thanks. -- Gerald IIUC, under Windows it is not possible to have in the same directory two files whose names differ only in case. Let's say you have Makefile in some directory. Creating makefile or MAKEFILE in the same directory will overwrite it. Similarly foo.c, FOO.C and Foo.C are indistinguishable. If Vim tries to open one of them, and another one exists, the OS will deliver it. Thus a 'smartcase' or 'noignorecase' setting for Windows filenames makes no sense. True. But how about filenames that aren't the same? Let's say we have these files on a Windows system: franticallysearching_0_alongfilename.txt franticallysearching_1_alongfilename.txt .. franticallysearching_641237_alongfilename.txt Franticallysearching_641238_alongfilename.txt franticallysearching_641239_alongfilename.txt .. franticallysearching_99_alongfilename.txt and we know we want to edit the file that starts with the capital F. When we do :e FTab would we expect it to match :e franticallysearching_ where we have to follow up by typing in the unknown number for that capital F file? I'd rather have it match :e Franticallysearching_641238_alongfilename.txt where it does what it's told to do. I could care less that Windows treats these files the same: franticallysearching_641238_alongfilename.txt Franticallysearching_641238_alongfilename.txt fraNtIcallysearChiNg_641238_alongfilename.txt to let it affect what I'm searching for. In the end, it's a matter of preference :) -- Gerald
Re: synchronize current working directory - problem with vim7
On Sat, 17 Jun 2006, K.S.Sreeram wrote: [EMAIL PROTECTED] wrote: :he netrw-problems In particular, look at P6. Thanks for the pointer, but unfortunately doing let g:netrw_keepdir = 0 in _vimrc file does not seem to have any effect at all! Here's what happens: 1) run gvim.exe 2) :pwd (output: c:\Vim\vim70) 3) :e c:\Projects\Test\ (shows directory listing) 4) :pwd (output: c:\Vim\vim70) If I have 'set autochdir', then : 3) :e c:\Projects\Test (shows directory listing) 4) :pwd (output: c:\Projects) (I'd like this to be c:\Projects\Test!) So in either case, g:netrw_keepdir=0 doesn't have any effect at all, I even tried with a fresh install of vim7 without any extra plugins and the result was the same! How do I solve this? Chip, Like Sreeram, I was also trying to get g:netrw_keepdir to work but was unsuccessful with Netrw v102b. -- Gerald
Re: Makefile indentation with spaces for line continuation
On Fri, 16 Jun 2006, John Orr wrote: [snip] Another alternative might be to enable expandtab (to get the spaces) and enter the tab characters explicitly - is there any easy way of inserting a tab character when expandtab is enabled? Yes. In Insert mode, you could either (a) hit Ctrl-v followed by Tab (b) hit Ctrl-v followed by Ctrl-i (c) hold down Ctrl and type vi (c) is essentially (b), but has a nice ring to it ;) Entering tab characters explicitly is what I normally do when editing makefiles, since I have 'expandtab' set. See :help i_ctrl-v :help i_ctrl-q HTH. -- Gerald
Re: ***SPAM*** Problem with regexp in macro
On Thu, 15 Jun 2006, Sylvain wrote:
[snip]
I'm using setline() function to replace the line..so I will delete it before
I add mine, it's not very elegant so if anyone has a better way, I will take
it also :-)
[snip]
I modified Vimtip#329 some time ago to be able to swap visual
highlighted words. I also modified it into a function form because it
got long.
The code below has an advantage over tip#329 in that it does not pollute
the search history. In addition, it also works for swapping words on
different lines.
It does, however, clobber marks 'y 'z for positioning purposes. You
can code around this if you want.
===
tested for GVim 6.3 7.0
shift word forward/backward
nnoremap silentA-S-Left _yiw:cal ShiftWord(0)CR
nnoremap silentA-S-Right _yiw:cal ShiftWord(1)CR
vnoremap silentA-S-Left EscS-LeftS-Left:cal
ShiftWord(2)CRmyfC-aaBSEscmzgvg`zog`y
vnoremap silentA-S-Right EscS-RightS-Right:cal
ShiftWord(3)CR_xmyfC-aaBSEscmzgvg`yog`z
function! ShiftWord(...)
let delimiter = \C-a
if a:1 == 0
let @/ = '\w\+\_W\+\%#'
execute normal! ?\CR
let @/ = '\%#\(\w\+\)\(\_W\+\)\(\w\+\)'
silent! s//\3\2\1
execute normal! \C-o
elseif a:1 == 1
let @/ = '\%#\(\w\+\)\(\_W\+\)\(\w\+\)'
silent! s//\3\2\1
execute normal! \C-o
let @/ = '\%#\w\+\_W\+\zs'
execute normal! /\CR
elseif a:1 == 2
let t_paste = paste
set paste
execute normal! g`a\C-v.delimiter
execute normal! g`i\C-v.delimiter
let paste = t_paste
let @/ = '\w\+\_W\+\w*\%#'
execute normal! ?\CR
let @/ =
'\%#\(\w\+\)\(\_W\{-1,}\)\(\w*\)'.delimiter.'\(.\{-1,}'.delimiter.'\)'
silent! s//\4\2\3\1
execute normal! \C-o
elseif a:1 == 3
let t_paste = paste
set paste
execute normal! g`a\C-v.delimiter
execute normal! g`i\C-v.delimiter
let paste = t_paste
let @/ = '\%#\('.delimiter.'.\{-1,}'.delimiter.'\)\(\w*\)\(\_W\+\)\(\w\+\)'
silent! s//\4\2\3\1
execute normal! \C-o
let @/ = '\%#\w\+\_W\+\zs'.delimiter
execute normal! /\CR
endif
nohlsearch
endfunction
===
HTH :)
--
Gerald
Re: Working with windows line endings
On Wed, 14 Jun 2006, Tim Chase wrote: I have set fileformats=unix,dos at the bottom of my _vimrc, but still see the ^M's. My guess is that the file in question has one line that lacks a ^M in the line, and thus, it vim concludes that it must use unix-style line-endings. The likely culprit is the last line in the file. You can clean them all up with :%s/^M$/ where ^M is entered by pressing ^V followed by ^M Once you've gotten them all cleaned up, you can use :set ff=dos and then write the file. If problems keep cropping up in files, somebody else's editor is likely bunging stuff up. Another way to clean up all the ^M's is to do :set ff=unix :w :e Then to convert to DOS format, I'd recommend :set ff=dos eol :w :e HTH. -- Gerald
Re: Problem with example in :help complete()
On Mon, 12 Jun 2006, A.J.Mechelynck wrote: Gerald Lai wrote: On Sun, 11 Jun 2006, A.J.Mechelynck wrote: Gerald Lai wrote: Hi all, [On Windows Vim 7.0, binary at ftp://ftp.vim.org/pub/vim/pc/gvim70.exe] I'm having trouble getting the example in :help complete() to work. When I hit F5 in Insert mode, I get this: Error detected while processing function ListMonths: line 1: E523: Not allowed here I have :set nosecure. Having this instead fixes the problem: inoremap F5 C-r=ListMonths()CR Looks like a bug. I wasn't sure if this has been fixed. -- Gerald Looks to me like a documentation bug. I believe you got it right, and the helpfile got it wrong. Best regards, Tony. Does this mean that expr isn't allowed for complete()? It mentioned at the top of :help complete() that both :map-expr and C-r= were allowed. Isn't imap expr F5 MyFunction() and imap F5 C-r=MyFunction()CR pretty much the same? Or at the very least, the same in terms of security (see :help E523)? -- Gerald Sorry, the expr in the given example had escaped me. They /ought to/ be synonymous, but the C-R= mechanism is older; expr is new in version 7, which means perhaps it hasn't yet got all its bugs ironed out. :help E523 is the same as :help 'secure'. Are you sure this option isn't set unbeknownst to you? When the error happens, what does :verbose set secure? (without the quotes but with the question mark) reply? If it does return nosecure then I guess it's a bug. Yes, it does return nosecure. Everything unchanged, when I tried the C-r= version, it works. It looks like a bug from my side. Do you notice the same? Anybody else? -- Gerald
Re: negative match pattern, again
On Mon, 12 Jun 2006, Yakov Lerner wrote:
On 6/12/06, Gerald Lai [EMAIL PROTECTED] wrote:
On Mon, 12 Jun 2006, Gerald Lai wrote:
On Mon, 12 Jun 2006, Yakov Lerner wrote:
On 6/12/06, Tim Chase [EMAIL PROTECTED] wrote:
I need to match lines using g// (not v//); those lines having
'foo' and NOT having /)\s*;/ anywhere in the line. How do I
write such regex.
Well, there are several ways to go about it. One would be to use
Dr. Chip's logipat script:
http://vim.sourceforge.net/scripts/script.php?script_id=1290
LogiPat does wonders. Thanks.
For the record,
:echo LogiPat('foo!bar')
produces:
\%(.*foo.*\^\%(\%(bar\)[EMAIL PROTECTED])*$\)
Yakov
In addition to the regex above, you can also do:
/^\%(.*)\s*;\)[EMAIL PROTECTED]
It's a little shorter, and probably a little faster since the LogiPat
regex does a \%(..\)* for every character position of the line. The
speed is evident for a long line.
It follows the general form of a negative line search for embedded
search:
/^\%(.*[limit0.*]search[.*limit1]\)[EMAIL PROTECTED]
For example, to match a line that contains foo but does not contain
bar between big and tummy:
/\%(.*big.*bar.*tummy\)[EMAIL PROTECTED]
Sorry, I missed the ^ anchor:
/^\%(.*big.*bar.*tummy\)[EMAIL PROTECTED]
Is the trailing .* necessary there ? Why ?
Nope, not necessary for :g//. I left it there for hlsearch appeal ;)
HTH.
--
Gerald
Re: negative match pattern, again
On Mon, 12 Jun 2006, Charles E Campbell Jr wrote:
Gerald Lai wrote:
On Mon, 12 Jun 2006, Gerald Lai wrote:
On Mon, 12 Jun 2006, Yakov Lerner wrote:
On 6/12/06, Tim Chase [EMAIL PROTECTED] wrote:
I need to match lines using g// (not v//); those lines having
'foo' and NOT having /)\s*;/ anywhere in the line. How do I
write such regex.
Well, there are several ways to go about it. One would be to use
Dr. Chip's logipat script:
http://vim.sourceforge.net/scripts/script.php?script_id=1290
LogiPat does wonders. Thanks.
For the record,
:echo LogiPat('foo!bar')
produces:
\%(.*foo.*\^\%(\%(bar\)[EMAIL PROTECTED])*$\)
Yakov
In addition to the regex above, you can also do:
/^\%(.*)\s*;\)[EMAIL PROTECTED]
It's a little shorter, and probably a little faster since the LogiPat
regex does a \%(..\)* for every character position of the line. The
speed is evident for a long line.
It follows the general form of a negative line search for embedded
search:
/^\%(.*[limit0.*]search[.*limit1]\)[EMAIL PROTECTED]
For example, to match a line that contains foo but does not contain
bar between big and tummy:
/\%(.*big.*bar.*tummy\)[EMAIL PROTECTED]
Sorry, I missed the ^ anchor:
/^\%(.*big.*bar.*tummy\)[EMAIL PROTECTED]
Hello!
These two regex's produce different results; I'm using foo and bar
instead of foo and )\s*;, because its more human readable...
To see the results, use:
vim tst
:set hls
:so pat1
:so pat2
(also, use a fixed font to see this properly in the email)
-- tst --P1--P2-
foo * *
bar
foo junk* *
bar junk
junk foo* *
junk bar
foo junk bar*
bar junk foo
-- pat1
/^\%(bar\)[EMAIL PROTECTED]
-- pat2
/\%(.*foo.*\^\%(\%(bar\)[EMAIL PROTECTED])*$\)
--
To summarize:
Gerald's pattern (P1, pat1) matches the same three that LogiPat's (P2, pat2)
does,
plus it allows one line that P2 rejects.
In the same context, pat1 should instead be:
/^\%(.*bar\)[EMAIL PROTECTED]
and both patterns match the same.
--
Gerald
Problem with example in :help complete()
Hi all, [On Windows Vim 7.0, binary at ftp://ftp.vim.org/pub/vim/pc/gvim70.exe] I'm having trouble getting the example in :help complete() to work. When I hit F5 in Insert mode, I get this: Error detected while processing function ListMonths: line1: E523: Not allowed here I have :set nosecure. Having this instead fixes the problem: inoremap F5 C-r=ListMonths()CR Looks like a bug. I wasn't sure if this has been fixed. -- Gerald
RE: Tab complete filenames
On Wed, 7 Jun 2006, Hari Krishna Dara wrote:
On Wed, 7 Jun 2006 at 11:18am, Max Dyckhoff wrote:
I completely forgot about abbreviations, although the remap that I came
up with doesn't work badly at all because it does check the command pos,
and I never use any other :sf* command than sfind.
If you could send me a zip of your experimental plugin that would be
great, I'd love to give it a go! I'm using vim 7, if that helps.
Thanks!
Max
Sorry, I forgot that your map also has command position as restriction.
Note that abbreviations have an advantage that they don't timeout
[snip]
That's actually the main reason why I suggested cmapping ':' with the
command position restriction. You don't have to wait on it like other
mappings of more than one character. Plus, by default, entering leading
colons on the :cmdline is superfluous. Try ::echo '123'.
Max, my mistake on silent. I couldn't test the mapping, as I was on my
Linux box with Vim 6.3, so I just fired away. I'm glad that it worked
out :)
--
Gerald
-Original Message-
From: Hari Krishna Dara [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 07, 2006 11:16 AM
To: Max Dyckhoff
Cc: Gerald Lai; vim org
Subject: RE: Tab complete filenames
On Wed, 7 Jun 2006 at 9:29am, Max Dyckhoff wrote:
You're working on a large project, so I would advise caution when
doing
tab completion. If you happened to be waiting on an accidental
(slow)
completion like aTab, then hit Ctrl-c to stop it.
Yes, I love how vim is nice and intuitive if Linux stuff is
ingrained in
your every move :)
Nope, no (easy) way. That's just how Vim was implemented. You
could
hack
the source code though.
If you don't have any other commands besides :Sfind beginning with
Sf,
you can just do :Sf instead of the full :Sfind. It's an extra
Shift
keystroke.
That is a shame. Regrettably I have enough coding to do without
hacking
through the source for vim and getting it to compile on Windows; I'm
sure I could do it in Linux in a couple of minutes but that wouldn't
help me at work much! Curses. However I have found a rather nice
solution (see below).
An (untested) alternative I just thought of is to do something
like
this
(Vim 7):
cnoremap silentexpr:
getcmdpos()==1?toupper(nr2char(getchar())):':'
That is rather great, although it doesn't work with the silent tag
in
there. That is, it DOES work, but it is somewhat confusing. Because
of
the silent the result of the :getchar() will not be displayed in
the
command line, meaning if you enter ::sf then you will see on the
command line :f . Note the space after the f. If you now press
backspace the command line changes to :S. Removing the silent
makes
the remapping of : work perfectly.
However I was playing around and came up with an alternative mapping
which makes me grin all over. It is a really logical continuation of
the
remapping of : that you provided:
cnoremap exprsf getcmdpos()==1?'Sf':'sf'
Brilliant! It works exactly as I want, and if you pause after the
s
before typing the f (for timeoutlen) then it aborts the remap and
gives you a lowercase sf.
Thanks for your help Gerald, I hope this thread helps others in
their
time of need!
Max
I wasn't tracking the thread initially, but here is my input. Maps are
not the best approach for tasks like this, you should use
abbreviations.
With maps, if you type sf anywhere on the commandline, it will become
Sf. You don't want that to happen in a filename right (well, if you
are
on windows you might not care most of the time, but there are enough
other cases you should). I suggest you take a look at the cmdalias.vim
plugin that I wrong just for these cases. If you create an alias like
this:
call CmdAlias('sf', 'Sf')
call CmdAlias('sfind', 'Sfind')
it creates abbreviations such that they get changed only when they are
typed at the start of the command-line and when they are by themselves
(e.g, :sfix will not become :Sfix). I also added a tip recently which
shows how to use cmdalias.vim:
http://www.vim.org/tips/tip.php?tip_id=1247
I use cmdalias plugin heavily and haven't faced any issues.
I was also experimenting with a plugin that would lookup filenames as
you type. Except for a bug in Vim completion bothering me, it works
well, and is usable. Instead of using the 'path' setting, it uses tags
created specially for filenames, so it is a lot faster, you can use
regular expressions and you get a dropdown with all the matching
filenames. If you are interested, let me know I will send you a zip.
--
HTH,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Changing a long list of entries with corresponding index
On Tue, 6 Jun 2006, Gary Johnson wrote: On 2006-06-06, Salman Mohsin [EMAIL PROTECTED] wrote: Hi, I have a long list of city names (more than 2,000 of them) in a file, each name on a separate line. I'd like to modify each line so that: ABERFOYLE . . ZURICH Becomes: cities[0] = ABERFOYLE . . cities[2039] = ZURICH Is there a way I could issue a command (or some commands) and achieve the above? :%s/.*/\='cities['.line(.).'] = '.submatch(0).'' The key here is the \=expression in the replacement string. See :help sub-replace-expression You can't mix replacement expressions with other forms of replacement string. That is, the replacement must start with \= and everything that follows must be part of that expression. Using an expression allows the use of functions such as line() to interpolate the current line number. submatch(0) returns the entire string matched by the pattern. See :help line() :help submatch() Adding to this, let's say you have ABERFOYLE on line 5, and ZURICH on line 2044, then this would do what you want: :5,2044s/.*/\='cities['.(line(.) - 5).'] = '.submatch(0).'' -- Gerald
Re: Changing a long list of entries with corresponding index
On Tue, 6 Jun 2006, Charles E Campbell Jr wrote: Salman Mohsin wrote: I have a long list of city names (more than 2,000 of them) in a file, each name on a separate line. I'd like to modify each line so that: ABERFOYLE . . ZURICH Becomes: cities[0] = ABERFOYLE . . cities[2039] = ZURICH Is there a way I could issue a command (or some commands) and achieve the above? The way I'd do it is to use a simple substitute and visincr.vim: :[range]s/^.*$/cities[0]= (goto the first 0 in the first cities[0] line, enter visual-block mode) ctrl-v (goto the last 0 in the last cities[0] line) :I Visincr.vim will transform the visual-block column of zeros into an incremented list. You can get visincr.vim from: http://vim.sourceforge.net/scripts/script.php?script_id=670 or the most up-to-date one from http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs (see Visual Incrementing). visincr.vim also supports date, dayname, monthname, and alphameric incrementing. Chip, Visincr pads trailing spaces as the number of characters needed to represent the end number increases. What I mean is, for the above example, we will be left with: cities[0 ] = ... . . cities[2039] = ... Could it be made to pad nothing? Or, in addition, even leading zeros/spaces/other characters? Also, are there plans for incrementing/decrementing hex octal? -- Gerald
Re: Alt key mapping trouble under windows XP
On Sun, 4 Jun 2006, Eyal Raab wrote: Hi, I'm using VIM 7.0 under windows XP. [snip] What I'm trying to do is to keep using the h,j,k,l in insert mode by mapping the alt-key to them. Something like: :map M-j escji [snip] :map does not include Insert mode mapping. See :help map-modes. This should do what you want: inoremap M-h Left inoremap M-j Down inoremap M-k Up inoremap M-l Right See :help imap. HTH :) -- Gerald
Re: How to use map to exchange g and G keys?
On Fri, 2 Jun 2006, Steven Starr wrote: On Fri, 2 Jun 2006, Steven Starr wrote: I have been using vim since version 4, and never had this problem before. I have always (in VI before vim and thereafter) used the following to exchange the use of the g and G keys in my .vimrc file. :noremap g G :noremap G g Now that I've updated to 7.0, this no longer works. It is hard to retrain my fingers after 20 years. Help! [snip] Now I remember. There was a discussion some time ago on vim@vim.org about this. Read all about it at: Vim 7 mapping change http://groups.yahoo.com/group/vim/message/68788 HTH :) -- Gerald You are my hero! I checked the netrw plugin, and figured out that all I had to do was introduce a bogus map to prevent it from mapping gx. :map x PlugNetrwBrowseX This works great! Thank you so much. I'm back in business. Steve Or you could simply unmap gx in your vimrc :unmap gx as Tony mentioned. You're welcome :) -- Gerald
Re: How to use map to exchange g and G keys?
On Fri, 2 Jun 2006, Steven Starr wrote: I have been using vim since version 4, and never had this problem before. I have always (in VI before vim and thereafter) used the following to exchange the use of the g and G keys in my .vimrc file. :noremap g G :noremap G g Now that I've updated to 7.0, this no longer works. It is hard to retrain my fingers after 20 years. Help! How does it no longer work? Please provide more info; perhaps an example. -- Gerald
Re: problem (expanded): undo/redo messages often immediately hidden
On Sat, 3 Jun 2006, A.J.Mechelynck wrote: Eric Arnold wrote: Have you tried resizing your command line: :set cmdheight=10 I have, and I still see the problem. Have you tried reproducing it? I could, with no problem. I can't test this because my home computer with Vim 7 is down. What happens when you do :set report=0 instead? -- Gerald
Re: How to use map to exchange g and G keys?
On Fri, 2 Jun 2006, Steven Starr wrote: On Fri, 2 Jun 2006, Steven Starr wrote: I have been using vim since version 4, and never had this problem before. I have always (in VI before vim and thereafter) used the following to exchange the use of the g and G keys in my .vimrc file. :noremap g G :noremap G g Now that I've updated to 7.0, this no longer works. It is hard to retrain my fingers after 20 years. Help! How does it no longer work? Please provide more info; perhaps an example. -- Gerald Gerald: Previously, if I wanted to move to line 26, I would just type 26 g Now I have to type 26 gg Previously, to get to the last line, I would only have to type g Now I have to type gg And G seems to have no function at all. Now I remember. There was a discussion some time ago on vim@vim.org about this. Read all about it at: Vim 7 mapping change http://groups.yahoo.com/group/vim/message/68788 HTH :) -- Gerald
Re: Java indenting
On Fri, 2 Jun 2006, Jeff Lanzarotta wrote: Hello, I have a Java indenting questions. When editing C code if I have something like: void function(int x, int y int z) The second line of the declaration indents automatically, right under the first parameter, after pressing enter after the 'y'. How can I get this to happen when I am writing Java code? As suggested previously, :set cindent :set cinoptions+=(4 will only indent the next line by 4 spaces plus a shiftwidth for every subsequent unclosed parenthesis. Unfortunately, if you want Java indent to be smart enough to recognize where you end the opening parenthesis, and to continue from the same column on the next line, you would have to edit $VIMRUNTIME/indent/java.vim itself. This is a lot of work, and would require a peculiar set of conditions to determine when you need to do this type of smart indenting. For instance, how would you determine if the previous line(s) was part of the parameter list of a function header? What if the parameter list stretched for more than 2 lines? Example: public static void function(int x, int y, int z) int z) will have trouble telling whether it needs to do the indent if it only looks at the previous line int y,. That's just a taste of the things you would need to consider when defining an indent file for Vim :) -- Gerald
Re: Reassigning F keys in eVim
On Thu, 1 Jun 2006, John R. Culleton wrote: [snip] functions, e.g., F3 activates an external program. The equivalent map command would be imap F3 Ctrl-O:!pdftex book.texCra [snip] When I try to import such a string it just gets added to the file as text. [snip] Change Ctrl-O to C-O: imap F3 C-O:!pdftex book.texCra See :help ctrl HTH. -- Gerald
Re: vimrun fails
On Sun, 28 May 2006, Juan Lanus wrote: Hi, I'm researching a problem that all ! commands fail, since many versions ago (6.4 more or less), in one of my W2K PCs. Now it has vim70. Also, the EXE installer cannot set the Edit with vim option. Both problens started together. Can't solve it, and I'm quitting after a couple years and now 3 full days. But found that by hiding vimrun.exe I have the functionality back, albeit with the risk of terminating vim sometimes. Here are the symptoms: + !!dir returns E485: Can't read file f:\tmp\VIo20.tmp The process has rights to write there, for example I can :w F:\tmp\qqq from within the same gvim. It's in fact the target of the TMP system variable, anybody can write there. In fact, gvim briefly writes a file, for example F:\TMP\VIi1F.tmp, and complains about not being able to read VIo20.tmp. + :!dir (same as :!path, for example) opens a DOS window with: C:\WINNT\system32\cmd.exe /e:8192 /c dir shell returned -1 Hit any key to close this window... The summoned shell is the one in my COMSPEC definition, it works OK. I was unable to find the meaning of that -1. Also I checked _default.pif for weird permissions, it's enabled for all. There is only one instance of all DLLs and EXEs set by the installer, checked with file search over MyComputer. Also, I searched the registry for all references to vim, gvim, the DLLs and their CLSIDs and deleted the keys before reboot and reinstall. I installed vim70 in the server (NT4) and diffed the registry before and after in an attempt to find something weird. Nothing showed. Well that's all. Yesterday Gerald, suresh and Tony helped me, thanks to them I was able to kep researching and I'm grateful. The source of this problem is out of the reach of my knowledge. I blame vimrun.exe (sorry Vince) but it's so innocent, so simple that even I can read it (I'm a VB/SQL/COBOL/FORTRAN/JS/Java programmer). I just needed a subject. One more thing you can try. Run Sysinternal's Filemon at http://www.sysinternals.com/Utilities/Filemon.html while you do a :!cmd and see what files are accessed that would eventually lead to the error. Likewise, you can also run Regmon at http://www.sysinternals.com/Utilities/Regmon.html to see what is accessing the registry during that time. I have a suspicion it may be some other software getting in the way. You can use Autoruns at http://www.sysinternals.com/Utilities/Autoruns.html to find out what boots with your W2K. HTH. -- Gerald
Re: Per document dictionay modifications?
On Sun, 28 May 2006, Geoffrey Alan Washburn wrote: Gerald Lai wrote: Since 'spellfile' cannot be set from a modeline for security reasons, you can try placing something like this in your vimrc: autocmd BufWinEnter * \ if expand(%:t) == myfile1.txt | \ set spellfile=myspell1.latin1.add | \ elseif expand(%:t) == myfile2.txt | \ set spellfile=myspell2.utf-8.add| \ else | \ set spellfile= | \ endif | Ah, this is actually a bit too heavyweight, as it would mean keeping a rather complicated switching block in my .vimrc, that includes the full path of every LaTeX file for which I have a dictionary. Regardless, your suggestion reminded me that I can set a per directory .vimrc, so I just placed one in my project directory and I seem to be set. This isn't quite as nice as my original proposal because it means it only works if I start vim from within that directory. Somehow I don't see how this is any less of a security risk than allowing what I proposed. I'm not sure, but if you haven't added any words to the spellfile, then setting the 'spellfile' option will not create a blank file, I think. Perhaps then, you can do something like this: (untested) autocmd BufWinEnter,BufWritePost * \ if expand(%) != | \ let l:spellfile = expand(%:p)...encoding..add | \ endif | With this, you can avoid including the full path of every LaTeX file in your vimrc. HTH. -- Gerald
Re: Jumping to Headline in h1Headline/h1
On Fri, 26 May 2006, Tim Chase wrote: [snip] I've also had times where, while I regularly use the fH varient of matters to go forward to the first character in the tag, sometimes I get stung, as in [c] lilook here!/li (with the cursor on [c]). Using fl (eff ell) in attempt to jump to the ell in look, gets hung up on the ell in the li tag. It's simple to just use ; to jump again, but it's one of those minor annoyances. Other matters that can play into the picture include ugly/broken (non-HTML-entity-ized) tag-soup HTML with attributes such as: [c] img src='foo.php?operator='pipsqueek getting to the first p in pipsqueak isn't exactly a trivial task to automate. fw seems to get where we want for both the cases above. I like it for its no-thinking-cap-just-hit-it result. If the result isn't what we want, then keep repeating with ;w. Don't think ;) Then again, some might argue that Vim is about thinking before making a calculated move.. -- Gerald
Re: Can not run any command with ! in W2K
On Fri, 26 May 2006, Juan Lanus wrote: [snip] The problem is that any ! command returns, for example !!dir returns (after a couple seconds): E485: Can't read file x.tmp If I do :!dir a console opens and says: C:\WINNT\system32\CMD.EXE /c dir shell returned -1 Hit any key to close this window... and gvim says Press ENTER or type command to continue, no dir data shows. Any other ! command, and the diff stuff, all complain about the temporary files. [snip] My first assessment would be to check if C:\WINNT\system32\CMD.EXE does exist. Does it? -- Gerald
Re: Can not run any command with ! in W2K
On Fri, 26 May 2006, Juan Lanus wrote: On 5/26/06, Gerald Lai [EMAIL PROTECTED] wrote: My first assessment would be to check if C:\WINNT\system32\CMD.EXE does exist. Does it? Yes it does. I'm not at that PC now, but I assume it's there because I can open DOS windows with the usual shortcut that points to %SystemRoot%\system32\cmd.exe Also, when I use the :! syntax a DOS window containing the error shows. I should have noticed that in the first place :) Well, your problem is a real weird one. What happens when you start cmd.exe manually and do C:\WINNT\system32\CMD.EXE /c dir ? Also try to recall the recent activities you've done on your PC system, e.g., installing new software/hardware, windows update, the way you installed Vim, etc. and generally keep a lookout for weird behavior. Beyond this advice, there's not much a remote help can do unless you can pinpoint what's wrong, or at least provide more information. -- Gerald
Re: viminfo feature not working after upgrade from vim6.2-vim7.0
On Wed, 24 May 2006, Srinivas Rao. M wrote: Thanks Tony, It works after adding those 4 lines into my ~/.vimrc. But i never used to do this in my older version of vim6.3. How come it used to work then ? It may be a possibility but check your system-wide .vimrc at /etc/vimrc for when you had the old 6.3 version. I know mine has the 4 lines that would make Vim remember the last cursor position. -- Gerald
Re: How to get cygwin command line to know where it is
On Wed, 24 May 2006, A.J.Mechelynck wrote: Eric Arnold wrote: Off hand, I can't remember the exact name, but I think that there is a special rc filename that is executed even when it isn't a login shell. [...] Yes, I think so too, and I don't remember it offhand either, but man bash (which is quite long for a manpage) will tell you. Perhaps it's called .bashenv? Not sure. I use ZSH. It's equivalent is .zshenv. -- Gerald
Omnitags [WAS: missing system functions in .vim/systags]
On Sun, 21 May 2006, Yakov Lerner wrote: I created systags per ':help ft-c-omni' suggestion: ctags -R -f ~/.vim/systags /usr/include /usr/local/include and added systags to tags (set tags+=~/.vim/systags). Now I find that system() does not appear in ~/.vim/systags generated as above. This is Linux, and prototype for system() appears in /usr/include/stdlib.h I realize this is ctags issue not vim issue, but maybe someone knows what's the deal ? This is Linux I notice the same thing. After reading your mail, I was thinking about how the popup menu can be made to show more information about the item currently being completed. I was also thinking about standard functions that exist in different programming languages (e.g., system() in the case of C). Combining the two, it's about time someone cataloged the standard functions with concise descriptions that will be displayed when the omnicompletion popup menu is employed. For functions, the prototype can be displayed to show what type of parameters the functions will accept, and also the type of their return values. This is not only limited to functions. It can be extended to standard constants and typedefs, with brief descriptions of each shown in the popup. I went ahead and constructed what I call an omnitags file of the standard C library, based on the ctags format at http://ctags.sourceforge.net/FORMAT with reference to both these websites: http://www.utas.edu.au/infosys/info/documentation/C/CStdLib.html http://www.phim.unibe.ch/comp_doc/c_manual/C/FUNCTIONS/funcref.htm and the GNU C library header files themselves. So far, most of the functions have been included, among a few constants, from these files: assert.h ctype.h math.h stdio.h stdlib.h string.h time.h I try to stay faithful to a particular description format that's very much like the library source code itself. At the moment, I haven't written down the rules I followed, but I feel it's quite self explanatory upon inspection. The file c_std_omnitags, included in the attachment, can be activated by something like :set tags+=~/.vim/c_std_omnitags :setf c (then use Ctrl-x + Ctrl-o) A FileType event can be made to add the omnitags file. The file c_std_omnitags_src is essentially the same file, except that the tags are sorted according to header files. Work is done on the src file. All tags in the src need to be sorted in alphabetical order before being applied to the 'tags' option. I don't have much experience with omnicompletion and the intricacies of C, so I'd like to ask everyone about this omnitags idea. Would this be useful? Has this sort of thing been implemented before for Vim? If this is useful, perhaps we could form a support group to maintain omnitags files from different languages, and also different variants of the same language. The popup menu could be made to include a (cascaded) description popup to allow for a multiple-line desciptions instead of the current single-line descriptions. Feedbacks appreciated :) -- Gerald c_std_omnitags.tar.gz Description: GNU Zip compressed data
Help doc grammar mistakes
I noticed a grammar mistake at :help xfree-xterm scroll down 57 lines Original: ... but not everybody is it using yet.] Should be: ... but not everybody is using it yet.] Also at :help hpterm-color scroll down 1 line Original: ... for a hpterm ... Should be: ... for an hpterm ... -- Gerald
Re: cmapping woes
On Sun, 21 May 2006, Eric Arnold wrote: I've been trying to map cd if it's the first two characters on the :ex line. I've tried all the combinations I can think of. On several of them, I seem to be getting errors as if expr is run in the sandbox (that dog won't hunt). The only one that works at all is the first simple mapping, but that gets painful, of course, when you want to use cd in a search, etc. [snip] cnoremap silent expr cd ( getcmdpos() == 1 ? Cd_plus() : 'cd' ) [snip] This one ought to work. Remove silent. cnoremap expr cd ( getcmdpos() == 1 ? Cd_plus() : 'cd' ) HTH. -- Gerald
Re: How to insert increasing numbers in each line of a file
On Sat, 20 May 2006, Tim Chase wrote: I don't really know how to do this but im sure that there's a solution. I have some file and i need to insert a number before each line and a separator. The number is the line number. Is there any way in vim to do this easily? Well, the canonical way to do this on *nix boxes is just cat -n file.in file.out which can be used in vim with :%!cat -n [snip] I see that Tim and Tony have both mentioned most of the ways of inserting a number before each line. One more alternative: if you are on a *nix box, the premier tool for doing this job is nl. Check out 'man nl'. It lets you set the start number, increment amount, separator string, number column width, empty-line skip, left/right justification with optional leading zeros. For example, :%!nl -s -w4 -v7 -i2 -nln -ba This will use a 2-space separator column width of 4 start with number 7 increment by 2 left justified for all lines (don't skip empty lines) HTH :) -- Gerald
Re: right-to-left text selection
On Sat, 20 May 2006, Jared wrote: On 5/18/2006 1:52 AM, Gerald Lai wrote: On Tue, 16 May 2006, Gerald Lai wrote: I just thought of another more pleasing workaround, if you're interested. Try: nnoremap 2-LeftMouse viwo vnoremap 2-LeftDrag LeftDrag This way, if you wish to select the last character, start with a double click instead of a single click (ala include the last character, damn it!) ;) If you want it to be in SELECT mode after the double click, then use this instead: nnoremap 2-LeftMouse viwoC-g Hi, Gerald. Thanks for the reply. This is a pretty creative suggestion, but I can't get it to work quite right. I tried adding this to my .vimrc: nnoremap 2-LeftMouse viwoC-g vnoremap 2-LeftDrag LeftDrag What's happening is that the last character will be selected, but I'm unable to drag without clicking again. When I click that third time, one of two things happen: * I click it fast enough to trigger the triple-click event, which selects the whole line. * I click slow enough that the default single-click action kicks in, which takes me back to my original problem. The vnoremap line doesn't seem to have any effect. Does Vim recognize that 2-LeftDrag event? That seems like it should solve my problem, but Vim seems to ignore it. Yes, Vim should recognize the 2-LeftDrag event. I verified your problem and found out what happened :) When I tried those mappings on my settings, it works perfectly. When I started it without my settings (that heavily modified mouse mappings), it does as you describe. Stripping down my mappings led me to the solution. Add this extra mapping: nnoremap LeftRelease Nop It ought to work then with the other 2 mappings, and does not disrupt anything from what I can tell. Seems that LeftRelease was doing its job within the double-click. HTH :) -- Gerald
Re: Oddities bugs
On Thu, 18 May 2006, Yegappan Lakshmanan wrote: Hi Gerald, On 5/18/06, Gerald Lai [EMAIL PROTECTED] wrote: Hello all :) Just rehashing the recent threads that suggested some odd behavior with Vim 7. I haven't heard much about them on vim@vim.org, perhaps they've been fixed already. Anyway, here are the archive links all in one place: i_CTRL-E when completeopt has longest http://groups.yahoo.com/group/vim/message/68969 i_C-r= + \C-o http://groups.yahoo.com/group/vim/message/68932 vim7: two issues with insert mode completion http://groups.yahoo.com/group/vim/message/69205 echon space ? http://groups.yahoo.com/group/vim/message/69193 Could someone confirm the status on these issues? Thanks. You have to wait for Bram to come back from vacation to get update on these problems/bugs. Will do, Yegappan. Thanks :) -- Gerald
RE: Mappings fail in gvim...
On Fri, 19 May 2006, Malhotra, Vijendra wrote: -Original Message- From: Gerald Lai [mailto:[EMAIL PROTECTED] Sent: Tuesday 16 May 2006 12:35 To: Malhotra, Vijendra Cc: vim@vim.org Subject: Re: Mappings fail in gvim... On Tue, 16 May 2006, Malhotra, Vijendra wrote: I have the following mappings that work fine on vim but don't on gvim any idea why Window manipulation Ctrl left == Ctrl W l map ^[Oc ^Wl Ctrl left map ^[Od ^Wh Ctrl+Down == Ctrl-W + j map ^[Ob ^Wj Ctrl+Up == Ctrl-W + k map ^[Oa ^Wk You're mapping Vim keystrokes to shell keycodes (that aren't really acknowledged by GVim). A better way would be to map Vim keystrokes to Vim's internal representation of keycodes. On the first pass, we would have: nnoremap C-Right C-wl nnoremap C-Left C-wh nnoremap C-Down C-wj nnoremap C-UpC-wk nmap ^[Oc C-Right nmap ^[Od C-Left nmap ^[Ob C-Down nmap ^[Oa C-Up (should work in GVim at this point) But mapping ^[Oalphabet will cause Vim to wait everytime you press Esc, because there's a possibility that an O followed by an alphabet will come after the Esc. You won't manually type that O + .., of course (but it's possible). It comes whenever you do the Ctrl-combination in the terminal. An improvement would be to represent the shell keycode as one of Vim's internal representation. Then we can use 'ttimeoutlen': set timeout timeoutlen=1000 ttimeoutlen=100 set xF1=^[Oc xF2=^[Od xF3=^[Ob xF4=^[Oa nnoremap C-Right C-wl nnoremap C-Left C-wh nnoremap C-Down C-wj nnoremap C-UpC-wk nmap xF1 C-Right nmap xF2 C-Left nmap xF3 C-Down nmap xF4 C-Up Now Esc won't wait. See :help 'ttimeoutlen' :help xF1 HTH :) -- Gerald What does the nnoremap C-Right C-wl and nmap ^[Oc C-Right really represent? [Pardon me if you know this already, Vijendra :) I'll take this from the top. Sorry for the long post, but I felt it's necessary.] First, you should understand the difference between a map and a noremap. With a noremap, any keystrokes on the right-hand side (RHS) will be interpreted as original Vim keystrokes. By original, I mean that Vim remembers the default actions of every keystroke. For example, with nnoremap F2 G hitting 'F2' will bring the cursor to the last line. With a map, the RHS will incorporate other maps and noremaps, if they exist. For example, we add: nmap G google Now, hitting 'G' is the same as typing 'google'. But hitting 'F2' still takes you to the last line. If the previous noremap was a map instead: nmap F2 G then hitting 'F2' will be the same as typing 'google', because hitting 'F2' would mean hitting 'G' would mean typing 'google'. OK, that covers the map association part. Now about Vim's internal representation of keycodes.. As you are probably aware, applications can read keyboard input via what is known as keycodes. For example, an application sees typing Ctrl-Right_arrow as a keycode of ^[Oc. Unfortunately, keycodes are not standardized. They differ for each terminal and/or OS setting. Since Vim works on multiple platforms, it attempts to unite the representation of keycodes with an intuitive nomenclature (e.g. C-Right, C-a, A-F4, C-A-LeftMouse). Vim will try its best to recognize the keycodes for your platform. Sometimes, it fails. In your case, Vim does not understand that ^[Oc means C-Right. And so you use this map ^[Oc ^Wl which is the same as map ^[Oc C-wl Now Vim, in terminal mode only (since ^[Oc only shows up in terminal mode), understands that when you type Ctrl-Right_arrow, it needs to do a Ctrl-w + l. But GVim still doesn't understand what to do when you type Ctrl-Right_arrow. It never sees ^[Oc. Hence, the way to make both Vim and GVim understand is to use Vim's internal keycodes for everything. Then assign terminal/OS-specific keycodes to Vim's internal keycodes on a platform case-by-case basis. First we start with nnoremap C-Right C-wl that tells Vim GVim to do an original Ctrl-w + l when it encounters a Ctrl-Right_arrow. Then we do nmap ^[Oc C-Right for Vim's sake only. This bridges your terminal's Ctrl-Right_arrow to Vim's Ctrl-Right_arrow. Hope this explains what you wanted to know. If not, please feel free to ask the mailing list :) -- Gerald
Re: Split not visible in putty
On Fri, 19 May 2006, Sanjaya wrote: I searched the vim mailing list archive at http://marc.theaimsgroup.com/ regarding the problems I am having but couldn't find any related threads. This thread has a mention of your problem: http://www.webservertalk.com/archive295-2005-2-906323.html I got this by entering these keywords in Google: vim tiny no split I want to edit a multiple files in vim (through putty but not tried on the display..) but when I do :split two.c the window isn't split and I can still see the split command ... [snip] Tiny version without GUI. Features included (+) or not (-): [snip] +wildignore -wildmenu -windows +writebackup -X11 -xfontset -xim -xsmp [snip] You're out of luck. The tiny version is compiled with no multiple windows support (-windows). You cannot do :split. See :help feature-list and search for /^windows. HTH. -- Gerald
Re: Extending Vim7 with plugins
On Fri, 19 May 2006, Meino Christian Cramer wrote: [snip] IMHO the help files are only for those, who are know already, what they are searching for. A newbie gets hopelessly lost. The help files are very extensive. Because of this, it has to cover each topic in a brief, accurate and concise way. To do otherwise would cause bloat, confusion and inconsistency. Example: Q: Why is my set history=num reset to num = 20 regardless where in .vimrc I will set it? A: set nocompatible will reset that to 20 Here's the thread for this discussion: History and set history=xx http://groups.yahoo.com/group/vim/message/68390 This issue of the 'compatible' option clobbering other options when the option was set was debated in the thread above. There are valid reasons to all points of view. A help history will no help here. helpgrep will lead to about 200 hits, which needs searched through until the clue is found. [snip] A helpgrep with a few hits requires unique words. Unfortunately, history and compatible are common words. Suppose your are starting to learn vim. You have learned to edit text basically and to do some tricks to impress your friends of the World of Notepad category. So nice so far. Now you want to delete all lines in a file, which conatin a certain pattern. What is keyword here ? helpgrep will find some hits, but I found none telling me the magic: g/pattern/d _IF_ you know already the g trick...ok, you may fnd it in the helpfilesbut as a newbie? [snip] I would advise those who wish to be more proficient at Vim to look through http://www.vim.org/tips It makes a good starting place to try little things. Zzapper's list of tips should well include the :global command, and things you can do with it: http://www.vim.org/tips/tip.php?tip_id=305 There are many other such tip lists on the internet. I would like to have a context-helpfile or something like a cross reference, which maps natural language search topics to vim speek. Something like Lagenscheidts encyclopedia VIM - English English - VIM [snip] Yes there is such a thing: the Vim FAQ http://vimdoc.sourceforge.net/htmldoc/vimfaq.html I've included this as a Vim tip at http://www.vim.org/tips/tip.php?tip_id=1172 -- Gerald
RE: Visual Block: $ vs. ^ inconsistency?
On Fri, 19 May 2006, Suresh Govindachar wrote: James Vega wrote: On Fri, May 19, 2006 at 07:47:41AM -0700, Suresh Govindachar wrote: In visual block mode (C-V) one can get jagged right edges by hitting $. But hitting ^ does not result in jagged left edges. Why the inconsistency? Is it something in my set-up? The leftmost column of a line is always 0. I was asking about ^, not 0 -- there is a difference between 0 and ^. ^ refers to left-most non-blank. That's an interesting idea, Suresh. I'd like to see what happens then when I do ggC-v^o$G -- Gerald
Re: Vertical selection
On Thu, 18 May 2006, John Love-Jensen wrote: Hi Eddine, Is it possible to make a vertical selection in a text, to have a rectangular selection in the text ? If so, how ? Yes, you are looking for the Visual mode blockwise. ^V to initiate Visual mode blockwise. Use movement keys to get to where you want the block to span. Use y (yank) or x (cut) to put the block into the register (as a block) Use p (put) to insert the register (as a block) into the buffer For more info... :help CTRL-V :help ' :help ' There are probably a zillion variants and tricks with Visual mode blockwise. I find that these simple ones suffice for all my needs. One more extremely useful thing to do in Visual Block mode is to hit I or A (capital) to insert/append the same text for all the lines that have been selected. -- Gerald
Re: Vertical selection (fwd)
[I wasn't sure if Eddine sent this out to everybody, so I'm forwarding this to the list.] You're welcome, Eddine :) -- Gerald -- Forwarded message -- Date: Thu, 18 May 2006 22:20:24 +0200 From: Baha-Eddine MOKADEM [EMAIL PROTECTED] To: Gerald Lai [EMAIL PROTECTED] Subject: Re: Vertical selection Once again, Victor, Gerald, Eljay and J?rgen thank for all of you !!! It's a real pleasure to get quick and precise responses. Thank you again. Eddine
Oddities bugs
Hello all :) Just rehashing the recent threads that suggested some odd behavior with Vim 7. I haven't heard much about them on vim@vim.org, perhaps they've been fixed already. Anyway, here are the archive links all in one place: i_CTRL-E when completeopt has longest http://groups.yahoo.com/group/vim/message/68969 i_C-r= + \C-o http://groups.yahoo.com/group/vim/message/68932 vim7: two issues with insert mode completion http://groups.yahoo.com/group/vim/message/69205 echon space ? http://groups.yahoo.com/group/vim/message/69193 Could someone confirm the status on these issues? Thanks. -- Gerald
Re: Multiline file appearing in one line under Vim
On Wed, 17 May 2006, Baha-Eddine MOKADEM wrote: 2006/5/17, Georg Dahn [EMAIL PROTECTED]: Hi! My guess is: notepad breaks at column 1024. In notepad the first two lines of your file have exact 1024 characters. This could be a notepad limitation. Best wishes, Georg Is there a way to make profit of this kind of limitation. Or is there a way to cut the single line so I can have n lines of the same L length ? Perform: :g/\%1025c/wh getline(.)=~@/|s//\r/|endw This will slice the single line into multiple lines of 1024-length. HTH. -- Gerald
Re: echon space ?
On Tue, 16 May 2006, Eric Arnold wrote: Does anybody understand why trailing spaces in an echon string don't actually show up? echon \ngimme let inp = getchar() echon nr2char(inp) I think echo/echon is doing fine. It's getchar() that's eating up trailing spaces. Compare @a's for: :redir @a | echon 123 | call getchar() | redir END :redir @a | echon \n123 | call getchar() | redir END :redir @a || echon 123 | call getchar() | redir END The \n or previous ex command | has something to do with it. (tested on Vim 6.3) -- Gerald
Re: gvim when x server is shut down
On Wed, 17 May 2006, Dennis Nezic wrote: when i exit my wm (e16), since it doesn't (and shouldn't) close any other programs, gvim is stuck without an x server, and doesn't handle this loss gracefully. effectively, it's as if it was kill -9'ed ... and thus leaves temporary files behind, which i later have to labouriously clean up. can it not do something better like simply close down if no changes were made to the file (and close any temp files). and, i guess, leave the temp files behind if changes were made (as it currently does in all cases :\). You could try something like :au VimLeave * if v:dying | quitall! | endif if it helps. See :help v:dying. HTH. -- Gerald
Re: How to auto-set font and size?
On Mon, 15 May 2006, Donal wrote: Now that my primary issue of getting Windows Explorer to use gvim to open .prg files has been fixed, I have 2 further issues. I will seperate them so they do not get confused... My eyes are not what they once were, and I use a high-res monitor. I don't want to decrease my screen res as I am used to all the real estate I need to keep multiple things going at once :) but I need to increase the default font size for my program files in gvim. I need a line for _vimrc, I suppose, that will set the default font to Lucida Console and 14pt. Select your font to your liking via Edit - Select Font... Once you're done, do :echo guifont Copy what you see to set the option 'guifont' (see :help 'guifont'). It'd probably look something like :set guifont=Lucida\ 14 (spaces are escaped with backslashes) You can place this in your vimrc. HTH. -- Gerald
Re: How to auto-set font and size? (fwd)
[You're welcome :) I think you may have wanted to send this to the list.] -- Forwarded message -- Date: Mon, 15 May 2006 13:20:09 -0500 From: Donal [EMAIL PROTECTED] To: Gerald Lai [EMAIL PROTECTED] Subject: Re: How to auto-set font and size? At 01:11 PM 5/15/2006, Gerald wrote: On Mon, 15 May 2006, Donal wrote: Now that my primary issue of getting Windows Explorer to use gvim to open .prg files has been fixed, I have 2 further issues. I will seperate them so they do not get confused... My eyes are not what they once were, and I use a high-res monitor. I don't want to decrease my screen res as I am used to all the real estate I need to keep multiple things going at once :) but I need to increase the default font size for my program files in gvim. I need a line for _vimrc, I suppose, that will set the default font to Lucida Console and 14pt. Select your font to your liking via Edit - Select Font... Once you're done, do :echo guifont Copy what you see to set the option 'guifont' (see :help 'guifont'). It'd probably look something like :set guifont=Lucida\ 14 (spaces are escaped with backslashes) You can place this in your vimrc. Thank you very much. For any that are interested, the exact line for my _vimrc is set guifont=Lucida_Console:h14:cANSI It works perfectly! :) --- Donal, SysAdmin of the Brewers' Witch BBS http://www.brewich.com mailto:[EMAIL PROTECTED] ICQ:422928 CMA: 20639 WitchVox: 1494 Soc.Religion.Paganism (Modkinus Primus, Ret.) news:soc.religion.paganism Moderator: Houston Pagans Online http://groups.yahoo.com/houstonpagansonline Council of the Magickal Arts (Brewers Society Coord, Pooh-burbanite) http://www.magickal-arts.org Pagans' Night Out (Founder) http://www.paganhouston.com/pno Everquest II: Florence Sopher (Templar Sage) Co-Guild Leader of Helanic Frost; Lucan D'Lere server http://setiathome.ssl.berkeley.edu My BOINC Credits: 2579.85 Avg: 29.44 ET's found: 0
Re: Moving windows horizontally from col to col
On Tue, 16 May 2006, Marc Weber wrote: I like the way you can move windows in wmii. 1 | 2 --+-- 3 | 4 if your cursor is in window 1 and you move the window to the right you get | 1 3 | 2 | 4 [improved illustrations] So I've tried to implement this in vim.. It works (not for preview window) and is ugly.. Perhaps you want to try it out or have some ideas how to improve it? I'm creating two unnecessary buffers to not accidently exit vim.. [snip] Not going as far as writing a full script to move windows around, what I'd do to achieve the above are the following commands: :windo wincmd K :3wincmd w :wincmd H You can also check out WinWalker at http://www.vim.org/scripts/script.php?script_id=1522 HTH :) -- Gerald
Re: Mappings fail in gvim...
On Tue, 16 May 2006, Malhotra, Vijendra wrote: I have the following mappings that work fine on vim but don't on gvim any idea why Window manipulation Ctrl left == Ctrl W l map ^[Oc ^Wl Ctrl left map ^[Od ^Wh Ctrl+Down == Ctrl-W + j map ^[Ob ^Wj Ctrl+Up == Ctrl-W + k map ^[Oa ^Wk You're mapping Vim keystrokes to shell keycodes (that aren't really acknowledged by GVim). A better way would be to map Vim keystrokes to Vim's internal representation of keycodes. On the first pass, we would have: nnoremap C-Right C-wl nnoremap C-Left C-wh nnoremap C-Down C-wj nnoremap C-UpC-wk nmap ^[Oc C-Right nmap ^[Od C-Left nmap ^[Ob C-Down nmap ^[Oa C-Up (should work in GVim at this point) But mapping ^[Oalphabet will cause Vim to wait everytime you press Esc, because there's a possibility that an O followed by an alphabet will come after the Esc. You won't manually type that O + .., of course (but it's possible). It comes whenever you do the Ctrl-combination in the terminal. An improvement would be to represent the shell keycode as one of Vim's internal representation. Then we can use 'ttimeoutlen': set timeout timeoutlen=1000 ttimeoutlen=100 set xF1=^[Oc xF2=^[Od xF3=^[Ob xF4=^[Oa nnoremap C-Right C-wl nnoremap C-Left C-wh nnoremap C-Down C-wj nnoremap C-UpC-wk nmap xF1 C-Right nmap xF2 C-Left nmap xF3 C-Down nmap xF4 C-Up Now Esc won't wait. See :help 'ttimeoutlen' :help xF1 HTH :) -- Gerald
Re: echo question
On Sun, 14 May 2006, Yakov Lerner wrote: On 5/14/06, Jared [EMAIL PROTECTED] wrote: I have a simple question that I can't seem to figure out. When I use the echo command to echo a statement on my open window, it simply displays that message in the status bar. However, if I use echo in a function, it adds Please ENTER or type command to continue after it. How do I make it not do that? Eg, I just want it to display the message, not prompt me to press a key. Try 2 things (1) add :redraw before the :echo in question (2) if that doesn't help, make message shorter. I noticed that if message is longer than screen width-15, it cases the prompt. You could also readjust the height of the command-line dynamically: let msg = str let len = strlen(substitute(msg, ., x, g)) let t_ch = cmdheight let cmdheight = len / (columns - 15) + 1 echo msg let cmdheight = t_ch See :help 'cmdheight' :help strlen(). HTH :) -- Gerald
Re: Is there a way to move tabs around via the mouse?
On Sun, 14 May 2006, Eric Arnold wrote: On 5/9/06, Gerald Lai [EMAIL PROTECTED] wrote: On Tue, 9 May 2006, Hari Krishna Dara wrote: On Tue, 9 May 2006 at 10:29am, Yegappan Lakshmanan wrote: Hi Scot, On 5/9/06, Scot P. Floess [EMAIL PROTECTED] wrote: Is there anyway to move the tabs in a tabbed window around using the mouse? I see the menu options for a tab when I right click on the tab. I also saw the tabm [N] option I can set. However, is it possible to set an option that will allow me to click on a tab and drag it either right or left? No. Moving the GUI tabs (re-ordering) using the mouse is not yet supported. - Yegappan It should be possible to save the current windows (something like the way ZoomWin does), and open the windows as they are in a new tab page, and close the old tab (note the order, this works with modified buffers with 'nohidden' set). Sorry, I have no code that can make this work, just an idea. Vim 8 - detachable tabs? ;) -- Gerald I'm not sure I got all that right, but I think WinWalker.vim does similar things. I was thinking about the Opera browser and how its tabs can be dragged and placed around with the mouse. Firefox can do the same too, but Opera's drag and drop is more visually stunning. Also, detachable tabs could be flexible enough to even be dragged and attached to another instance of Vim. Just some ideas :) Fancy stuff, nothing we can't do without. -- Gerald
Re: sourcing vimrc files
On Sun, 14 May 2006, Jared wrote: [snip] Longer and more complicated, but now I can check to see if the file exists before sourcing it. However, this also causes a problem: when I try to source the file containing this function, it gives me an error saying that it cannot replace the function because it is currently in use. If I remove the !, it still gives me an error because it already exists. Any ideas how to work around this? Or if you have a different/better way of doing this, I'm certainly open to suggestions. :-) This is on Windows XP. Thanks. Encase your function like this: if !exists(*Source_vimrc) function Source_vimrc() ... endfunction endif The reason you're getting the error is because you're sourcing the file (vimrc) that produced/will override the function (Source_vimrc) you're using at the moment. A few words of advice to source your vimrc cleanly: 1. Define your functions in vimrc with function! so that when sourced again, the functions will be overwritten. 2. Keep your autocmds in an augroup so that if it's sourced again, you can delete the augroup and redefine it instead of adding more of the same autocmds. 3. If you're using the FuncUndefined autocmd, delete those functions that have been defined before. For examples 2 3, augroup vimrc delete augroup autocmd! ... silent! delfunction MyFuncInOtherFile autocmd FuncUndefined MyFuncInOtherFile source $HOME/.vim/autoload/MyFuncInOtherFile.vim ... autocmd ... ... augroup END HTH :) -- Gerald
Re: set highlight color?
On Fri, 12 May 2006, Jared wrote: How do I change the background color used for cursorline in Vim 7.0? I'd like to make it a few shades darker. It looks like it can be set with hl-CursorLine, but I can't figure out how to actually do it. I currently use the following setting in .gvimrc to set the color scheme: highlight Normal guifg=white guibg=black Any suggestions? Thanks. Just like you did with Normal, you can do with CursorLine. For example: :highlight CursorLine guibg=Grey20 To see what it's current set to: :hi CursorLine HTH. -- Gerald
Re: Indentation question...
On Fri, 12 May 2006, John Schmerge wrote:
Hi all,
I've got a question about changing vim's indentation behavior for
c/c++:
Is it possible to get the editor to insert tabs to signify *indentation*
level, and to insert spaces to align text *after* the indentation? I've
been trying to find some sort of option that allows for this and haven't
found any sort of solution (short of creating my own c indentation file).
To explain a little bit better, the following code fragment (with tabs
replaced by '---' and spaces replaced by backquote characters) is an
example of the indentation style that I want vim to produce:
/*
`* This is a comment note the spaces aligning the continuation lines
`*/
int main(int argc, char ** argv)
{
---/*
---`* note that the 2nd 3rd parameters are aligned with spaces...
---`* Vim indentation would insert more than a single tab on these
---`* lines; causing a change in tab size to munge the code formatting.
---`* This is the main thing that I want to change.
---`*/
---printf(This is a printout with a value(%d)\n,
---```25,
---```bl);
---/* note the spaces inserted between the tabs and logic operators */
---if ( (condition1 condition2)
---```|| ( condition3
---`` condition4) )
---{
--doSomething();
---}
---switch (condition)
---{
---`case '1':
--doSomething();
--break;
---`default:
--break;
---}
}
In essence, I want vim not to replace spaces by tabs, and insert spaces
instead of tabs in certain situations. Is this possible?
The answer to your question is: yes, it's possible :)
There's a catch: you need to define the certain situations where you
want Vim to insert spaces instead of tabs, as mentioned above.
In other words, can you define a general (and consistent) set of rules
for indentation vs. alignment that would produce the output you just
showed above?
That means, you start with an input source file, run it through a
function, and then out comes the output source file that has its
indentation (with tabs) and alignment (with spaces) determined. That
function needs to know how to do it.
Also, have a look at :help 'smarttab' :help cinoptions-values.
--
Gerald
Re: Set color block of text
On Fri, 12 May 2006, Richard Emberson wrote: Is there a way in a vim script to set the color (fg/bg) to a block of text? say from line 12 to line 15 and from column 4 to column 9. The text in this block can be anything, not syntax. Perhaps something like :match Todo /\%11l\%16l\%3c\%10c/ HTH. -- Gerald
RE: Bug i_CTRL-X s and arrow
On Wed, 10 May 2006, Suresh Govindachar wrote: [snip] Confirmed for 7.0 release. It seems that i_up-arrow i_down-arrow work un-intuitively as compared to i_ctrl-p i_ctrl-n, respectively. Not exactly -- the bug is _NOT_ un-intutiveness. To both Suresh and Edward: please read my posting again :) I did not mention anything about it being a bug. I merely confirmed what was being observed, so as to point out that we're all seeing the same thing. After confirmation that it not a specialized matter can we discuss the topic further. The bug, present in 7.0.10, is that both of Bram's intents, viz., Using the cursor only selects another entry, it doesn't insert it. Use Enter to insert the match (original text). are _not_ happening. 1) UP -- just doing 1 UP -- after i_CTRL-X s actually inserts an entry -- Bram says it will not, but it does in fact. The Up did not insert the entry. The C-xs did. The Up moved the selection back to the original. If you like the original, you can type Enter or C-y. If you like to go back to the original from any (other) selection, you can type C-e. Moreover, even though the message at the bottom says Bram's intent Back at original, the word inserted is in fact the match 1 of 100 word -- after exactly 1 UP after i_CTRL-X s. No, word was inserted -- after exactly and only after i_CTRL-X s. The 1 UP was done after the fact. 2) Then -- after doing zero or more UP and DOWN -- hitting ESC will leave that inserted match 1 of 100 word in the buffer rather than Bram's intent of leaving the buffer unmodified. Yes that's correct - zero or more Up and Down's will never insert anything. But the buffer has already been modified by C-xs. I don't think that was Bram's intent of leaving the buffer unmodified. Does it say somewhere in the docs? It's like you saw the first suggestion given, moved up and down many times to look at the other suggestions. Then: 1. If you were satisfied with the first suggestion, you'd hit Esc to quit from the pop-up menu with the first suggestion intact. 2. If you wanted another suggestion you've selected with Up and Down, you would hit Enter or C-y to accept it. 3. If you wanted to go back to the original, you may hit C-e anytime. POSTSCRIPT: With 7.0.10, in insert mode, enter the command: C-XsC-PDown What shows up is what is supposed to show up after entering only C-Xs. Correction: this is not what is supposed to show up after entering only C-xs. What is described in POSTSCRIPT is a wish. But Bram has mentioned (and chosen) that users will get the first suggestion inserted _as soon as_ C-xs is typed. -- Gerald
i_C-r= + \C-o
[GVim 7.0 release for Windows] This is how I do my PageUp/Down: inoremap PageDown C-oC-dC-oC-dC-oC-y inoremap PageUp C-oC-uC-oC-uC-oC-e If I do inoremap PageDown C-r=\ltC-o\ltC-d\ltC-o\ltC-d\ltC-o\ltC-yCR inoremap PageUp C-r=\ltC-o\ltC-u\ltC-o\ltC-u\ltC-o\ltC-eCR it does not work. This inoremap PageDown C-r=\ltC-o\ltC-d\ltC-d\ltC-yCR inoremap PageUpC-r=\ltC-o\ltC-u\ltC-u\ltC-eCR works. Sticky \C-o while in C-r=? -- Gerald
RE: Column Selection
On Thu, 11 May 2006, Suresh Govindachar wrote: Elias Chatzigeorgiou wrote: I use the mswin behaviour and insert mode for editing (source mswin.vim and set insertmode in _vimrc ) To enable column selection I use the sequence: CTRL-O, g, CTRL-H and hold the SHIFT during the selection. Is it possible to simplify the above key sequence? Ideally I would like the cream-for-vim equivalent (ALT-SHIFT to enable column selection) - but I don't like ice-cream-s :-) Try creating the following insert-mode map: :imap A-c c-ogc-h and then using the sequence Alt-c and hold SHIFT etc. If you like it, place imap A-c c-ogc-h in your vimrc file. --Suresh I have these mappings in my vimrc that do a Visual Block mousedrag. It was a simple modification to make it a Select Block. Place in vimrc. nnoremap A-S-LeftMouse mzLeftMouseC-vg`zoC-g inoremap A-S-LeftMouse EscC-vg`^mzEscgiLeftMouseC-oC-vg`zoC-g vnoremap A-S-LeftDragLeftDrag vnoremap A-S-LeftMouse C-vLeftMousemzgvg`zC-g Holding down Alt-Shift and click-dragging with the left mouse button in any mode should start Select Block mode. HTH :) -- Gerald
RE: Column Selection
On Thu, 11 May 2006, Hari Krishna Dara wrote: On Thu, 11 May 2006 at 6:37pm, Gerald Lai wrote: On Thu, 11 May 2006, Suresh Govindachar wrote: Elias Chatzigeorgiou wrote: I use the mswin behaviour and insert mode for editing (source mswin.vim and set insertmode in _vimrc ) To enable column selection I use the sequence: CTRL-O, g, CTRL-H and hold the SHIFT during the selection. Is it possible to simplify the above key sequence? Ideally I would like the cream-for-vim equivalent (ALT-SHIFT to enable column selection) - but I don't like ice-cream-s :-) Try creating the following insert-mode map: :imap A-c c-ogc-h and then using the sequence Alt-c and hold SHIFT etc. If you like it, place imap A-c c-ogc-h in your vimrc file. --Suresh I have these mappings in my vimrc that do a Visual Block mousedrag. It was a simple modification to make it a Select Block. Place in vimrc. nnoremap A-S-LeftMouse mzLeftMouseC-vg`zoC-g inoremap A-S-LeftMouse EscC-vg`^mzEscgiLeftMouseC-oC-vg`zoC-g vnoremap A-S-LeftDragLeftDrag vnoremap A-S-LeftMouse C-vLeftMousemzgvg`zC-g Holding down Alt-Shift and click-dragging with the left mouse button in any mode should start Select Block mode. HTH :) -- Gerald I created a tip about this long back: http://www.vim.org/tips/tip.php?tip_id=743 -- Thanks, Hari Yes, I remember being inspired by this tip to write the version I have now :) As the tip suggests, I didn't really want the first click to move the cursor and then start the Visual Block mode. I wanted a Visual Block highlighted from the cursor's original position to its destination upon the first click. Then I extended it so that it would work in Insert mode. This was tricky to get the Insert cursor positioning correct all the time. -- Gerald
RE: Commenting out a block of text
On Wed, 10 May 2006, David Fishburn wrote: As Yakov mentioned, your question recently came up in this list. It started with http://www.vim.org/tips/tip.php?tip_id=346 Incidently I just updated this tip (May 8th) to handle the case where Vim automatically indents the line while you are in the process of adding the ending and starting comments. This has the nasty side effect of changing the location of ', so you end up adding the beginning tag in the wrong spot. Thanks for the heads up. I would suggest saving and setting 'paste' instead of 'indentkeys'. The 'paste' option is more thorough when it comes to these sort of things. -- Gerald
Re: basic question: quick split like awk
On Wed, 10 May 2006, Ben K. wrote:
Hi,
Is there a way to split a line automatically like awk would?
Given A quick brown fox jumped over ,
awk '{print $3}' ... == brown
or like in perl
split(':',$line)...
I'd like to do within vim something like
:s/{some notation}/\3
without having to define the pattern
:s/\(\S\+\) \(\S\+\) \(\S\+\) ... /\3 == brown
using white space, and if needed, by defining my own separator
The regex to search for the nth occurence of a search is
/^\%(.\{-}\zssearch\)\{n}
Given a line like
:A:quick:brown:fox:jumped:over
you can search for the nth word with
/^\%(.\{-}:\zs[^:]*\)\{n}
For example, if you want fox, then do
/^\%(.\{-}:\zs[^:]*\)\{4}
You can easily modify the regex to use whitespace as delimiters.
HTH.
--
Gerald
RE: Indentation and blank lines
On Tue, 9 May 2006, Arm?nio Pinto wrote:
-Original Message-
From: J?rgen Kr?mer [mailto:[EMAIL PROTECTED]
Sent: ter?a-feira, 9 de Maio de 2006 16:04
To: vim mailing list
Subject: Re: Indentation and blank lines
Hi
Arm?nio Pinto wrote:
I'm using Vim to edit Java code. There's an annoying behavior
that I would like to fix, but haven't had any success yet. The problem
is that the indentation disappears when you insert blank lines. For
example (and suppose that the ? it's a tab):
Vim does...
??for (String name: names) {
???System.out.println(name=+name);
???System.out.println(Done);
??}
... and I would like it to be:
??for (String name: names) {
???System.out.println(name=+name);
???
???System.out.println(Done);
??}
That is, after the first println I hit ENTER twice and I and would
like that the blank line remains with indentation. How can I do this?
insert any character and delete it immediately. You can put this in a
mapping which replaces the original behaviour of ENTER:
:inoremap cr crXbs
Regards,
J?rgen
It works, thanks! Isn't this a kind of nasty trick? :-) Does anyone know a
cleaner solution?
Arm?nio Pinto
Not a nasty one really. J?rgen's suggestion works well.
You can do
:inoremap CR CRLeftRight
if it eases your conscience ;)
--
Gerald
Re: fast file opening / find file as you type
On Tue, 9 May 2006, Benjamin Reitzammer wrote: [snip] Regarding :find. It does not do path-full completion, and no 'incremental completion menu'. To write such plugin, you'd need to process every typed character. Yes I tried, :find and that it's not doing completion of my filename, is something that makes it a lot less useful. Sure it broadened my vim skills ;) but it's still not as good as the described solution the jedit plugin offers. [snip] This has been suggested in the list before (by Hari, I think). Put these lines in your vimrc: == command! -nargs=? -complete=custom,PathFileComplete -bang -bar Find findbang args function! PathFileComplete(ArgLead, CmdLine, CursorPos) return substitute(globpath(path, a:ArgLead.*), [^\n]\\+/, , g) endfunction set wildmenu wildmode=longest:full == Then instead of doing :find partial filename do :Find partial filename (notice the capital F) Completion will work now. :Find is :find with completion. Take note of what J??rgen Tim had to say. :Find will look in the directories specified in the option 'path', as J??rgen mentioned. After typing your partial filename, you can hit the Tab button, as Tim mentioned, to complete the filename and/or bring up the wildmenu so you can scroll through the matching filenames from left to right. You can also type Ctrl-d to list the matching filenames. HTH :) -- Gerald
Re: Vim 7 mapping change?
On Tue, 9 May 2006, Robin Becker wrote: I am trying out Vim 7.0 and see a major difference in the way my old mappings work. I have for many years mapped g to G so I can use the lower case g to jump around the file instead of shift+g. Under 6.4 and earlier that works well, but with vim 7 I see a big delay between hitting the g key and the jump to the bottom of the file. Same if I type 1g. It seems as though the mapping is not happening immediately (I assume to allow for a follow up character to be recognized). Is there any way to fix this or is it a permanent feature? In 6.4 even though there are similar possibilities for g as a start character I don't see this delay. Just confirming, did you do :noremap g G :noremap G g ? After which, if you did :map g you should just see one entry of g. -- Gerald
Re: Is there a way to move tabs around via the mouse?
On Tue, 9 May 2006, Hari Krishna Dara wrote: On Tue, 9 May 2006 at 10:29am, Yegappan Lakshmanan wrote: Hi Scot, On 5/9/06, Scot P. Floess [EMAIL PROTECTED] wrote: Is there anyway to move the tabs in a tabbed window around using the mouse? I see the menu options for a tab when I right click on the tab. I also saw the tabm [N] option I can set. However, is it possible to set an option that will allow me to click on a tab and drag it either right or left? No. Moving the GUI tabs (re-ordering) using the mouse is not yet supported. - Yegappan It should be possible to save the current windows (something like the way ZoomWin does), and open the windows as they are in a new tab page, and close the old tab (note the order, this works with modified buffers with 'nohidden' set). Sorry, I have no code that can make this work, just an idea. Vim 8 - detachable tabs? ;) -- Gerald
Re: Auto-Commands popup message
On Mon, 8 May 2006, Mark Volkmann wrote: On 5/8/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Mark Volkmann wrote: When I start Vim 7 under Windows XP, I always get a popup message dialog that says Auto-Commands. Is there a way to prevent this? Check your startup scripts for a lonely au command. You can use :scriptnames to see what scripts are being used. I have the following in my _vimrc file. autocmd FileType ruby,eruby set omnifunc=rubycomplete#Complete I thought I needed those in order to use completion when editing Ruby source files. If that's not true, I'll remove them. Otherwise, can I tell autocmd not to display that message popup? Those 2 lines need to be in 1 line: autocmd FileType ruby,eruby set omnifunc=rubycomplete#Complete If you'd like to make an autocmd multiple lines, use backslash \: autocmd FileType ruby,eruby \ set omnifunc=rubycomplete#Complete See :help line-continuation. HTH. -- Gerald
RE: Commenting out a block of text
On Sun, 7 May 2006, Peter Slizik wrote: Use \t for a normal tag wrap. Use \T for a markup tag wrap of the form a../a. Dear Gerald, seems that \t and \T do the same thing. After a quick look at the source, I think you intended to support /* */ and HTML tags differently. For me, both mapping work the second way. That is, aaa (Pressing \t) Opening tag? /* becomes /*aaa//* Maybe there's some problem with magicness or whatever. Yes, I see. You have 'ignorecase' set. I don't. You could either do :set noignorecase or change these lines if a:mode[1] == T ... elseif a:mode[1] == t to if a:mode[1] ==# T ... elseif a:mode[1] ==# t Well, this makes me wonder how many scripts I've written/posted with the assumption that 'ignorecase' is not set :) Do most of you script writers keep this in mind? -- Gerald
Re: Newbie problem: Beginners script pitfall
On Sun, 7 May 2006, Meino Christian Cramer wrote: Hi, [snip] OK, if you're just starting out, before writing scripts, you would need to jump through a few hoops first. Please pardon me if you are already familiar with what I'm about to write. I'm just taking it from the top. First, get familiar with the :help system of Vim. You will be using it a lot, so make sure you understand :help help-context It consists of foru lines: :normal gg :normal %s/^[ ]*//g :normal gg :normal %s/[ ]*$//g Other versions I tried were: :normal gg :normal %s/^[ ]*//gCR :normal gg :normal %s/[ ]*$//gCR and :normal gg :normal :%s/^[ ]*//gCR :normal gg :normal :%s/[ ]*$//gCR Then as Eric mentioned, you would need to get familiar with all the modes of Vim to really make it fly. For this, read this and commit to memory if possible: :help mode-switching Commiting it to memory is as easy as trying it out to switch between modes. Don't bother memorizing, just try to use it daily. One thing to remember when scripting in Vim is that you can always ___manually___ go through every script line. In the case of your 4 lines, you would find that :normal gg does its job. That is, start Vim, type :normal gg and hit Enter. But when you try all of these :normal %s/^[ ]*//g :normal %s/^[ ]*//gCR :normal :%s/^[ ]*//gCR and press Enter, it just won't work. You'll know that the second line has problems. What would you do if you wanted to do a :substitute command while you were in Vim? I think you would do :%s/^[ ]*//g and press Enter, just as you illustrated in your script (with the unnecessary CR). See how the :s command above matches the :normal gg command that worked? Place the :s command into your script then: :normal gg :%s/^[ ]*//g and now you have 2 working lines of script code. (Intention is to strip off all leading and trailing white space from a file. It is an experiment, so I choose this basic task. May be there is one command to achieve this, but as said...I used this as an exercise. [snip] To be really productive in Vim, you could learn more about Vim's regular expressions. Regexes allow you to do the one command to achieve this deal. So, in your case of removing leading and trailing white space, this would do it: :%s/^\s\+\|\s\+$//g Info on the regex elements I used can be found at :help /\s :help /\+ :help /\| Now I noticed that you did a couple of :normal gg It's good that you're thinking in terms of the cursor position. It'll become useful later (in search ranges, see :help :range), but in your case, you are applying the :substitute command to all lines by specifying % in :%s. Hopefully, that's enough to get you started :) HTH. -- Gerald
RE: Commenting out a block of text
On Fri, 5 May 2006, Max Dyckhoff wrote:
-Original Message-
From: Yakov Lerner [mailto:[EMAIL PROTECTED]
Sent: Friday, May 05, 2006 11:45 AM
To: Max Dyckhoff
Cc: vim@vim.org
Subject: Re: Commenting out a block of text
On 5/5/06, Max Dyckhoff [EMAIL PROTECTED] wrote:
F4 I want to do a block comment, namely put /* at the beginning of the
selection and */ at the end. Currently I am using a massive hack for
this (xiHOME/*CRHOME*/CRupupescp) but was wondering if
there was anyway of doing a search and replace for an entire block,
something like
:s/start_of_visual_selection(.*)end_of_visual_selection/\/*\1\/*/
Try along the lines of
:map f4 esc`ia*/esc`i/*esc
OR
:map f4 esc`iAcr*/esc`O/*esc
depending on your needs. (all untested). This
came up recently in the list.
Yakov
Fabulous, thank you. There seems to be extraneous 'i's in the two
examples you provided; ia*/ puts 'a*/' at the end of the comment.
Never knew that ` and ` jumped around in the visual block, thank you!
Max
[modified for bottom post]
As Yakov mentioned, your question recently came up in this list. It
started with
http://www.vim.org/tips/tip.php?tip_id=346
I was inspired and wrote a more advanced version that handled markup
tags, comments, brackets and quotes depending on which mode you were in,
and if you were in visual block mode, wrap line-wise (following indent)
instead of character-wise.
This is what I have so far. It is pretty easy to modify it to add more
types of end tag matches. Whitespace that appear after the opening tag
is mirrored on the closing tag.
===
nnoremap silentLeadert mzviwEsc:cal TagWrap(nt)CR
vnoremap silentLeadert Esc:cal TagWrap(vt)CR
nnoremap silentLeaderT mzviwEsc:cal TagWrap(nT)CR
vnoremap silentLeaderT Esc:cal TagWrap(vT)CR
function! TagWrap(mode)
let opentag = input(Opening .a:mode[1].ag? )
if opentag ==
if a:mode[0] == n
normal! g`z
elseif a:mode[0] == v
normal! gv
endif
return
endif
if a:mode[1] == T
let closetag = /.substitute(opentag, ^\\(\\s*\\S\\+\\).*, \\1,
).
let opentag = .opentag.
elseif a:mode[1] == t
if opentag =~ ^/\\*
let match = substitute(strpart(opentag, 2), ^\\(\\s\\+\\)\\(.*\\), \\2\\1,
).*/
elseif opentag =~ ^!--
let match = substitute(strpart(opentag, 4), ^\\(\\s\\+\\)\\(.*\\), \\2\\1,
).--
elseif opentag =~ ^[{[]
let match = substitute(strpart(opentag, 1), ^\\(\\s\\+\\)\\(.*\\), \\2\\1,
).nr2char(char2nr(opentag[0]) + 2)
elseif opentag =~ ^(
let match = substitute(strpart(opentag, 1), ^\\(\\s\\+\\)\\(.*\\), \\2\\1,
).)
elseif opentag =~ ^[\'`]
let match = substitute(strpart(opentag, 1), ^\\(\\s\\+\\)\\(.*\\), \\2\\1,
).opentag[0]
else
let match = opentag
endif
let closetag = input(Closing .a:mode[1].ag? , match)
endif
if visualmode() == \C-v
let indent = indent(')
let pad =
while strlen(pad) indent
let pad = pad.
endwhile
if closetag !=
'put = ''
call setline(line(') + 1, pad.closetag)
endif
'put! = ''
call setline(line(') - 1, pad.opentag)
normal! ^
else
execute normal! g`a.closetag
execute normal! g`mzi.opentag
normal! g`z
endif
endfunction
===
Use \t for a normal tag wrap. Use \T for a markup tag wrap of the
form a../a.
HTH.
--
Gerald
Re: hiding lines
On Thu, 4 May 2006, Jack Donohue wrote: :v (and :g) made my day..! Yes, I use this a lot if I just want to filter out a set of lines, or see only lines containing some text (like the old XEDIT command). But what I'd really like to to is continue editing in this view and not lose all the hidden lines, more like folding. I expect folding can do this, but I've never gotten it to work and it seems pretty cumbersome. I'm looking for a simple solution involving maybe a couple of command I can make a map for. I guess I'm looking for a g or v command that folds the lines instead of actually deleting them. Perhaps this would do: :set foldenable foldexpr=getline(v:lnum)=~@/ To fold consecutive lines that start with the word fold, first search /^fold or :let @/ = ^fold Then do :set foldmethod=expr foldlevel=0 to fold every search match. HTH. -- Gerald
Re: deleting repeated blocks of text
On Thu, 4 May 2006, Tim Chase wrote: Which command should I add in the script to tell vi to embed it in the correct place? At the moment I do it by telling vi something like go to line XXX, delete everything, insert text: :386,$d o CTRL + v + ESC :r /tmp/arXiV_2.txt :w! ~pau/WWW/arXiV.html But the inconvinient is that I have to modify the vim script whenever I add something to the web page, the number line 386 is wrong... and it is very tedious Well, rather than a fixed line number, you can have some unique token in your file. E.g., you can have a unique comment to mark the start of the content...something like !-- CONTENT GOES HERE -- Then, instead of :386,$d, you can do :/CONTENT GOES HERE/+,$d That finds the line containing that text (/CONTENT GOES HERE/), and then deletes (d) from the following line (+) to the end of the file ($). [snip] Yes, Tim has explained everything. In the OP's case, CONTENT GOES HERE is !-- Fixter viu comenca --. The OP can also shorten :d and :r to :/!-- Fixter viu comenca --/+,$!cat /tmp/arXiV_2.txt or for a Windows system :/!-- Fixter viu comenca --/+,$!type /tmp/arXiV_2.txt -- Gerald
Re: scripted :isearch?
On Thu, 4 May 2006, Neil Bird wrote: Around about 04/05/06 10:07, Yakov Lerner typed ... Do you mean function a-la :ilist that returns list of matches instead of printing them on the screen ? Actually, I finally sussed how ballooneval works and I thought that it might be cool to show the '[i' output there. It would be cool to show the [I output in a balloon. A first attempt: fun! Test() redir = output silent! exe ilist! /.v:beval_text./ redir END return output endf :set ballooneval balloonexpr=Test() -- Gerald
Re: deleting repeated blocks of text
On Wed, 3 May 2006, Gerald Lai wrote:
On Wed, 3 May 2006, Vim Visual wrote:
Hi,
this is the continuation of a post... The point is that I have a file
where blocks of text appear sometimes once, sometimes twice or even
three times etc...
I would like to find out how to delete the blocks that are repeated,
so that in the end I am left with a text file in which the blocks
appear only ONCE
The text file looks like this, for instance:(please note that there
are NOT blank lines in my text file, it's just after pasting here)
What a call a block is a paragraph starting with a bra
href=http://xxx.lanl.gov/...; until the next bra
href=http://xxx.lanl.gov/...;
[snip]
One possibility of what you're asking for is a uniq of custom defined
blocks. Blocks that are repeated in a row will be reduced to a unique
one block.
The other possibility, where getting rid of duplicate blocks that are
sandwiched between one another, is extremely complicated, and would
require storage for every unique block in the text for comparison. Some
might argue that if you did manage to store every unique block, then you
would have done the work of uniq-ing already.
For blocks uniq, the following commands should perform what you want.
First, place block delimiters so the start of a block != end of another
block. I chose #end# on its own line as the end delimiter.
:g/xxx\.lanl\.gov\|!-- acaba --/put!='#end#'
Then the uniq command is a simple
:g/^\(.*www\.lanl\.gov\_.\{-}\_^#end#\)\n\1$/.,/^#end#$/d A
[snip]
Another way of doing this is:
:%s/^\(.*www\.lanl\.gov\_.\{-}\_^#end#\)\%(\n\1\)\+$/\1
After that, you just need to clean up the end delimiters:
:%s/^#end#$//
It would probably be better to do
:g/^#end#$/d
HTH :)
--
Gerald
Re: regex @vim, negating a group
On Tue, 2 May 2006, o1792 wrote: [snip] if you want to find anything that is not any word ending in ion, well the regex group you're looking at is \(\.\+ion\\), but how do you negate that? Put it all in square brackets and provide a caret ^ at the beginning? Nope. in fact group within square brackets doesn't work as might be expected. Th enegation pretty much seems to be built for single character negation only, not sequences. I'm only referrign to searching here, when it comes to substituting or deleting, :v/etc/d seems tailor nmade to help with negations of tricky regex. The regex format for a negative search is /\%(search\zs\)* where the $ anchor, if needed, is placed after \zs. For example, if your search is /^start.*foo.*bar.*end$ to negate that, do /\%(^start.*foo.*bar.*end\zs$\)* In your case of anything that is not a word ending with ion, you'd want /\%(\\w\+ion\\zs\)* Can't use .; use \w instead. See :help /\w and also :help /\zs. HTH :) -- Gerald
Re: mouse selected text on winxp
On Mon, 1 May 2006, oystercatcher wrote: Greetings, Sorry if this is an obvious one but I searched using a variety of arguments and nothing was too clear. I also looked at _gvimrc and changed the line highlight Normal guibg=white # from gray80 which made it much easier to see the selected text. Now I would like to test some other colors other than the gray look for the selected text, is it possible?. I am using mingw compiled version of vim-7.0223 on winxp I'm assuming you're on GVim. Go to the Syntax menu on top and select either Syntax Color test Syntax Highlight test Those tests will allow you to see a spectrum of colors on text. The manual way of doing the Color test is :sp $VIMRUNTIME/syntax/colortest.vim | so % The manual way of doing the Highlight test is :runtime syntax/hitest.vim HTH :) -- Gerald
Re: issues with taglist and minibuffer explorer
On Mon, 1 May 2006, James Vega wrote:
On Mon, May 01, 2006 at 06:45:24PM +0530, jagpreet wrote:
[snip]
Furthermore if I close(:q), either of the files and switch to another file
by selecting it from the buffer window it opens the files in black and
white(vi ) mode, like syntax off commend is given.
This is a documented problem with MiniBufExpl and there is a variable
you can let to attempt to fix this. If you read the notes at the top of
MiniBufExpl.vim, you should find the information you need. You may find
bufexplorer.vim to be less intrusive and easier to use. That's what I
switched to after getting frustrated with MiniBufExpl.vim.
I've made modifications to MiniBufExpl that dealt with this problem. I'm
not sure if it would work for you, but you can try this:
Find the lines
autocmd MiniBufExplorer BufDelete * call SIDDEBUG('-= BufDelete AutoCmd', 10) |call
SIDAutoUpdate(expand('abuf'))
autocmd MiniBufExplorer BufEnter* call SIDDEBUG('-= BufEnter AutoCmd', 10)
|call SIDAutoUpdate(-1)
and change them to
autocmd MiniBufExplorer BufDelete * call SIDDEBUG('-= BufDelete AutoCmd', 10) |call
SIDAutoUpdate(expand('abuf')) |filetype detect
autocmd MiniBufExplorer BufWinEnter * call SIDDEBUG('-= BufWinEnter AutoCmd',
10) |call SIDAutoUpdate(-1)
HTH :)
--
Gerald
Re: txt.vim - Universal syntax script for all txt docs, logs and other strange files
On Sat, 29 Apr 2006, Tomasz Kalkosi?ski wrote: Hello This is a good idea! I have a couple of suggestions: (1) HiLink txtString Normal The highlight for alphabetic text may be too strong if linked to Identifier. Yes, it is linked to Identifier. The point is that Normal text is usually 'the weakest' color in set. And as for me it looks like not-colored compared to others. So I linked it to Identifier and pair txtString-txtComment looks nice for many colorsets. Although this pair works well for Normal-Comment too. What colorscheme are you testing with? [snip] I use a modified Ron colorscheme. Well, the suggestion of linking to Normal is merely my opinion :) As you can see from http://www.haze.ehost.pl/pub/vim/txt-elflord.png http://www.haze.ehost.pl/pub/vim/txt-metacosm.png and even http://www.haze.ehost.pl/pub/vim/txt-dusk.png colorschemes with a dark background and a bright Identifier can get a little distracting for eyes in the long run. Yes, Normal may not be as striking, and is usually the weakest set color as you put it, but that's because it's meant to be the most common. Identifiers are meant to stand out sparsely, so they're good for quick glances, but burn retinas when read too much. -- Gerald
Re: History and set history=xx
On Sun, 30 Apr 2006, Yakov Lerner wrote: On 4/30/06, Gerald Lai [EMAIL PROTECTED] wrote: On Sun, 30 Apr 2006, Yakov Lerner wrote: On 4/30/06, Bram Moolenaar [EMAIL PROTECTED] wrote: :help 'compatible' where (among other things) you can find the warning This is a special kind of option, because when it's set or reset, other options are also changed as a side effect. CAREFUL: Setting or resetting this option can have a lot of unexpected effects: Mappings are interpreted in another way, undo behaves differently, etc. If you set this option in your vimrc file, you should probably put it at the very start. There is a remark about this right at :help 'history'. Maybe behaviour of 'set nocp' can be differentiated depending on whether cp was already off , or cp was on. It's one thing if you do 'set nocp' and cp was on, and another thing when you do 'set nocp' and cp was already off. Maybe 'set nocp' doesn't need to reset options to default values when it was already 'nocp'. But in Meino's case, it may have been that he was still in Vi compatible mode when he set history. Meino's commands were in .vimrc which means nocp was already nocp. True. The 'compatible' option is one that clobbers settings, but for a good reason. It determines whether Vim should work like Vi, or take on the modern Vim capabilities. It's a big switch. It's only a switch if 'nocp' was off and becomes on. If option X has value Y and I do 'set X=Y' I expect it to be noop, except maybe screen refresh. When option had different value, and I change it's value, then I agree it's a switch. That would be nice, but how about options like 'filetype', 'fileformat' or 'background' that need to be refreshed? Or options like 'indentkeys' or 'listchars' that could be an out-of-order comma-separated list composed of anything? There's too much overhead of checking whether X=Y just to do a noop. -- Gerald
Re: How to auto-escape space in filename when write
On Sun, 30 Apr 2006, Yakov Lerner wrote: On 4/30/06, Eddy Zhao [EMAIL PROTECTED] wrote: Very often, when I - snip some notes from web - paste them into an empty buffer - yank the key sentence as filename - then try to :write Vim report E77: Too many file names. How can the spaces in filename be automatically escaped when I save the file? Use the :W instead of :w, and :W! instead of :w!. See below. It automatically escapes spaces for you. command! -bang -nargs=* W :call W(q-bang, q-args) function! W(bang, filename) :exe w.a:bang. . substitute(a:filename, ' ', '\\ ', 'g') endfu In addition to Yakov's suggestion, you can perform :let @@=escape(@@,' ') after you yank the key sentence as the filename. It should escape spaces once you paste for :write. HTH. -- Gerald
Re: txt.vim - Universal syntax script for all txt docs, logs and other strange files
On Sun, 30 Apr 2006, Russell Bateman wrote: Gerald Lai wrote: On Sat, 29 Apr 2006, Tomasz Kalkosi???ski wrote: Hello This is a good idea! I have a couple of suggestions: (1) HiLink txtString Normal The highlight for alphabetic text may be too strong if linked to Identifier. Yes, it is linked to Identifier. The point is that Normal text is usually 'the weakest' color in set. And as for me it looks like not-colored compared to others. So I linked it to Identifier and pair txtString-txtComment looks nice for many colorsets. Although this pair works well for Normal-Comment too. What colorscheme are you testing with? [snip] I use a modified Ron colorscheme. Well, the suggestion of linking to Normal is merely my opinion :) As you can see from http://www.haze.ehost.pl/pub/vim/txt-elflord.png http://www.haze.ehost.pl/pub/vim/txt-metacosm.png and even http://www.haze.ehost.pl/pub/vim/txt-dusk.png colorschemes with a dark background and a bright Identifier can get a little distracting for eyes in the long run. Yes, Normal may not be as striking, and is usually the weakest set color as you put it, but that's because it's meant to be the most common. Identifiers are meant to stand out sparsely, so they're good for quick glances, but burn retinas when read too much. -- Gerald Really, Gerald, I think you put these screens shots up here just to draw attention to your interesting backgrounds! ;-) I've got news for you, Russell ;) It's Tomasz's background. -- Gerald
Re: History and set history=xx
On Sun, 30 Apr 2006, Yakov Lerner wrote: On 4/30/06, Gerald Lai [EMAIL PROTECTED] wrote: On Sun, 30 Apr 2006, Yakov Lerner wrote: On 4/30/06, Gerald Lai [EMAIL PROTECTED] wrote: On Sun, 30 Apr 2006, Yakov Lerner wrote: On 4/30/06, Bram Moolenaar [EMAIL PROTECTED] wrote: :help 'compatible' [snip] The 'compatible' option is one that clobbers settings, but for a good reason. It determines whether Vim should work like Vi, or take on the modern Vim capabilities. It's a big switch. It's only a switch if 'nocp' was off and becomes on. If option X has value Y and I do 'set X=Y' I expect it to be noop, except maybe screen refresh. When option had different value, and I change it's value, then I agree it's a switch. That would be nice, but how about options like 'filetype', 'fileformat' or 'background' that need to be refreshed? Or options like 'indentkeys' or 'listchars' that could be an out-of-order comma-separated list composed of anything? There's too much overhead of checking whether X=Y just to do a noop. Since when it's too much overhead to check the value of binary option for equaliy or not equality ? Sorry, I meant to say that there's overhead for checking if option X == Y for options that are non-binary, like 'indentkeys' or 'listchars'. For binary options, your suggestion is plausible, though I do agree with Gary said. Some options have to be refreshed, and it will be inconsistent to have setting binary options do a noop if the option is set to what it already is, while other options maintain the same :set behavior. An exception could be made for 'compatible', but that is an exception Bram would have to make. -- Gerald
Re: highlighting tabbed text
On Mon, 1 May 2006, Michael Naumann wrote: Is there a way to highlight a sequence of non-tabs followed by a sequence of tabs (/^[^\t]\+\t\+/) differently from the next such sequence? For example in the line a\tb\t\tc\td I want a\t to be color1, b\t\t to be color2 and c\t to be color3 (or probably color1 again) Is this even possible? You could check out Mark.vim http://www.vim.org/scripts/script.php?script_id=1238 HTH. -- Gerald
Re: modify a text file
On Sat, 29 Apr 2006, Vim Visual wrote:
[snip]
I solved it like this:
:1,/received/d
:$?^\s*For subscribe options?,$d
:let @a=''
:g/hole\|relativistic\|LISA\|black\|supermassive\|intermediate/?^\s*astro-ph?,/^\s*astro-ph/-y
A
:%d
:put a
:1d
:%s!^\s*astro-ph/\(\d\+\)!a href=http://xxx.lanl.gov/pdf/astro-ph/\1;/a
:w! /tmp/2.html
:q
and using the
cat /tmp/1.html | vim -s foo_arXiv.vim -
[snip]
For what it's worth, here's a search regex that will search for words in
blocks delimited by #begin# and #end# on its own line:
(all on one line)
/^#begin#\%(
\%(\n\(#end#\_$\)[EMAIL PROTECTED])*word0
\\%([EMAIL PROTECTED])*word1
\\%([EMAIL PROTECTED])*word2
\)\_.\{-}\_^\1$
For example, if
word0 = foo
word1 = bar
word2 = xxx
then the regex will match
==
#begin#
On one foofine day, a regex
found itself in the local
bar... There were many
regexxxes there to
begin
and
end
with.
#end#
==
You can add on as many words as you need according to the \ format
above. After you are satisfied with the search, you can do something
like
:let @a = ''
:g//.,/#end#/y A
to yank all the blocks.
There was also discussion on this mailing list earlier (between Yakov
and I) on how to search for words in a paragraph. Assuming a paragraph
is delimited by blank lines ^\s*$, we have this search regex instead:
(all on one line)
/^\s*\%(
\%(\n\%(\s*\_$\)[EMAIL PROTECTED])*word0
\\%(\n\%(\s*\_$\)[EMAIL PROTECTED])*word1
\\%(\n\%(\s*\_$\)[EMAIL PROTECTED])*word2
\)\_.\{-}\ze\_^\s*$
HTH :)
--
Gerald
Re: brackets placement in vim
On Fri, 28 Apr 2006, Justin Randall wrote:
Hi,
I would like to know if there is an easy way to fix the placement of { }
brackets in vim
so that they fall two or three spaces intented. For example in a C++ file I'm
currently
working on, I have:
if (pExample != NULL)
{
// code here
}
What I would like is to have the brackets indented from the edge of the page 2
or 3
spaces. Such as:
if (pExample != NULL)
{
// code here
}
Any ideas as to how I can achieve this?
Assuming your code curly brackets are correctly aligned, and there's
only whitespace before them, you can do
:%s/^\s*[{}]/
to add 2 extra spaces in front of every curly bracket on its own line.
HTH :)
--
Gerald
Re: ` visual selection -- inconsistent?
On Fri, 28 Apr 2006, Eric Arnold wrote: On 4/28/06, Eric Arnold [EMAIL PROTECTED] wrote: The end of the visual selection as gotten by` seems to depend on whether the cursor was between the end_col - 1, and end_col, or between end_col, and end_col + 1. The GUI gvim seems to have the notion of the the cursor being between characters in visual mode. ` sometimes lands you on the character *after* the last col of the visual selection. So, the question is, how do I get the real last column of the Visual selection? Actually, this seems be inconsistent mostly when you start a visual-block selections from different corners. It works as expected for me. For example, 1. Start :new buffer. 2. From Normal mode, type iab. 3. Hit Enter. 4. Type cd, and hit Esc. Then do gg0. You should have: ab cd with the Normal cursor on a. 5. Start visual block with C-v, and hit jl. Press Esc. Now, from Insert mode, if you did 6. C-o followed by ` the Insert cursor will be between c and d. If, instead, you hit j2l in step 5, then (after step 6) the Insert cursor will appear after d. Remember, visual modes are able to highlight _past_ the end-of-line, unlike the Normal mode cursor. Please provide an example if you still see a problem. HTH. -- Gerald
Re: autochdir doesnt work right
On Thu, 27 Apr 2006, Eric Crahen wrote:
I've tried all variation of BufEnter and autchdir commands to get the
cwd switched to that of the file that is open. None of them ever work
when I specify a file on the command line. The buffer for the file I
specify is open, but the cwd is right where I started vim. I have to
:bn|:bp to get the buffer switched.
Its only this first file. Anyone know why?
Change directory
if exists('+autochdir')
set autochdir
else
autocmd BufEnter * silent! lcd %:p:h:gs/ /\\ /
endif
Hi Eric,
I don't use 'autochdir', but here's what I have that works for me:
set local directory
autocmd BufWinEnter,BufWritePost *
\ if expand(%) !~ ^\\%(\\a\\+://\\|$\\) |
\ lcd %:p:h |
\ endif |
HTH :)
--
Gerald
Re: autochdir doesnt work right
On 4/27/06, Eric Crahen [EMAIL PROTECTED] wrote:
On 4/27/06, Gerald Lai [EMAIL PROTECTED] wrote:
On Thu, 27 Apr 2006, Eric Crahen wrote:
I've tried all variation of BufEnter and autchdir commands to get the
cwd switched to that of the file that is open. None of them ever work
when I specify a file on the command line. The buffer for the file I
specify is open, but the cwd is right where I started vim. I have to
:bn|:bp to get the buffer switched.
Its only this first file. Anyone know why?
Change directory
if exists('+autochdir')
set autochdir
else
autocmd BufEnter * silent! lcd %:p:h:gs/ /\\ /
endif
Hi Eric,
I don't use 'autochdir', but here's what I have that works for me:
set local directory
autocmd BufWinEnter,BufWritePost *
\ if expand(%) !~ ^\\%(\\a\\+://\\|$\\) |
\ lcd %:p:h |
\ endif |
HTH :)
I tried adding that and there was no effect
Try running from the prompt:
$ vim -u NONE
Then do:
:set nocp laststatus=2
:autocmd BufWinEnter * lcd %:p:h
Split open 2 files in different directories and switch between both the
windows. Do you see the paths change?
--
Gerald
Re: autochdir doesnt work right
On Thu, 27 Apr 2006, Eric Crahen wrote:
On 4/27/06, Gerald Lai [EMAIL PROTECTED] wrote:
On 4/27/06, Eric Crahen [EMAIL PROTECTED] wrote:
On 4/27/06, Gerald Lai [EMAIL PROTECTED] wrote:
On Thu, 27 Apr 2006, Eric Crahen wrote:
I've tried all variation of BufEnter and autchdir commands to get the
cwd switched to that of the file that is open. None of them ever work
when I specify a file on the command line. The buffer for the file I
specify is open, but the cwd is right where I started vim. I have to
:bn|:bp to get the buffer switched.
Its only this first file. Anyone know why?
Change directory
if exists('+autochdir')
set autochdir
else
autocmd BufEnter * silent! lcd %:p:h:gs/ /\\ /
endif
Hi Eric,
I don't use 'autochdir', but here's what I have that works for me:
set local directory
autocmd BufWinEnter,BufWritePost *
\ if expand(%) !~ ^\\%(\\a\\+://\\|$\\) |
\ lcd %:p:h |
\ endif |
HTH :)
I tried adding that and there was no effect
Try running from the prompt:
$ vim -u NONE
Then do:
:set nocp laststatus=2
:autocmd BufWinEnter * lcd %:p:h
Split open 2 files in different directories and switch between both the
windows. Do you see the paths change?
[modified for bottom posting]
When I open files from within vim its not a problem. Its the files
that are opened from the command line, a method I use every day.
The autocmds VimEnter, BufEnter, WinEnter, and BufWinEnter all activate
when a file is opened from the command line. You can use any of these.
The example set local directory I gave you will only set the directory
for windows in Vim. When you quit Vim, you will still be where you
executed Vim.
Consider using
:cd
instead of
:lcd
See :help :cd :help :lcd.
I'm sorry I misunderstood what you wanted in the first place.
HTH :)
--
Gerald
Re: File - register
On Thu, 27 Apr 2006, Suresh Govindachar wrote: Hello, What's the best way to get the contents of a file into a register? I tried the following (file is foo.bat), but it doesn't get rid of the new buffer: :new|r foo.bat|1d|normal ayG|q! So why does the q! get lost, and is there a better way? Do :new | r foo.bat | 1d_ | set nonu | redir @a | sil! %p | redir END q! gets lost because :normal reads its argument till the end of the cmdline. HTH :) -- Gerald
Re: Backslash in maps
On Thu, 27 Apr 2006, Suresh Govindachar wrote:
Hello,
Why does the following _single_ line map
generate the E10 error?:
nmap space :let @a=substitute(getline('.'),'\(^.*|\s*\)\|\(\s\s*$\)','','g')
How would it be fixed?
What do you intend to do with the mapping?
First, replace all | with Bar:
nmap space :let
@a=substitute(getline('.'),'\(^.*Bar\s*\)\Bar\(\s\s*$\)','','g')
|s are used as the command separator in the :cmdline.
I think you'd want the first Bar to be escaped with a backslash \ .
Also, put CR at the end:
nmap space :let
@a=substitute(getline('.'),'\(^.*\Bar\s*\)\Bar\(\s\s*$\)','','g')CR
Simplifying the regex yields:
nmap space :let
@a=substitute(getline('.'),'^.*\Bar\s*\Bar\s\s*$','','g')CR
HTH.
--
Gerald
Re: Bug in i_^X
On Wed, 26 Apr 2006, Hari Krishna Dara wrote: In Vim 6.3, hitting ^X in insert mode when the cursor is on the number: 08) produced: 03778) This is a bug which seems to be fixed in Vim 7.0f, but it doesn't work right, as it now produces: 7) instead of: 07) If the string is say, 07) both versions correctly produce, 06) Confirmed for Vim 6.3. Seems like some kind of octal increment/decrement confusion. However, I think Hari meant to say Normal mode instead of Insert mode. Vim thinks that it's an octal number because of 0 followed by [0-9]\+ (yes, it should be [0-7]\+). But when it encounters [8-9]\+\d*$, it takes 0 as the octal number itself, and not as the octal indicator (as 0x is the hex indicator). This is evident with: 08123 Placing the cursor on any of the 5 digits and hitting Ctrl-x produces: 03778123 Some may say it is correct operation ;) except for the fact that Vim confuses the indicator for the number itself. Hence, performing the same on: 008123 also produces: 03778123 In this case, the good 0 is decremented to -1 in octal. Of course, the fix for this behavior on any Vim is :set nrformats-=octal See :help 'nrformats'. HTH :) -- Gerald
Re: Insert Visual mode
On Wed, 26 Apr 2006, Benji Fisher wrote: On Wed, Apr 26, 2006 at 05:17:01PM +0200, Bram Moolenaar wrote: Benji Fisher wrote: This mode seems to be similar to Insert mode, but Esc takes me to Visual mode instead of Normal mode. AFAICT this is undocumented. This is a really weird mode, being both in Insert mode and having a Visual selection. I agree. I think I better prevent this from happening. No complaints here. Gerald, I hope you will not miss it! ;) Nah. Good riddance :) It will actually fix a bug in one of my scripts. Bram, could you make Vim do -- (insert) VISUAL -- instead when it now does -- INSERT VISUAL -- ? -- Gerald
RE: Making * search for strings
On Wed, 26 Apr 2006, Halim, Salman wrote:
I use the extreme version:
vnoremap silent * yy:let @/='\(' . substitute( escape( @y,
'$*^[]~\/.' ), '\_s\+', '\\_s\\+', 'g' ) . '\)'cr:set hlscr
This escapes a lot of stuff, including replacing any whitespace with a
generic expression that includes newlines. I like it because if you
highlight 'a b' (without the quotes) and hit *, it will subsequently
also match 'a b', 'a\nb' (where the \n indicates that the a
and b are on different lines). I got the idea from a previous
discussion on this list (might well have been Gerald posting his
mappings earlier).
Good idea :) I'll adopt it for my kMultiply. Question, do
you think it would be useful to extend this to numbers too?
For example, visual matching 123 results in \d\+?
I thought about doing substitutions to non-whitespace characters
(numbers with \d\+ and letters/underscores with \w\+) but it seemed to
match too many things. Admittedly, I will occasionally have something
like this:
[snip]
How about another mapping that does something like:
:let @/=substitute(@/, '\d\+', '\\d\\+', 'g')
[snip]
Thanks. I think I'll include number generalization in my extreme
version of kMultiply ;) Seems useful enough. It now looks like:
(one line)
vnoremap silentkMultiply
y/\VC-r=substitute(substitute(escape(@@,'/\'),'\_s\+','\\_s\\+','ge'),'\d\+','\\d\\+','ge')CRCRC-o
--
Gerald
Re: Making * search for strings
On Tue, 25 Apr 2006, Suresh Govindachar wrote: Hello, By default, * searches for words: /\stuff_below_cursor\ but I would like it to search for strings: /stuff_below_cursor One way is to use the following map * yiw:let @/[EMAIL PROTECTED]cr Is there a better way? (/yiw didn't work.) I found this somewhere in Vim tips: visual search vnoremap * y/\VC-r=substitute(escape(@@,/\\),\n,n,ge)CRCR vnoremap kMultiply y/\VC-r=substitute(escape(@@,/\\),\n,n,ge)CRCR vnoremap # y?\VC-r=substitute(escape(@@,?\\),\n,n,ge)CRCR HTH :) -- Gerald
