On Fri, Jul 23, 2010 at 2:06 PM, Nikolai Weibull <[email protected]> wrote: > On Fri, Jul 23, 2010 at 19:33, James Vega <[email protected]> wrote: >> On Fri, Jul 23, 2010 at 1:25 PM, Nikolai Weibull <[email protected]> wrote: > >>> Sort of like a modeline? > >> Sort of, except modelines can be at the top or the bottom of the file > > And one could easily scan from the beginning or end of the file, sort > of like we already do for a modeline. > >> and are processed after the buffer has been loaded. > > Which I already noted should be processed before the buffer has been > loaded, at least for options that affect the fundamental processing of > the buffer, for example, 'fileencoding'. > >> This would have to be part of the process of loading the buffer, > > Not necessarily. > >> which is why the places that do allow it require the information >> to be at the top of the file. > > <meta/> may actually appear anywhere in the document, if places is > referring to HTML processors (which of course don’t have to respect > it). > > Look, I never suggested that this was going to be easy, but there’s no > point in making it harder (by adding some separate control sequence). > Ruby already looks for the 'fileencoding' option in a Vim modeline > when trying to determine the encoding of a file.
Doing it *properly* (eg, for all supported encodings) would definitely be difficult, but I can envision a quick hack that works for single-byte encodings: 0) Start handling a :e command 1) remember what 'fenc' was set to before any modelines were handled 2) handle modelines 3) if fenc has changed, implicitly do an :e ++enc=&fenc (and whatever other flags) (goto 0) I think that should work fine as long as the modeline is a valid modeline in both encodings, which should be true for all single-byte encodings and utf-8, but won't hold for utf-16, utf-32, etc... Any thoughts? If I'm not missing anything, it should be possible to make vim handle the simplest (and most useful, since they can't be unambiguously detected automatically) case without breaking things any worse than they are for more complicated cases. ~Matt -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
