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

665Re: mbyte.c patch

Expand Messages
  • Bram Moolenaar
    Jul 17, 2002
    • 0 Attachment
      Glenn Maynard wrote:

      > However, notice that one of the HanExtTextOut calls only does anything when
      > ImeGetTempComposition returns non-NULL, and that only happens when
      > bInComposition is TRUE.
      > 01:35am glenn@.../2 [~/vim/src] grep bInComposition *.c
      > gui_w32.c:static BOOL bInComposition=FALSE;
      > gui_w32.c: if (bInComposition == TRUE)
      > It looks like this was broken at some point. It's apparently written to
      > try to display a partially-composed Korean character with the Korean IME
      > in Windows.
      > I don't remember if this code predates the newer IME code; it might no
      > longer be necessary, now that the IME is being set up correctly.
      > (Perhaps the fact that it's not working and nobody's complained is
      > evidence?)

      This indeed looks very broken. ImeGetTempComposition() will always
      return NULL. It already was like this in 6.0. I didn't hear specific
      complaints about this. I suppose this means we might as well remove
      this code.

      > > We might as well do nothing. Most Japanese users are used to seeing the
      > > yen symbol in the place of a backslash anyway.
      > I view Japanese text in Vim daily, and I don't like seeing a backslash
      > there.

      Oh yes, the other way around it's not so nice.

      > The backslash-fix code is a trivial addition to my font-repair code, which
      > has other uses; in particular, fixing Unicode quotes in Japanese fonts.
      > So I, at least, don't mind if the current backslash fix code goes
      > away, since I have a replacement for it; and the current code is
      > extremely special case (system-font-size only?), to the point of not
      > really being useful. (And, like you said, if it *does* kick in, some
      > users probably won't want it.)

      It even uses floating point numbers. Let's get rid of this.

      > The solution to that is to use the system's conversions instead of iconv
      > for codepages. You're always using iconv if it's available (in fileio),
      > and never using MultiByteToWideChar in Windows. I'd blame Unicode problems
      > in Windows on that.
      > The only way I can see system conversions causing problems is if round-trip
      > conversion fails. I don't know of any cases of this, but if anyone does I'd
      > definitely like to know.

      Perhaps it goes wrong when the codepage is set wrong? This is
      especially for 8-bit codepages where you probably don't notice the
      mistake if you do use the right font. Conversion to Unicode will reveal
      the problem.

      > I'll work on making fileio use MBtoWC for codepage<->Unicode conversion
      > when possible. Even if you leave encodings as is, this will help.

      That is a good thing. More people will be able to use different
      encodings "out of the box".

      Engineers will go without food and hygiene for days to solve a problem.
      (Other times just because they forgot.)
      (Scott Adams - The Dilbert principle)

      /// 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 ///
      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
    • Show all 14 messages in this topic