On 03/03/09 01:40, James Vega wrote:
> With Vim's current behavior, 'encoding' is derived from the environment
> and 'fileencoding'/'termencoding' derive from 'encoding' (modulo
> 'fileencodings' affect on 'fenc'). This seems sub-optimal for various
> reasons.
>
> 1) Vim is using an internal encoding derived from the environment which
> may or may not be able to represent the different file encodings
> encountered when editing various files.
> 2) The encoding Vim uses for interpreting input from the user and
> determining how to display to the user is not directly derived from
> the user's environment.
> 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.
>
> 1) This is now a non-issue as Vim can internally represent all
> characters by converting them to their unicode counterpart.
> 2) This can be addressed by making 'tenc' derive its value from the
> environment instead of from 'enc', which is more in line with the
> behavior implied by the name.
> 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.
>
> This change would also allow eliminating 'encoding' as an option or,
> less drastic, disallowing changing 'enc' once the startup files have
> been sourced.
>
> Changing 'enc' in a running Vim session is a very common mistake to new
> Vim users that are trying to get their file written out in a specific
> encoding or editing a file that's not in their environment's encoding.
>
> The help already states that changing 'enc' in a running session is a
> bad idea, and I know from experience that it can cause Vim to crash[0].
> Taking the next logical step and preventing users from doing that
> (unless someone can provide a compelling reason to continue allowing it)
> makes sense and helps prevent potential data loss.
>
I have the following remarks:
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.
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.
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.
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). 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.
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. 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 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.
Best regards,
Tony.
--
BEDEVERE: Stand by for attack!!
[CUT TO enormous army forming up. Trebuchets, rows of PIKEMEN, siege
towers, pennants flying, shouts of "Stand by for attack!" Traditional
army build-up shots. The shouts echo across the ranks of the army.
We see various groups reacting, and stirring themselves in readiness.]
ARTHUR: Who are they?
BEDEVERE: Oh, just some friends!
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
