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

673Re: windows and unicode filenames, etc.

Expand Messages
  • Bram Moolenaar
    Aug 5 12:09 PM
    • 0 Attachment
      Glenn Maynard wrote:

      > Just a quick update on other fixes:
      >
      > Editing files with Unicode in the filename that don't fit in the ANSI
      > codepage doesn't work. Fixed, except for the browser, and except for
      > renaming (since I don't really want to go near win32's mch_rename, but
      > it does need fixing.)

      I thought it did work for some DBCS encodings. I did include patches
      for this in the past.

      > The IME didn't work when encoding=ucs2 (or other utf-8-but-not
      > encodings.) Fixed: use ucs2_to_penc. This also does away with
      > CONV_UCS2_TO_DBCS and CONV_DBCS_TO_UCS2 completely.

      You still need to do the conversions, right?

      > Treat all Windows codepages as DBCS, since there's no difference between
      > DBCS and SBCS in Windows (SBCS is just DBCS with no lead-bytes). We
      > talked about this, and I've hit more problems due to enc_dbcs not being
      > set when encoding is set to an SBCS CP.

      This has a big drawback: for DBCS codes finding the start of a character
      is complicated and slow. Don't want to use the same code for single
      byte encodings. There are quite a few other places where DBCS is
      handled much slower.

      Isn't it easier to ignore enc_dbcs where the code needs to be used for
      both encodings?

      > Non-ASCII in the titlebar is problematic. I know the problem and the fix,
      > but I havn't done this yet.
      >
      > I've added getacp() for Windows, to get the active codepage; this allows
      > people to use the enc=utf-8;fencs=ucs-bom,utf-8,cp####,latin1;fenc=cp####
      > setup without having to hardcode their codepage (which most people
      > probably don't know.) This setup seems to have the desired effect:
      > utf-8 internally, current codepage as a higher-priority option for files
      > than the ambiguous latin1, and the current codepage as the default flie
      > encoding.

      That sounds good, but we should look very carefully for any problems
      with backwards incompatibilities.

      > I'll probably revert removing the broken Korean stuff and just comment out
      > the call for now; I doubt it's needed, but it's not important.

      Still didn't find someone who can tell when the code is really needed?

      > I won't throw these patches at you yet. Instead, I'll probably be compiling
      > these, describing the patches and the problems they fix better, and making
      > binaries available to make them more accessible and try to get some testing
      > done. Due to the scope of these changes, I suspect you'll want to wait a
      > while on this.

      Good, I prefer including tested patches!

      --
      hundred-and-one symptoms of being an internet addict:
      108. While reading a magazine, you look for the Zoom icon for a better
      look at a photograph.

      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
      /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
      \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
      \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
    • Show all 6 messages in this topic