On 23/07/10 20:06, Nikolai Weibull 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).
<meta> in an HTML document MUST be in the <head> part, which MUST be
before the <body> part — IOW, pretty near the top. In addition, the
description of the <meta http-equiv="Content-Type"> tag, which is where
the charset may appear, says that it SHOULD be as near the top as
possible; in practice, that would mean immediately after the <head>
opening tag.
Or the charset could be mentioned in the "Content-Type" HTTP header
(even before the document start) if there is one, or, for a Unicode
document, by means of a BOM, which MUST be at the very start of the
document, even before the <!DOCTYPE. Pretty near the top in all cases
for HTML I'd say.
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.
'fileencoding' shouldn't be set by a modeline because the modeline will
set the encoding-for-writing after (possibly) getting the
encoding-for-reading wrong, so you wouldn't even know if you've _got_ it
wrong. Some kind of "software metadata" to be read by an autocommand
might be acceptable, but if your custom function determines that the
'fileencoding' should be changed it should NOT change it by ":setlocal
fenc=foobar", but by rereading the file: ":if &ro || !&ma | view
++enc=foobar | else | e ++enc=foobar | endif". This will, of course,
entail a performance hit for any file whose encoding cannot be
determined without reading the file. I'm assuming you won't have both
EBCDIC and ASCII files on any system where Vim can handle both, or that
you can discriminate them before reading.
Best regards,
Tony.
--
The Fifth Rule:
You have taken yourself too seriously.
--
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
