On 04/04/09 05:44, Dominique Pelle wrote: > > Tom Porter wrote: > >> We currently use an old version of the crisp editor (running in read- >> only mode) on our solaris boxes to view extremely large files, in some >> cases approaching 2G. The nice thing about crisp is that it will pull >> a small chunk of the file into memory and immediately display it, then >> as you scroll through the file, it will pull discard the first chunk >> and load another. You see the first screenful of data immediately, no >> matter what the file size, and you can limit the amount of memory that >> crisp uses without affecting the size of file you can load. > > ...snip... > > I would personally also enjoy something like that. It's something that > had already been discussed, at least in this thread: > > http://www.mail-archive.com/[email protected]/msg03165.html > > Being able to open a file quickly would be great. Rather than the > extreme solution of loading pages of the file in memory, I would not > mind if the file got loaded entirely in memory, as along as it's done > in a lazy way, i.e. pressing G to go to the end for example could > cause to wait until the file is entirely loaded (fine, doesn't "less" do > just that?). But browsing the top of the file could become > instantaneous. Perceived time when opening the file (to show the > top of the file) can be more important to users than actual time to > load the entire file. > > Unfortunately, it's probably not so simple to implement in Vim, > and there are other priorities. > > It probably also opens lots of questions. For example, > say I have this in my ~/.vimrc... > > set fileencodings=ucs-bom,utf-8,latin1
a rather common setting if you're a "Westerner" and your 'encoding' is set to UTF-8. I have the same. People from East Asia might have their favourite CJK encoding between utf-8 and latin1 but the reasoning below still applies, maybe even more strongly. > > .... so that Vim selects the encoding based on file content. > The top of the file might be valid-utf-8, but near the end, there > might be invalid utf-8 sequences. If Vim loads the file lazily, > it can't figure it out, so it can't select the encoding automatically > until it has read the entire file. It could be a documented limitation > when turning a lazy file loading option. But I'm sure there are > many other issues like this. > > I don't think this idea even appears on the already huge todo list > anyway. I searched in ":help todo.txt" and could not see anything > like that. > > In the mean time, there are settings which can help to speed > up Vim significantly when using large files. See: > > http://vim.wikia.com/wiki/VimTip343 > > Regards > -- Dominique ...not to mention modelines, which (if you set 'modeline' on and leave 'modelines' at its default) can be either in the first five or the last five lines of the file, so both ends have to be examined. OK, it might be possible to go to the 6th-last linefeed without reading everything that goes before it, but I'm not sure how to do it buglessly, and the capability to go to offset X from the end of the file without even reading what comes before could depend on the OS and/or on the filesystem type. And for multibyte encoding detection (see above) it's the _whole_ file which has to be examined in order to _keep_ a multibyte value like utf-8 anyway. (To _reject_ it, finding one invalid sequence is enough.) Best regards, Tony. -- Our policy is, when in doubt, do the right thing. -- Roy L. Ash, ex-president Litton Industries --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
