On 03/03/09 06:40, James Vega wrote:
> 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.
UTF-8 support is pretty much standard on any recent Unix-like OS, though
its use by default is not necessarily universal. I don't know about
Vista, but on XP the default was _not_ to have UTF-8 as the system
default encoding.
>
>> 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.
With +multi_byte is always bigger than -multi_byte: one reason could be
making the Vim binary really "lean and mean". Personally I keep two Vim
builds on this computer: a Huge build named vim, with GTK2/Gnome2 GUI
(and +multi_byte), used via softlinks for most possible executable
names, and a Tiny build named vi (with no GUI and -multi_byte).
>
>> 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.
I recommend it for users who need or want to use various encodings, and
possibly plurilingual files mixing them. Users with simpler needs may
quite validly leave 'encoding' at whatever their OS locale sets, and
never stray away from it.
>
>> 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.
>
Hm, to use one of your earlier arguments, it might make the code more
complex, and thus add some bloat and possibly some bugs, where the
present code cannot really be said to be malfunctioning. "If it ain'
broke, don' fix it."
Best regards,
Tony.
--
Why is "abbreviation" such a long word?
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
