Loading ...
Sorry, an error occurred while loading the content.

993Re: Filename encodings under Win32

Expand Messages
  • Glenn Maynard
    Oct 12, 2003
    • 0 Attachment
      On Sun, Oct 12, 2003 at 10:44:05PM +0200, Tony Mechelynck wrote:
      > As long as 'fileencoding', 'printencoding' and (most important)
      > '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.

      This is a trivial fix, which I already proposed many months ago: the
      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 gvim
      > 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.

      The input in a Windows window is well-defined; "termencoding" should not
      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
      the same:

      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' and
      > '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.

      Switching "encoding" to "utf-8" should be transparent, once proper
      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).

      Glenn Maynard
    • Show all 29 messages in this topic