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

1002Re: Filename encodings under Win32

Expand Messages
  • Bram Moolenaar
    Oct 13, 2003
    • 0 Attachment
      Glenn Maynard wrote:

      > 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()

      The default that Vim starts with is 'encoding' set to the active
      codepage and 'fileencoding' set to "ucs-bom". This means it falls back
      to 'encoding' when there is no BOM. That should work almost the same
      way as what you give here, but without the explicit use of the codepage
      name. When the user sets 'encoding' the other ones follow. In your
      example the user has to set all three options.

      Perhaps setting 'termencoding' can be omitted if we can use the Unicode
      functions for keyboard input. Perhaps someone can figure out how to do
      this properly. And make use the input methods still work!

      > Note that "getacp" is a function in a patch I sent which was lost or
      > forgotton: return the ANSI codepage.

      Can't recall that patch. I generally give OS-specific additions a low
      priority.

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

      The problem still is that conversion from and to UTF-8 is not
      transparent. Especially when editing files with an unknown encoding.

      > 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).

      UTF-8 is already fully supported in Vim. They may be a few glitches on
      the conversions though. The clipboard also still doesn't work 100%.

      --
      hundred-and-one symptoms of being an internet addict:
      182. You may not know what is happening in the world, but you know
      every bit of net-gossip there is.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
    • Show all 29 messages in this topic