On 01/09/09 22:31, Gene Kwiecinski wrote:
[...]
> Absolutely, but again, recall that it's intended to be a *line*-editor.
> Not to appear facetious in repeating that again, but that's what
> 'vim'/'gvim' happens to be, a *line*-editor. You yank and put *lines*.
> You add *lines*. You delete *lines*. Hell, syntax highlighting becomes
> downright painful for overly-long lines that people wrote add-ons to
> stop highlighting after N columns! That should be Clue #1 that
> overly-long lines are not "natural" to a *line*-editor.
Not exactly an add-on, it's an option, viz., 'synmaxcol', rather recent
option at that: it was new in Release 7.0. At first I thought it was a
bug ("Hey! I don't get any highlighting past the n-th chracter on the
line!") (and I see the present default is 3000, but ISTR it was
originally 1000). Bram had to point me to the new option.
[...]
>> What was the reason again to add :vimgrep to vim when grep is
>> available?
The ":helpgrep" command appeared first (at patchlevel 6.1.423), to help
us find our lost needles in the huge haystack of help text. Once that
was there, adding a general-purpose internal grep (in version 7.0)
wasn't much additional work, and it was a help for platforms like
Windows, where the OS doesn't install an external grep -- sure, there
are GnuWin32, unxutils, MinGW, and the like, but you have to fetch one
of these grep versions yourself if you want to have one. With
":vimgrep", no need to check whether or not an external grep is
available; and, I repeat, from ":helpgrep" to ":vimgrep" it wasn't a big
step.
Another advantage is that ":vimgrep" is guaranteed to use exactly the
same regular expressions as are used everywhere else in Vim, while egrep
may use something just subtly different, and certainly not documented in
the Vim help.
>
> I have no idea, as I don't recall ever using it.<shrug/>
I did, about as soon as it appeared, with some "snapshot" of Vim 7.0aa
alpha.
>
>
> To reiterate, I *don't* want to appear to be argumentative, but I'm just
> saying that handing Uberlines is something that's *possible* in
> 'vim'/'gvim', but don't expect it to be handled "efficiently", not if
> it's well outside the usual performance envelope of file-editing.
I agree with that. Searching a file tens of megabytes long for a
not-too-complex regexp already takes some measurable time (maybe tens of
seconds); if you want to join a gigabazillion lines into one, Vim can do
it -- but expect it to take hours or even days rather than seconds, and
at, oh, let's say 99.5% CPU time. It's not even a hang -- it's just that
you gave it an enormous task to which it is ill-suited, and it's
uncompainingly and patiently grinding at it; when it's finished, it will
wait for the next command -- if by then you haven't lost patience and
interruped it or killed it. To efficiently join all lines of a big file,
use some program such as tr, which looks at the file characterwise
rather than linewise and makes a single pass through it. You can even
use it from within Vim, of course (see ":help filter").
Best regards,
Tony.
--
There once was a Scot named McAmeter
With a tool of prodigious diameter.
It was not the size
That caused such surprise;
'Twas his rhythm -- iambic pentameter.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
