>>No disrespect intended, but *why* in B'Harni's Dark Name would you
>>want to join >10000 lines into 1?!?
>There might be usecases. Data is growing rapidly today, and I myself
>had to manage automatically generated text-files of several hundred MB
>of size. Plus there have occasionally been questions on this list
>regarding joining lines.
Even so, something which I can understand, eg, a logfile, should be
delineated by linebreaks. Raw xml/sgml/etc., should be edited as a
sequence of modestly-sized lines, then if necessary, joined to a single
line after saving (or before saving, if you have the time :D ).
>Well just one simple test:
>#v+
>~$ for i in 1 2 4 8 16 32 64 128; do
> seq 1 $(($i*1000)) >tempfile
> echo "joining $i kilo lines"
> time vim -u NONE -N -c ':%join|:q!' tempfile;
>done
>#v-
>and compare the timings yourself. Doesn't this look like a bug to you?
I have no idea, as I didn't run it yet. Offhand, an exponential
increase wouldn't be out of the question, ie, e^n.
Don't forget *physical* limits such as available memory. Once you bang
your head on that memory-ceiling and start having to swap to disk, all
bets are off, and processing time can increase by order*s* of magnitude,
depending how bad it is. Hell, I run into that in *perl*, let alone
'gvim', when intentionally joining huge files to a single line to c&p
whole sections of the file! And I'm not even dealing with syntax
highlighting, colorschemes, and the like.
>>Any 'vi' variant is a *line*-based editor, which presumed a modest
>>line-size for each. Juggling lines back and forth is easy, but
heaving
>>huge MB-sized chunks o' text is just obscene. Add to that
syntax-based
>>highlighting, multiple colors, etc., and all the processing required
for
>>just *1* line adds exponentially to the amount of work involved, let
>>alone cursor motions, etc.
>Well Vim is an editor. Shouldn't it be able to join properly millions
>of lines, even if that sounds strange? The power of vim comes from
Sure, it should be able to be pushed to its limits and do so, but not
necessarily *efficiently*. Ie, it may hit that aforementioned ceiling
and then start hitting the disk to do so, and pretty much require you to
leave it running overnight to go and join a brazillion lines into 1
Uberline. That's not necessarily a "bug", just an unexpected excursion
of its performance envelope. The fact that it can create a huge
Uberline without *crashing* is a testament to the robustness of the
code. An old version of 'vi' I had would vomit on lines >300chars or
so.
Point being, *line*-editors are meant to be used with *lines*, and lines
of a modest size. The fact that it *can* handle Uberlines is great, but
you can't expect it to be handled "efficiently". The kind of advice I
might give would be along the lines of the guy who sees his doctor:
guy: "Doc, it hurts when I do this."
doc: "So don't do that."
>the fact, that you can do many different manipulations very
>efficiently and does not limit you.
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.
>Plus :h limits does not talk about joining only a couple of lines ;)
Of course not. I can 'ls' a list of filenames into a file, do a ':%j'
to get them into a single line, then prepend a command to run (with the
filelist as the list of files to operate on) and make an instant
batchfile. Works great. But there's a huge difference between a
batch-/shell-command that's 1000chars long, and a 1-line file with a
100Mchar Uberline.
>>Dunno, but to me, that seems like using a text editor to edit a .jpg
or
>>.gif or something, ie, not the right tool for the job, even if,
through
>>herculean contortions and torturing the editor's functionality, it
*can*
>>be done.
>Exactly. It can. And it might be done by someone.
And if he has the luxury of letting it run overnight, great. :D
>>I'd, if anything, edit the file as needed, save it, then use 'sed',
>>'tr', etc., to post-process it accordingly. No overhead for syntax,
>>colorschemes, etc. Ie, use the right tool for the job.
>Yeah, but sed, tr, awk, perl, $language is not always available. And
>Vim should be able to do it right.
>What was the reason again to add :vimgrep to vim when grep is
>available?
I have no idea, as I don't recall ever using it. <shrug/>
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.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
