> > > Can you please do something about your line wrapping? Trying to read > your messages is getting rather annoying. >
if you are reffering to me I do my best with manual wrapping, I can use for the moment only the web browser to write email, and nothing else. > > 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.) could be faster. Could do some sort of lazy reading. That is if certain variable is set, than read in only the first part of the buffer. Read the rest only when needed. More: I understand that the datatype is a linked list. For read only mode (view) the buffer should be linear. Probably then reading would be faster. http://www.mobiphil.com/2008/06/opening-large-files-with-vim-is-however-slow/ 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. again data types used for view mode should not be the same as for editing mode. therefore if one would have an abstraction buffer with different implementations, for view mode and edit mode, than things could be improved. With object oriented languages that is easier to achieve, but it is possible with C, as we all know. > If this is in regard to the suggested C++ rewrite of Vim, then wow, just > wow. > I think you mixed the two things. StarWing was referring to better syntax parsing. Rewrite in c++ would be an option... But why not create a C++ wrapper around the existing VIM functionality and and and ... imagination 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. > That was discussed in this thread and the other one "plugin mechanism", rgrds, mobi phil being mobile, but including technology http://mobiphil.com --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
