Re: Vim 8.0 Suggestion
Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). Martin -- Martin Krischik mailto://[EMAIL PROTECTED] pgpfEiBREWv3r.pgp Description: PGP signature
Re: Vim 8.0 Suggestion
On 1/30/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). How do you mean? A lot of editors work like this. The Atari Editor is hardly the first, or last, editor to work this way. Sam works this way, Wily works this way, my editor ned works this way, James Brown's example editor Neatpad [1] works this way. It's usually down to the data structure used to manage buffer contents that defines whether it's possible to implement this feature or not. It's can also be down to support for various encodings that can require preprocessing of the files. I'm not sure to what degree Vim requires the whole file to be read before editing can commence. I'm, however, sure that it can be made to load files without too much preprocessing, but I'm also pretty sure that it would require a lot of work and I don't think it's worth the kind of time that Bram would have to invest in such a feature. Vim is, when it all comes down to it, designed to be a programmers editor, and that means that it'll mostly work with files smaller, mostly much smaller, than a megabyte, for which preprocessing works fine. nikolai nikolai [1] http://www.catch22.net/
Re: Vim 8.0 Suggestion
Nikolai Weibull wrote: On 1/30/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). How do you mean? A lot of editors work like this. The Atari Editor is hardly the first, or last, editor to work this way. Sam works this way, Wily works this way, my editor ned works this way, James Brown's example editor Neatpad [1] works this way. It's usually down to the data structure used to manage buffer contents that defines whether it's possible to implement this feature or not. It's can also be down to support for various encodings that can require preprocessing of the files. I'm not sure to what degree Vim requires the whole file to be read before editing can commence. I'm, however, sure that it can be made to load files without too much preprocessing, but I'm also pretty sure that it would require a lot of work and I don't think it's worth the kind of time that Bram would have to invest in such a feature. Vim is, when it all comes down to it, designed to be a programmers editor, and that means that it'll mostly work with files smaller, mostly much smaller, than a megabyte, for which preprocessing works fine. nikolai nikolai [1] http://www.catch22.net/ IIUC, Vim loads the whole file in memory before starting to edit. It might be possible (but not necessarily worth the trouble on modern computers with their large memory and their huge virtual-memory addressing ranges) to only keep parts of the file in memory; but: - depending on the syn-sync setting, it may be necessary to scan part or all of the file in front of the edit point, even repeatedly, in order to synchronize the syntax highlighting properly. - if many scattered changes are made without saving the file, they may have to be written to the (Vim) swapfile, then later read from swap, causing a performance degradation over time. (I realize that for files which are larger than the available RAM, reading the whole file in memory actually always includes some virtual memory, which is OS swap, and not necessarily better managed than Vim swap.) - A command such as :$ or G (goto last line) can be implemented by seeking to EOF then scanning backwards; but for :8752 or 8752G (go to line 8752) I see no other possibility than counting the 8751 first ends-of-lines (if there are that many, of course), which means scanning the whole file until there. Of course, any search also requires scanning from the current location to the next match in the search direction (and the whole file if there is no match and wraparound is set). Loading the whole file in memory at the start allows building an index (or something) which will later allow lightning-fast access to any line given by number. I see this as an advantage when line numbers are known, e.g. when trying to evaluate a patch by looking at the parts of the source that it will change if applied, or when using a tagfile with line numbers (as opposed to a tagfile with search patterns). (And, yes, the index could be built incrementally as later parts of the file are accessed, but then a forward seek might seem to hang just because it goes to a part of the file not yet read from disk.) Vim is not only a programmer's editor (in the sense of an editor which can be used to edit source programs: even Notepad can do that). It can do any kind of editing, and it is particularly useful for complex editing tasks. If it is a programmer's editor, it is most importantly an editor which can be programmed (in five programming languages [six in version 7] including vimscript, which is a full structured-programming language for text, string, and integer processing). Unlike many other editors, it can handle any kind of text, including Unicode text, even if the underlying OS has no input method usable for arbitrary Unicode codepoints. The biggest file I'm currently using it for is 33.8 million bytes long. That file does take some time to load, and searching when there is no match, or no nearby match, does take a measurable time; but IMHO it remains bearable. Best regards, Tony.
Re: Vim 8.0 Suggestion
Dominique Pelle wrote: My wishlist for vim-8.0: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. This could perhaps have been useful ten years ago, but computers are now fast enough not having to do this. Lazy file loading causes quite a few problems: - You don't know how many lines there are, the CTRL-G command would not work. - If the file changes after starting to read it you get a big mess. - If the file is deleted after starting to edit it the user may be very surprised he lost the text. Recovery will also be impossible. - You quickly end up loading the whole file anyway if you search for a pattern without a match, do G, etc. - define spelling checker language for different part of the file (probably using syntax file). In the following example, I would like to let the spelling checker know that msgid strings are be English and msgstr are in French. msgid Any authenticated user msgstr Tout utilisateur authentifié This is in the todo list somewhere. It's not difficult to implement, mostly a question of how to define what language applies where. - option to ignore accent differences when searching for strings (a bit like :set ignorecase) ex: searching for cafe could find café /caf[[=e=]] I don't think we want yet another option to change the meaning of patterns. It's difficult enough as it is. -- Proof techniques #2: Proof by Oddity. SAMPLE: To prove that horses have an infinite number of legs. (1) Horses have an even number of legs. (2) They have two legs in back and fore legs in front. (3) This makes a total of six legs, which certainly is an odd number of legs for a horse. (4) But the only number that is both odd and even is infinity. (5) Therefore, horses must have an infinite number of legs. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Vim 8.0 Suggestion
On 1/31/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 1/30/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). How do you mean? A lot of editors work like this. The Atari Editor is hardly the first, or last, editor to work this way. Sam works this way, Wily works this way, my editor ned works this way, James Brown's example editor Neatpad [1] works this way. It's usually down to the data structure used to manage buffer contents that defines whether it's possible to implement this feature or not. It's can also be down to support for various encodings that can require preprocessing of the files. I'm not sure to what degree Vim requires the whole file to be read before editing can commence. I'm, however, sure that it can be made to load files without too much preprocessing, but I'm also pretty sure that it would require a lot of work and I don't think it's worth the kind of time that Bram would have to invest in such a feature. Vim is, when it all comes down to it, designed to be a programmers editor, and that means that it'll mostly work with files smaller, mostly much smaller, than a megabyte, for which preprocessing works fine. nikolai [1] http://www.catch22.net/ IIUC, Vim loads the whole file in memory before starting to edit. It might be possible (but not necessarily worth the trouble on modern computers with their large memory and their huge virtual-memory addressing ranges) to only keep parts of the file in memory; but: [a list of reasons why preprocessing may be a hidden cost of commands being run on the file at around load-time anyway.] That is all true, but under certain conditions it may still be the case that pre-loading the whole file is unnecessary. Loading the whole file in memory at the start allows building an index (or something) which will later allow lightning-fast access to any line given by number. Considering that lightning travels at the speed of light, I'd say that this is an overestimation of the line-lookup routines. Vim is not only a programmer's editor (in the sense of an editor which can be used to edit source programs: even Notepad can do that). My statement was more about the size of a typical file loaded into Vim than its specific uses. I consider(ed) that to be obvious. nikolai
Vim 8.0 Suggestion
I'd like to see an external .vimrc editor shipping with gVim and directly accessible from within easy mode (e.g. on the tools menu). The editor would likely be a totally separate binary though, so maybe a separate project is called for. What I have in mind is a tabbed dialog (depending on platform), that behaves like any native dialog on the target platform. So under windows you would have OK, Apply and Cancel (assuming that applying .vimrc changes to an active vim window is even possible). Only the most basic settings would be provided (obviously). This is intended for users absolutely new to gVim. Tabs might include: - Shortcuts (mappings), grouped by mode, sorted by keystrokes - Abbreviations, similar to above (a.k.a. Auto-correct or Auto-complete) - Per-language settings (smartindent, formatoptions, textwidth) - Appearance (colors, fonts, line numbering, titlebar text, tabbar text, status bar text, window chrome features) - Syntax Highlighting Colors (a.k.a. a colorscheme editor) - Behaviors (search behavior, mouse behavior, command history, scroll offset, foldmethod, etc) Also, it would be nice to have native Win32 help (chm). This would annoy most of us but new users would really like to see this I think. Again, this can be an external project. Also, a real built in file browser would be nice (e.g. a sidebar similar to that in EasyEdit). Actually an optional Browser Tabpage showing a Windows Explorer-like view would be killer on Win32. Oh, and the ability to add a New Tab button to the tab bar. Double-clicking does not work properly when you are using a text-mode tab bar. Just brainstorming. -Robert
