Ben Fritz wrote:
I wonder if a different approach might help.
Vim already has :perldo, :pydo, etc. Perhaps a :perlmatch, :pymatch, etc. could
be added for basic searching in those languages?
There is also a patch in the todo list for :bvimgrep. Maybe a :bgrep command
could also be added. I think that would allow searching the current buffer
using whatever tool you like.
----
the perldo/pydo approaches seem (from what earlier folks said),
to be too limited and perhaps be too slow to be that useful. Those
commands don't work on the actual text, but on an internal form w/o
the EOL that doesn't allow for splitting or combining lines.
Another ugly Q comes up -- what is the internal form of the chars?
I.e. UTF-8?. If so, that's at least good from a perl-compat point of
view, but if not that could be another whole mess. Even in perl --
depends on what I'm doing, but I'll often localize the 'end-of-line' char
to 'null', and allow a single 'read' to read in an entire file into a
single scalar. Sometimes it's faster to do manipulations on the whole
buffer than try to use multiple manipulations on each line.
Ex: a mail message which has an empty line at the end of the header.
It's easier for mail processing to combine header lines that have been
split over multiple lines into 1 line. Trying to special case the
indents each time you pass over the headers for something really slows
down the traversal. But its usually necessary (at least for sanity's
sake) to make more than one pass over the header lines for sorting and
routing, but at the end of the header processing, the rest of the text
can be dumped out w/1 write statement -- a big win over writing things
out a line at a time, especially when writing over a network.
I still feel 'pain' in older mailers that use a 4K r/W size on network
I/O that is positively painful with modern networks that use Jumbo
packets of 9k or more. You are literally throwing away 55% of the
bandwidth on 1G or faster networks, and that's just the loss from the
low end. By the time you've progressed up the network stack, a multi-meg
email with a few pics attached and I'll see 30-60s send-times --- most
of it between sendmail and local client over a dedicated 10gb connection,
whereas using SMB, I've seen (*past tense*, w/all the new win10 updates
being forced upon Win7 users) file transfer speeds range between
400-600MB/s (w/a mostly cpu-bound limit). As MS has changed their
network stack to allow multi-cores to use more than one connection to a
server, that, I'm told, will only benefit win8 and above, they've really
done harm
to win7, which has the multi-streaming code put in its stack, but
is administratively prohibited from using it.
I'm not sure what would be faster -- trying to split file mods by line, or
handing back a huge array of pointers to text blocks (where each text
block would have to be marked as line-delineated, or 'raw'). That
sounds more like something where a tunable heuristic would be the most
flexible route -- not something likely to be seen in the near future, I'm
guessing.
Sigh.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
