On Tue, Mar 03, 2009 at 03:32:45AM +0100, Tony Mechelynck wrote:
>
> On 03/03/09 01:40, James Vega wrote:
> > ...
> > 3) File encoding detection ('fencs') defaults to a value that is
> > unlikely to correctly work with most interesting (non-ascii) files.
> >
> > Defaulting 'enc' to UTF-8 helps address these problems.
> >
> > ...
> > 3) File encoding detection now has a sane default value which means new
> > users are less likely to encounter problems when editing files of
> > various encodings.
> > ...
>
> 1) When using gvim with GTK2 GUI, setting 'encoding' to UTF-8 is the
> preferred option, though not enforced. However in that case,
> 'termencoding' is fixed as UTF-8 (unchangeable) in the GUI. I wonder
> whether it is possible to configure a GTK2 build with --disable-multibyte.According to the help, "utf-8" hasn't been made the default for 'encoding' in GTK2 builds to prevent different behavior of the terminal and GUI versions. Since supporting multibyte is pretty much standard on any relatively recent OS, trending towards UTF-8 instead of the other way around seems more logical. > 2) Vim compiled with the --disable-multibyte configure option cannot use > UTF-8, or any other multibyte encoding; in fact it doesn't even accept > the 'encoding' option as valid. Is there a reason to allow building Vim without multibyte support? Always having multibyte support would make the code simpler/smaller. > 3) 'termencoding' (the encoding used for the keyboard and, in Console > mode, for the display) defaults to empty (which means, fall back to > 'encoding') except when running in GUI mode with GTK2. This means that, > by default, communication between Vim and the user is done in the system > locale. Unless 'encoding' is set in the user's ~/.vimrc, which in my experience is pretty common. I'm not sure how closely that aligns with the overall usage patterns, though. > 4) It _is_ possible to set 'encoding' to UTF-8 in the vimrc, with > appropriate safeguards, if used at the right spot in the "chronology" of > successive actions (and in particular, before defining mappings or > setting string option values including characters above 0x7F). As per my response to your previous point, 'termencoding' is less likely to be based on their locale even though it should always be based on their locale. > On this Linux box, my locale encoding is UTF-8, but that was not the > case when I acquired a serious interest in Vim: the latest version at > the time was some patchlevel of Vim 6.1 and I was using Win98. A > compelling reason for doing so would be a desire to create or edit > files using characters not supported by your system locale, for > instance multi-charset files in UTF-8 when the Windows locale is > Windows-1252, as it was (IIRC) on that W98 system mentioned above. Right, point 3 from my initial mail. > OTOH, changing the 'encoding' _after_ the end of startup, when you > already have one or more buffers loaded, is not something I would > recommend; it may lead to dataloss or file data corruption, depending on > how you do it. Exactly. > However, I believe that forbidding it by means of something in the C > code would probably be too harsh, and how would you do it? It _is_ > useful to test the value of 'encoding' at any time, or to use the > value to set something else (IOW, to use &encoding in an expression), > so the option should still exist after startup. I'm not suggesting removing read access to the option. I'm purely suggesting that write access is disabled after the startup scripts are sourced. Making this change to the source would be fairly trivial, especially if support for using :lockvar on options were implemented. > I don't think there is a precedent (is there?) for an option that can > be changed, but only until the last VimEnter autocommand (if any) > terminates. No, there isn't yet but 'encoding' seems like a good one to set the precedent. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[email protected]>
signature.asc
Description: Digital signature
