993Re: Filename encodings under Win32
- Oct 12, 2003On Sun, Oct 12, 2003 at 10:44:05PM +0200, Tony Mechelynck wrote:
> As long as 'fileencoding', 'printencoding' and (most important)This is a trivial fix, which I already proposed many months ago: the
> 'termencoding' default (when empty) to whatever is the current value of
> 'encoding', the latter must not (IMHO) be set to UTF-8 by default.
> (Let's spell it out) In my humble opinion, Vim should require as little
> "tuning" as possible to handle the language interfaces the same way as the
> operating system does, and this means that, when the user sets nothing else
> in his startup and configuration files, keyboard input, printer output and
> file creation should default to whatever is set in the locale.
defaults in Windows should be the results of
exe "set fileencodings=ucs-bom,utf-8,cp" . getacp() . ",latin1"
exe "set fileencoding=cp" . getacp()
and now adding:
exe "set printencoding=cp" . getacp()
Note that "getacp" is a function in a patch I sent which was lost or
forgotton: return the ANSI codepage.
(A slightly safer default would be to remove "utf-8" from the search, to
prevent false matches.) I havn't found any problems with this; it's been
my default for a long time and I actively edit UTF-8 and CP932 files.
> If the user wants to handle Unicode files, is is quite possible to set gvimThe input in a Windows window is well-defined; "termencoding" should not
> to do it, even in Win98 systems like mine; but this requires, among other
> things, storing the previous value of 'encoding' into 'termencoding' because
> the user cannot, by a mere snap of the fingers, change his keyboard input
> from some national encoding to Unicode.
even be needed in Windows. Depending on which messages are trapped, the
input is always in the ANSI codepage or Unicode.
However, if it's being used anyway for some reason, then the solution is
exe "set termencoding=cp" . getacp()
The only reason I know of not to set "encoding" to "utf-8" is that Vim
doesn't do proper conversions for Win32 calls.
> used by (g)vim (namely, 'encoding', 'fileencoding', 'termencoding' andSwitching "encoding" to "utf-8" should be transparent, once proper
> 'printencoding', as well as a possible 8-bit encoding at the end of
> 'fileencodings') should, as I believe they already do, default directly or
> indirectly to whatever is set in the locale, and that a possible switchover
> to Unicode should be left to the voluntary and reasoned choice of the user.
conversions for win32 calls are in place. Regular users don't care
about what encoding their editor uses internally, any more than they
care about what type of data structures they use.
On the other hand, if utf-8 internally is fully supported, then utf-8
can be the *only* internal encoding--which would make the rendering
code much simpler and more robust. I remember finding lots of little
errors in the renderer (eg. underlining glitches for double-width
characters) that went away with utf-8, and I don't think Vim renders
correctly at all if eg. "encoding" is set to "cp1242" and the ACP
is CP932 (needs a double conversion).
- << Previous post in topic Next post in topic >>