On Thu, Jul 16, 2009 at 19:22, StarWing<[email protected]> wrote:
> On 7月17日, 上午12时11分, Nikolai Weibull <[email protected]> wrote:
>> 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?
Yes. Did you read my whole mail?
> 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;
> }
See, that’s sort of the problem. When you could use something simple like
% repeat 10000000; do echo "this is a fucking long line?"; done > test
you’re already thinking of a C program, 13 lines long.
> 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.
”Logical”? Am I getting my terminology mixed up or isn’t a logical
line what you get when you enable word wrapping?
By the way, Emacs has the exact same issue with this sort of file.
> What good algorithm? the algorithm Linus write in a OS.
I don’t follow this line of reasoning.
> IMHO, I want a new text editor, it has multithread, do on-the-fly
> service background
This is a desirable goal, yes. Having an editor support transactions
is a good goal and would allow background processing.
> it manage memory fast and clever, all of memory
> are have ref-count and copy-on-write.
Now you’re losing me again. What does this matter? Copy-on-write?
It seems that you’ve just read a book on operating-system design or
something and want to, ahem, rewrite Emacs.
> yes, I'm not thinking about to
> write a editor, I'm thinging about to write a Operation-system based
> on Vim.
Ah, there it is.
> that's my private hobby, I'm not beg you to join me.
May I then beg you to create a separate mailing list where discussion
revolving around this operating-system Vim can be had instead?
> 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.
...
> My Plan: port a fast reguiar expression to Vim (Vim's current regex
> module is hell terrible)
I thought this had already been done?.
> 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)
Hasn’t this also been done?.
> a better memory manager as the subordinate of the script system.
Memory manager for what memory use?
> and a better undo system (since history issue, Vim's undo system
> is more or less terrible)
Huh? What’s wrong with Vim’s undo?
> and a flesh new parser-base highlight system.
This I can live with.
By the way, I still haven’t written the article I was going to write
on this, but Vim’s current :syntax command is powerful enough to parse
LALR(1) grammars, and perhaps others as well, in a recursive descent
fashion.
> all in all,
> what I should do is just invente a new language for Vim. that's all
> (maybe with a little other things.)
You’re tone suggests that this is easy. Invent a language? And how
does that solve all the “problems” listed above?
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
