cut/paste character conversion issues from Word or Notepad to vim
Alas, most of my clients give me text in Word Format. However even when I cut-paste from Notepad into gvim certain characters don't convert over, namely quotes (single, double) and diacritics (áé...). Instead ' for example turns into ¿. When I pasted in a lot of text, it can be very hard to convert all the characters back. What can I do to avoid this in the first place (besides dropping Winbloze, since that's not an option)? converted in Carolina, Ben
Re: Structure of runtime directory on ftp.vim.org
On Sun 28-Jan-07 9:36pm -0600, you wrote: > I noticed that for getting the runtime files, Bill McCarthy uses > ftp.vim.org/pub/vim/runtime/dos/ whereas Tony uses everything > inside ftp.vim.org/pub/vim/runtime/ except the dos subdirectory. > > So I surmise that the stuff under runtime/dos/ is essentially the > same as everything in runtime/ excluding dos/ -- with the > difference having to do with the use of CRLF and CR. Am I > correct? Yes, the dos/ directory has line endings of CR/LF, the other has LF. Also, the dos/ directory as only 14 subdirectories, but the one above has 16. The difference is the dos/ directory and the spell/ directory - I don't know why, but the spell directory is missing for dos/. -- Best regards, Bill
Writeup on mkdownload, getunix.aap and getdos.aap
Hello, Is there a write-up describing what :mkdownload does and describing the sturcture of the following files? ftp.nluug.nl/vol/1/vim/runtime/getunix.aap ftp.nluug.nl/vol/1/vim/runtime/getdos.aap I suspect that knowing the answer will enable me to write a perl script to update $VIMRUNTIME. Thanks, --Suresh
Structure of runtime directory on ftp.vim.org
Hello, I noticed that for getting the runtime files, Bill McCarthy uses ftp.vim.org/pub/vim/runtime/dos/ whereas Tony uses everything inside ftp.vim.org/pub/vim/runtime/ except the dos subdirectory. So I surmise that the stuff under runtime/dos/ is essentially the same as everything in runtime/ excluding dos/ -- with the difference having to do with the use of CRLF and CR. Am I correct? --Suresh
Re: Avoiding a temporary global variable
Suresh Govindachar wrote:
Recently, Tim Chase wrote in the thread "replace
with a number sequence":
...8<---
> Things get a little trickier if one wants to do the replacement
> in a single line of multiple instances...
>
> opInstance(1), opInstance(2), opInstance(3)
>
> One has to write a function that effects a global variable:
>
> let g:start=0
> function! Incrementer()
> let l:result = g:start
> let g:start = g:start + 1
> return l:result
> endfunction
>
> and then do something like
>
> :%s/regexp/\=Incrementer()/g
>
> It would be nice not to have to use global variables for
> something like that.
Can't one initialize the unnamed register, @" and use a :g with
a command along the lines of 'replace with @" and increment @"'
(I tried some experiments to implement the above idea but could
not do so. But my inability to implement it does not meant that
it can't be done.)
--Suresh
I don't see any advantage (and I see some inconvenients) in using a register
rather than a variable; but you could do with a script variable (which could
be used globally but only via the functions defined in the script):
function SetStep(value)
let s:stepvar = a:value
endfunction
function GetStep(increment)
let s:stepvar += a:increment
return s:stepvar
endfunction
call SetStep(-1)
1,$s/OpInstance(\zs\n\+\ze)/\=GetStep(1)/g
...or a local variable to the buffer where you do the substitute (untested):
function GetStep(varname, increment)
exe "let" a:varname "+=" a:increment
exe "return" a:varname
endfunction
let b:counter = -1
1,$s/OpInstance(\zs\n\+\ze)/\=GetStep("b:counter", 1)/g
Best regards,
Tony.
additional spaces with C_V
Hi,
Suppose I have this text loaded into vim (":set list")
09wqeuwueo$
aaai$
kjdhfks$
jhd$
kdj$
asldo0$
skaj$
Now I put my cursor in the first line onto the last charcter, press
"a " to insert some space and then start visual mode
with C-V and move the cursor directly down to the last line, press "I
" and got a space inserted into the first line. Nothing
else is changed
Since the marked bar in visual mode has had no problems to reach the
last line without stumbling accross the missing spaces, I would
exspect to get something like this
09wqeuwueo $
aaai $
kjdhfks$
jhd$
kdj$
asldo0 $
skaj $
. On the other hand, vim would exspect, that her/his user would
understand, what s/he is doing ;)
Is there a way to accomplish this? May be be tweaking some options?
I did a "set virualedit=block" in my .vimrc, but this doesn't help.
Thank you very much for any "i help " in advance ! :
Keep editing!
mcc
Avoiding a temporary global variable
Recently, Tim Chase wrote in the thread "replace with a number sequence": ...8<--- > Things get a little trickier if one wants to do the replacement > in a single line of multiple instances... > > opInstance(1), opInstance(2), opInstance(3) > > One has to write a function that effects a global variable: > > let g:start=0 > function! Incrementer() > let l:result = g:start > let g:start = g:start + 1 > return l:result > endfunction > > and then do something like > > :%s/regexp/\=Incrementer()/g > > It would be nice not to have to use global variables for > something like that. Can't one initialize the unnamed register, @" and use a :g with a command along the lines of 'replace with @" and increment @"' (I tried some experiments to implement the above idea but could not do so. But my inability to implement it does not meant that it can't be done.) --Suresh
Re: replace with a number sequence
>>> I have these lines,
>>> UniqueID2 = lview.focusedItem.subItems.opIndex(0).text;
>>> Parent = lview.focusedItem.subItems.opIndex(0).text;
>>> Children= lview.focusedItem.subItems.opIndex(0).text;
>>>
>>> and I would like to replace the number between the parens () to a
>>> sequential
>>> number starting from 0. ie,
>>
>> If you highlight the lines in question and issue the following:
>>
>> :'<,'>s/opIndex(\zs\d\+\ze)/\=line('.')-line("'<")
>>
>> It should renumber them starting at zero for you.
>>
>> I'd be glad to explain what that's doing if you have trouble
>> un-opaquifying it :)
>
> I've used the line function in the past. And it's something seems to
> recur frequently.
It, and its mate "getline()" are commonly used in scripts,
usually taking a line reference (such as "." for the current line
or "'x" for a mark or "$" for the last line of the file)
:help line(
:help getline(
> Since I'm always learning new things in vim, I'd appreciate any
> instructive comment on your solution.
> The use of zs and ze is also interesting (-:
I'll try to address them both in the same pass. The \zs and \ze
mark the beginning and end of the pattern in which I'm
interested. This allows me to add context (the "opIndex(" and
the closing paren) without worrying about extracting those pieces
and putting them back in in the final expression. Thus, I'm only
dealing with the numbers, but I know that those numbers are the
ones in the opIndex() that I'm interested in.
:help /\zs
:help /\ze
I now have as my "entire" pattern, the digits that I want to
replace. I replace them with the results of evaluating an
expression: \=
:help sub-replace-special
The math in question replaces the contents that were found (the
digits) with the following result:
line('.')-line("'<")
The line('.') is the line number of the current match (or the
beginning of the current match, if it had been multi-line). The
second line("'<") is the line number of a mark. In this case,
the "<" mark, which is the beginning of the range (as in, your
"'<,'>" that shows up at the beginning of the line when you try
to execute an Ex command within visual mode).
Thus, the result of this on the first line (N) of the replacement
will be N-N=0. The second line on which we replace this, it will
have be (N+1)-N = 1 and so on until you get to the end of the
range. If one wanted to count from 1, you could just use
1+line(".")-line("'<")
Or you could count by multiples of 2 (0,2,4,6,8...):
2*(line(".")-line("'<"))
or odd multiples of two (1,3,5,7,9...)
1+2*(line(".")-line("'<"))
and so on.
Things get a little trickier if one wants to do the replacement
in a single line of multiple instances...
opInstance(1), opInstance(2), opInstance(3)
One has to write a function that effects a global variable:
let g:start=0
function! Incrementer()
let l:result = g:start
let g:start = g:start + 1
return l:result
endfunction
and then do something like
:%s/regexp/\=Incrementer()/g
It would be nice not to have to use global variables for
something like that.
Just a few further riffs on the original idea...Hope this helps
understand and dissect the original so you can use/abuse it in
the future. :)
-tim
Re: replace with a number sequence
Hi.
Tim Chase wrote:
I have these lines,
UniqueID2 = lview.focusedItem.subItems.opIndex(0).text;
Parent = lview.focusedItem.subItems.opIndex(0).text;
Children= lview.focusedItem.subItems.opIndex(0).text;
login = lview.focusedItem.subItems.opIndex(1).text;
txtCust.text= lview.focusedItem.subItems.opIndex(2).text;
txtProj.text= lview.focusedItem.subItems.opIndex(3).text;
txtbDate.text = lview.focusedItem.subItems.opIndex(4).text;
txtdDate.text = lview.focusedItem.subItems.opIndex(5).text;
txteDate.text = lview.focusedItem.subItems.opIndex(6).text;
txtPM.text = lview.focusedItem.subItems.opIndex(7).text;
txtLang.text= lview.focusedItem.subItems.opIndex(8).text;
txtVendor.text = lview.focusedItem.subItems.opIndex(9).text;
txtInvoice.text = lview.focusedItem.subItems.opIndex(10).text;
txtPMFund.text = lview.focusedItem.subItems.opIndex(11).text;
txtProjFund.text= lview.focusedItem.subItems.opIndex(12).text;
txtA_No.text= lview.focusedItem.subItems.opIndex(13).text;
txtNotes.text = lview.focusedItem.subItems.opIndex(14).text;
txtStatus.text = lview.focusedItem.subItems.opIndex(15).text;
and I would like to replace the number between the parens () to a sequential
number starting from 0. ie,
If you highlight the lines in question and issue the following:
:'<,'>s/opIndex(\zs\d\+\ze)/\=line('.')-line("'<")
It should renumber them starting at zero for you.
I'd be glad to explain what that's doing if you have trouble
un-opaquifying it :)
I've used the line function in the past. And it's something seems to
recur frequently.
Since I'm always learning new things in vim, I'd appreciate any
instructive comment on your solution. The use of zs and ze is also
interesting (-:
Kind regards.
Luke.
-tim
--
Luke Vanderfluit
Analyst / Web Programmer
e3Learning.com.au
08 8221 6422
Re: Weird problem with helpgrep
On Sun 28-Jan-07 4:33pm -0600, DervishD wrote: > Finally, examining the source code, I found the problem. I > have my vim documentation installed in /usr/doc, which is > where all documentation is installed on my system. I've > set "helpfile" so ":help" finds the docs. BUT ":helpgrep" > doesn't use "helpfile", but only "runtimepath/doc". This > is a problem for me, because no matter which value I > assign to "runtimepath", the documentation is not going to > be found in any "/doc" subdir! If that's the case, you could add the path to vimruntime. For example, if your vim70 docs are in /usr/doc/vim70/doc: set rtp+=/usr/doc/vim70 An alternate idea, which will only search the distributed help files, is to add a command: command! -nargs=1 HG let g:myrtp = &rtp \ | let &rtp = '/usr/doc/vim70' \ | exe 'helpg ' \ | let &rtp = g:myrtp \ | unlet g:myrtp Of course, to search all docs, including add-on help files, replace: \ | let &rtp = '/usr/doc/vim70' with \ | set rtp+=/usr/doc/vim70 in another command, perhaps called HGA. -- Best regards, Bill
Re: Weird problem with helpgrep
DervishD wrote: Hi all :) I've discovered that ":helpgrep pattern" doesn't work for me, always returning "E480" (BTW, ":help E480" shows help about "argdelete", as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say "most", for example), "helpgrep" returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set "helpfile" so ":help" finds the docs. BUT ":helpgrep" doesn't use "helpfile", but only "runtimepath/doc". This is a problem for me, because no matter which value I assign to "runtimepath", the documentation is not going to be found in any "/doc" subdir! Given that "/usr/doc" or "/usr/share/doc" are pretty standard when it comes to install documentation, shouldn't "ex_helpgrep" use the directory from "helpfile" too, just like ":help" does? I'm not familiar enough with the source to be able to add support for "helpfile" path to "ex_helpgrep" without resorting to a dirty hack, but I can try... "ex_helpgrep" looks like it is tailored to only process "runtimepath/doc" in the main loop, so any nonintrusive modification is almost impossible. Any suggestion instead of modifying the sources *and* moving the documentation? I would like to use ":helpgrep" O:) Thanks a lot in advance :) Raúl Núñez de Arenas Coronado Here, ":help E480" shows help about ":argdelete", and the help tags ":argd" ":argdelete" and "E480" are on a single line. Maybe you are using wrong syntax? To use your own example, the syntax to search for "most" as a separate word is :helpgrep \ Notice that there are no / or " around the pattern, and that "where to search" is implicit. On my system, the above command finds 255 hits, the first of which is in matchit.txt (not in $VIMRUNTIME/doc but, IIRC, as $VIM/vimfiles/doc/matchit.txt which is a softlink to ../../vim70/macros/matchit.txt ). Or if you are using correct syntax, maybe you have a mapping or abbreviation tripping you? (Try it with "vim -N -u NONE" after setting 'helpfile' and whatever other options you really can't do without.) Here are a few ways to access the documentation if it is in a nonstandard location: 1) Use ":vimgrep" instead of ":helpgrep". The syntax is different but you ought to get access to the same results, albeit not in a help window but in the current window (use ":new" before ":vimgrep" to do it in a new window). To use the same example again (and an imaginary directory location): :vimgrep /\/g ~/mydocs/vim/doc/*.txt As a variation of this, you could use the following: command -nargs=1 -bar HelpGrep vimgrep //g ~/mydocs/vim/docs/*.txt cabbrev HG HelpGrep You could then use :HelpGrep (or :HG) instead of :helpgrep. If you don't need the abbreviation, then of course you can skip the cabbrev definition. 2) Don't set 'helpfile' but create softlinks from the standard location to the actual location. (This requires the ability to create softlinks, which is easily available in Unix/Linux and Cygwin, but is absent, undocumented or esoteric on most native-Windows systems, unless "shortcuts" provide the same functionality.) 3) Bite the bullet and move the docs to their standard location. This ought not to require a recompilation. Best regards, Tony.
Weird problem with helpgrep
Hi all :) I've discovered that ":helpgrep pattern" doesn't work for me, always returning "E480" (BTW, ":help E480" shows help about "argdelete", as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say "most", for example), "helpgrep" returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set "helpfile" so ":help" finds the docs. BUT ":helpgrep" doesn't use "helpfile", but only "runtimepath/doc". This is a problem for me, because no matter which value I assign to "runtimepath", the documentation is not going to be found in any "/doc" subdir! Given that "/usr/doc" or "/usr/share/doc" are pretty standard when it comes to install documentation, shouldn't "ex_helpgrep" use the directory from "helpfile" too, just like ":help" does? I'm not familiar enough with the source to be able to add support for "helpfile" path to "ex_helpgrep" without resorting to a dirty hack, but I can try... "ex_helpgrep" looks like it is tailored to only process "runtimepath/doc" in the main loop, so any nonintrusive modification is almost impossible. Any suggestion instead of modifying the sources *and* moving the documentation? I would like to use ":helpgrep" O:) Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: replace with a number sequence
> I have these lines,
> UniqueID2 = lview.focusedItem.subItems.opIndex(0).text;
> Parent = lview.focusedItem.subItems.opIndex(0).text;
> Children= lview.focusedItem.subItems.opIndex(0).text;
> login = lview.focusedItem.subItems.opIndex(1).text;
> txtCust.text= lview.focusedItem.subItems.opIndex(2).text;
> txtProj.text= lview.focusedItem.subItems.opIndex(3).text;
> txtbDate.text = lview.focusedItem.subItems.opIndex(4).text;
> txtdDate.text = lview.focusedItem.subItems.opIndex(5).text;
> txteDate.text = lview.focusedItem.subItems.opIndex(6).text;
> txtPM.text = lview.focusedItem.subItems.opIndex(7).text;
> txtLang.text= lview.focusedItem.subItems.opIndex(8).text;
> txtVendor.text = lview.focusedItem.subItems.opIndex(9).text;
> txtInvoice.text = lview.focusedItem.subItems.opIndex(10).text;
> txtPMFund.text = lview.focusedItem.subItems.opIndex(11).text;
> txtProjFund.text= lview.focusedItem.subItems.opIndex(12).text;
> txtA_No.text= lview.focusedItem.subItems.opIndex(13).text;
> txtNotes.text = lview.focusedItem.subItems.opIndex(14).text;
> txtStatus.text = lview.focusedItem.subItems.opIndex(15).text;
>
> and I would like to replace the number between the parens () to a sequential
> number starting from 0. ie,
If you highlight the lines in question and issue the following:
:'<,'>s/opIndex(\zs\d\+\ze)/\=line('.')-line("'<")
It should renumber them starting at zero for you.
I'd be glad to explain what that's doing if you have trouble
un-opaquifying it :)
-tim
replace with a number sequence
Greetings! I have these lines, UniqueID2 = lview.focusedItem.subItems.opIndex(0).text; Parent = lview.focusedItem.subItems.opIndex(0).text; Children= lview.focusedItem.subItems.opIndex(0).text; login = lview.focusedItem.subItems.opIndex(1).text; txtCust.text= lview.focusedItem.subItems.opIndex(2).text; txtProj.text= lview.focusedItem.subItems.opIndex(3).text; txtbDate.text = lview.focusedItem.subItems.opIndex(4).text; txtdDate.text = lview.focusedItem.subItems.opIndex(5).text; txteDate.text = lview.focusedItem.subItems.opIndex(6).text; txtPM.text = lview.focusedItem.subItems.opIndex(7).text; txtLang.text= lview.focusedItem.subItems.opIndex(8).text; txtVendor.text = lview.focusedItem.subItems.opIndex(9).text; txtInvoice.text = lview.focusedItem.subItems.opIndex(10).text; txtPMFund.text = lview.focusedItem.subItems.opIndex(11).text; txtProjFund.text= lview.focusedItem.subItems.opIndex(12).text; txtA_No.text= lview.focusedItem.subItems.opIndex(13).text; txtNotes.text = lview.focusedItem.subItems.opIndex(14).text; txtStatus.text = lview.focusedItem.subItems.opIndex(15).text; and I would like to replace the number between the parens () to a sequential number starting from 0. ie, (0) (1) ... ... (19) etc. Any help would be greatly appreciated. josé
Re: replacing with a newline
jose isaias cabrera wrote: "A.J.Mechelynck" wrote, Bill McCarthy wrote: On Sat 27-Jan-07 11:15pm -0600, you wrote: Ok, here is a question: Why not keep it the same, \n? Any reasoning behind it? That could be a way to do it, but that choice wasn't made. Perhaps someone else could explain why \n means end-of-line in the pattern, but nul in the substitution, while \r means ^M in the pattern, but end-of-line in the substitution? And why not a \x representation for nul in the pattern - instead of needing to do a [EMAIL PROTECTED] [Note: ^M is created with ctrl-v following by and ^@ is created by ctrl-v followed by 000.] IIUC, NULs are replaced by LF everywhere in Vim memory, because a NUL terminates a C string while a LF is the only ASCII character guaranteed not to exist (in Unix 'fileformat') in the middle of a line (as opposed to at its end). So if lines are stored as C strings, substituting NUL for LF and vice-versa allows representing everything. (Mac 'fileformat' may required some fancy footwork; Dos 'fileformat' is handled by treating either CR+LF or LF as a linebreak on input, and writing all linebreaks as CR+LF on output.) Why not use the same character in "replace by" as in "search for" is harder to explain, though. Maybe part of it is for historical "compatibility" reasons, but it doesn't explain why that choice was made by whoever made it. It may have something to do with the fact that hitting at the keyboard generates a CR but is stored (in memory) as a line break then (on file, if in Unix 'fileformat') as a LF. One of the things I love about vim is that it makes sense. And I don't have to learn or memorize much when things make sense, I just follow the logic. But this question, "how do I replace with a newline", I have asked about 5 times now. Why? Because I remember most things with vim since working with vim makes sense. But this \n vs. \r makes no sense to me and I keep forgetting. Perhaps, on the next big release, this command would be possible, :%s/,/\n/g and have commas be replaced by newline. Just a thought... Thanks for all the replies. josé It won't, because adding a "\n" or a ^J in the middle of a line gets translated into a NUL -- always. It has for as long as Vim has existed and maybe longer, and you know Bram's standing on upward compatibility (IMHO, rightly so). It's just one of those "Vim quirks" -- one of the few exceptions to the systematic rules -- that to count linebreaks by replacing them with themselves you have to use :[range]s/\n/\r/ It is documented, BTW: under :help /\n :help s including the few lines below the latter ...and maybe also elsewhere. Best regards, Tony.
Re: Updating $VIMRUNTIME on Windows
On Sun 28-Jan-07 1:20pm -0600, you wrote: > Bill McCarthy recently wrote to vim-dev and others: >> Runtime files are kept fairly well updated at the Vim FTP >> site. You can update those files from there. Scripts have >> been provided for 'nix and Windows to update local files. > Only script I found on www.vim.org to help with updating runtime > files involves use of AAP. If there are other scripts, please > provide an exact link to them. They are in posts to this mailing list. >> For Windows, using 4nt, this one-liner will do the update: >> >> copy /[!*~]/u/s ftp://ftp.vim.org/pub/vim/runtime/dos vrt: >> >> where vrt: is a directory alias for my $VIMRUNTIME. > I am surprised that NT supports /[!*~] as an option to a command! > > Anyone know of a version of this command for XP? I'm using XP. As I mentioned, that copy command is for 4nt - a commercial shell replacement for cmd. The switches I'm using are: /[!*~] Skips all filenames ending with "~" /u Only download new or newer files /s Include subdirectories I don't believe cmd supports ftp or http as source or target of its copy command. I'm not familiar with its switches. > I can use perl's lwp-rget to down-load the runtime files to a > separate directory. I can then over-write the entire $VIMRUNTIME > with the downloaded stuff, but do not know how to merely update > $VIMRUNTIME. If you work from the command line, 4nt is an excellent tool - you'll never have to put up with the limitations of cmd again. You can read about it at: http://www.jpsoft.com/ BTW, it doesn't run on NT - only on 2000, XP, 2003 and Vista. -- Best regards, Bill
Re: Updating $VIMRUNTIME on Windows
Suresh Govindachar wrote: Bill McCarthy recently wrote to vim-dev and others: > Runtime files are kept fairly well updated at the Vim FTP > site. You can update those files from there. Scripts have > been provided for 'nix and Windows to update local files. Only script I found on www.vim.org to help with updating runtime files involves use of AAP. If there are other scripts, please provide an exact link to them. > For Windows, using 4nt, this one-liner will do the update: > > copy /[!*~]/u/s ftp://ftp.vim.org/pub/vim/runtime/dos vrt: > > where vrt: is a directory alias for my $VIMRUNTIME. I am surprised that NT supports /[!*~] as an option to a command! Anyone know of a version of this command for XP? I can use perl's lwp-rget to down-load the runtime files to a separate directory. I can then over-write the entire $VIMRUNTIME with the downloaded stuff, but do not know how to merely update $VIMRUNTIME. --Suresh I don't know a purely native-Windows way of doing it (though I suspect Bill might). If you have a functioning rsync program (maybe a Cygwin version) you could try the "Unix" method to keep the runtime directory up-to-date. The following maintains the runtime/ subdirectory tree which has the same parent as the src/ directory used to compile Vim; you can then update $VIMRUNTIME from it locally (not wasting bandwidth). Don't use this as written (changing the last argument) to update $VIMRUNTIME directly because this would remove all executables in it or under it, since it removes everything in the local tree that is not found in the remote one (a great feature, so obsolete files won't give you any trouble). I suppose that even if you don't compile Vim yourself, you could use this to keep a phony "runtime" directory up-to-date (and that if you create an empty "runtime" directory under the current directory, the first run of this command will populate it): rsync -avzcP --delete --exclude="/dos/" ftp.nluug.nl::Vim/runtime/ ./runtime/ The above also assumes that you use "unix-format" versions of the runtime files (i.e. with LF only rather than CR+LF as end-of-line marker); this is marginally more economical (one byte per line), and it is OK for Vim as long as your 'fileformats' option includes "unix" (which is the default). Notepad (but not Vim and not WordPad) chokes on the LF-only ends-of-lines but I suppose you can live with that. Best regards, Tony.
Updating $VIMRUNTIME on Windows
Bill McCarthy recently wrote to vim-dev and others: > Runtime files are kept fairly well updated at the Vim FTP > site. You can update those files from there. Scripts have > been provided for 'nix and Windows to update local files. Only script I found on www.vim.org to help with updating runtime files involves use of AAP. If there are other scripts, please provide an exact link to them. > For Windows, using 4nt, this one-liner will do the update: > > copy /[!*~]/u/s ftp://ftp.vim.org/pub/vim/runtime/dos vrt: > > where vrt: is a directory alias for my $VIMRUNTIME. I am surprised that NT supports /[!*~] as an option to a command! Anyone know of a version of this command for XP? I can use perl's lwp-rget to down-load the runtime files to a separate directory. I can then over-write the entire $VIMRUNTIME with the downloaded stuff, but do not know how to merely update $VIMRUNTIME. --Suresh
background process in gvim
In my gvim under linux, I can't run a background process but I can do so in vim. I remember I can do it in gvim under windows. What would be the possible cause of that? Thanks.
Re: How to filter only portion of a line, and not the whole line?
On 2007-01-28, ben lieb <[EMAIL PROTECTED]> wrote: > I have decided to write some perl filters for vim, but was disappointed > that it seems I can only filter WHOLE LINES (and not selected parts of > lines). Is this true? > > I found that... > > :'<,'>!my_filter.pl > > ...is given the whole line, even when only two words in the middle of > the line are selected. Is there any way to send only parts of lines and > not the whole line(s). There is a plugin that lets you do this, vis.vim. You can find it here: http://vim.sourceforge.net/scripts/script.php?script_id=1195 HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: How to filter only portion of a line, and not the whole line?
ben lieb wrote: Greetings Vim Users! This is my first post, so Hello all from North Carolina! I have decided to write some perl filters for vim, but was disappointed that it seems I can only filter WHOLE LINES (and not selected parts of lines). Is this true? I found that... :'<,'>!my_filter.pl ...is given the whole line, even when only two words in the middle of the line are selected. Is there any way to send only parts of lines and not the whole line(s). Thanks in advance for any and all help, and since this is my first post, I want to say a big THANK YOU to all those in the vim dev community for maintaining such a powerful tool! Filters are line-oriented. If you want to give only part of a line (or a blockwise visual selection, which is part of several lines) to a filter, one possible workaround is to extract whatever you want to filter to a temporary buffer and filter that. Best regards, Tony.
Re: replacing with a newline
Bill McCarthy wrote: On Sat 27-Jan-07 11:15pm -0600, you wrote: Ok, here is a question: Why not keep it the same, \n? Any reasoning behind it? That could be a way to do it, but that choice wasn't made. Perhaps someone else could explain why \n means end-of-line in the pattern, but nul in the substitution, while \r means ^M in the pattern, but end-of-line in the substitution? And why not a \x representation for nul in the pattern - instead of needing to do a [EMAIL PROTECTED] [Note: ^M is created with ctrl-v following by and ^@ is created by ctrl-v followed by 000.] IIUC, NULs are replaced by LF everywhere in Vim memory, because a NUL terminates a C string while a LF is the only ASCII character guaranteed not to exist (in Unix 'fileformat') in the middle of a line (as opposed to at its end). So if lines are stored as C strings, substituting NUL for LF and vice-versa allows representing everything. (Mac 'fileformat' may required some fancy footwork; Dos 'fileformat' is handled by treating either CR+LF or LF as a linebreak on input, and writing all linebreaks as CR+LF on output.) Why not use the same character in "replace by" as in "search for" is harder to explain, though. Maybe part of it is for historical "compatibility" reasons, but it doesn't explain why that choice was made by whoever made it. It may have something to do with the fact that hitting at the keyboard generates a CR but is stored (in memory) as a line break then (on file, if in Unix 'fileformat') as a LF. Best regards, Tony.
