On Thu, Jul 16, 2009 at 03:41, StarWing<weasley...@sina.com> wrote: >>> Of course I am not pretending to add a c++ compiler for the highlighting. >>> That would be against the basic principle "vim is the fastest editor". Any >>> feature
> no, IMHO vim is not the fastest editor. you can try use Vim open a 2GB > size > text. UltraEdit or even emacs is far more fast than Vim. Can you please do something about your line wrapping? Trying to read your messages is getting rather annoying. Anyway, where are you getting these “statistics” from? I just ran a simple test, opening a 185 MB text file in both editors. Vim took 7 seconds, Emacs 14 seconds. I don’t know about UltraEdit, but it’s going faster as it doesn’t need to load the whole file, last time I checked. (Things may have changed to accomodate variable-width encodings, which are always going to be an issue.) Just to be clear, I’m not trying to bash Emacs, I’m trying to bash you. > Vim just can > fast > boot and fast when you edit small texts, maybe some lazy-eval tricks > and good > algorithm will make Vim more fast. that's my goal. Goal? Have you thought this through further than writing this email? “Good algorithm”? Do you know anything about implementing a text editor? Let me tell you, as someone who has written two and devoted two years of research into the matter for my master’s thesis, that writing a text editor is fucking hard. Vim’s method of reading and managing a buffer may not be optimal, but it’s pretty good and writing something that’s better will require a lot of work. A big whole shitload of work. > and, add a c++ compiler is not slow. you only need parse current > function, > other informations can obtain in tag files. and you can do a lazy > parse. I > mean, if you want Vim fast and expendable (not just compatibles with > Vi), > you can do a lot of work :-) What are you talking about here? A C++ omni-completer? When did we begin discussing something like that in this thread? Right now? I’m not following. If this is in regard to the suggested C++ rewrite of Vim, then wow, just wow. Further, what the hell would rewriting Vim in C++ gain? Why is everyone’s who’s clearly slightly insane’s solution (to problems that often don’t even exist), ”Hey, have you considered rewriting it in C++”? What Vim needs is a clearer separation of concerns in the source code. Different subsystems depend too much upon each other. The overuse of #ifdef’s also makes the code rather hard to understand. What it doesn’t need is a rewrite. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
