On 7月17日, 上午12时11分, Nikolai Weibull <[email protected]> wrote:
> On Thu, Jul 16, 2009 at 03:41, StarWing<[email protected]> 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.
>
First of all, I'm sorry for my textwidth, I had set it to 70, it
defaultly 78, which too long for this mail list.
> 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.
OK. but do you know how Vim hand memory and how Vim read a file? what
text file you use? I tell you: yes, if it's a "normal" text, Vim is
fast than most of editor, but, you can try use Vim to open "test" file
generated by this simple C program:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int i = 10000000;
freopen("test", "w", stdout);
while (i--)
printf("this is a fucking long line?");
return 0;
}
yes, it's a big long line. and you know what Vim do? in my Vim
7.2.228, it dead. just lost respond. and take 100% CPU usage.
just add a \n at the end of string, Vim can open this file in 7s. Why?
because Vim reads logical line, not block, it makes Vim obtain memory
unlimitly when it meet a long line. this is just one thing I want
change. in a lot of fucking fact of Vim.
>
> > 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.
What good algorithm? the algorithm Linus write in a OS. yes, a text
editor is really hard. I know. that's why I'm not write it now. I need
learn more things to balance, to make choice. I know it hard, but Vim
is not prefect, I just want Vim prefect. makes Vim fast than all of
other editors, and full extendable.
BUT, Vim is success, it has a lot of experience. I will read all of
its code, after understand it, I will begin my work. not now. because
I know it's hard.
IMHO, I want a new text editor, it has multithread, do on-the-fly
service background, it manage memory fast and clever, all of memory
are have ref-count and copy-on-write. yes, I'm not thinking about to
write a editor, I'm thinging about to write a Operation-system based
on Vim. that's my private hobby, I'm not beg you to join me.
>
> > 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.
Yes. A omni-completer for C++ language. just like VisualAssist on
Visual Studio, that's one of my plan. but must after I finished my
prefect Vim (in my mind), so maybe you can use it after 5 years.
> 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.
i Must to say: I DON'T WANT "REWRITE" Vim. and I don't want even do it
in C++. I want to build framework to Vim, change some parts of it
(especially reguiar expression and memory manage), and fix old vim
code into new framework. current Vim is a big gold mine, rewrite is
just impolicy. AND, I think C is the best language to implement a
portable text editor.
My Plan: port a fast reguiar expression to Vim (Vim's current regex
module is hell terrible), make a middle level script language (not a
macro language in current Vim now, but current Vim-script will hold
in, for the big amount of scripts avalible now), a better memory
manager as the subordinate of the script system. and a better undo
system (since history issue, Vim's undo system is more or less
terrible), and a flesh new parser-base highlight system. all in all,
what I should do is just invente a new language for Vim. that's all
(maybe with a little other things.)
thanks for attention it. I just treat it as hobby (just as Bram do), I
planed pay years on it. I know Vim is a success software, I will not
throw it away. all I do is make it prefect, in C.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
