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

642Re: Bug report and IME suggestions

Expand Messages
  • Glenn Maynard
    Jun 4, 2002
    • 0 Attachment
      On Mon, Jun 03, 2002 at 10:12:44PM -0400, alexandre.elias@... wrote:
      > 1) The character with Unicode value 0x25cf (a large filled circle) is
      > the length of 2 latin letters, but vim seems to treat it as though it
      > were only 1 latin letter long. This leads to annoying graphical
      > glitches. I'm not sure if this is the same bug you were talking about
      > with mb_off2cell(), but I thought I would point it out anyway.

      wcwidth() thinks U+25CF is single-width, but it's double-width in the
      Windows fonts. This is a fairly common bug; it happens with Unicode
      open- and close-quotes in Japanese fonts, too.

      PuTTY works around this by always honoring wcwidth(); if a character in
      the font is double-width, but wcwidth(n)==1, it renders the character
      half-width. This fixes the desynch, but doesn't fix Unicode quotes
      properly, as they don't look reasonable when rendered half-width. I'm
      working on code to specifically render the right half of characters for
      a predefined set (in certain fonts), as well as to make a fake backslash
      in Japanese fonts by flipping the forward slash. It's functional, but
      currently too slow.

      Bram, if I can get this fix optimized and solid in PuTTY, would you
      consider a similar fix for win32 Vim? Some kind of workaround for
      mismatched widths is needed, and a specific workaround for Unicode quotes
      and the Japanese backslash/yen problem is extremely useful.

      > 2) There should be a "clipboardencoding" option that determines in what
      > encoding text copied to the Windows clipboard is. Always using Unicode
      > is all very nice in theory, but it's no good for those of us whose other
      > apps want SJIS or another legacy format. I think there is definitely a
      > need for this feature.

      Shouldn't Windows automatically convert from a Unicode clipboard to
      whatever the other application asks for? (That, or shouldn't the other
      application know to convert from Unicode?)

      There's a known problem: Vim doesn't convert to Unicode properly for the
      clipboard. AFAIK, this is being worked on. Are you sure this isn't the
      problem you're having?

      > 3) vim with GIME support defaults to having the IME turned on in insert
      > mode. This was very annoying for me, because most of the time I edit
      > English. I searched several hours for a feature allowing me to set it
      > off by default. It turns out the "iminsert" feature was exactly what I
      > wanted, but I only found it when I went into the source code to hack in
      > a different default myself :(.
      > I think "iminsert" should be displayed much more prominently in the
      > multibyte documentation. Also, I think there are strong arguments why
      > iminsert should be 0 (off) by default. When you decide to include IME
      > support as a feature of vim as shipped by default, it will baffle people
      > to have vim automagically switch to a CJK language without their having
      > done anything *at all* to request it. Just because I have an IME
      > installed doesn't mean I want to use it most or even some of the time.
      > Having an IME installed shouldn't cause such radical changes in the
      > default behavior of vim.

      I've pointed this out many times. Bram, this is a serious problem. I also
      spent a *long* time fixing this. iminsert and imsearch should default to 0 on
      Windows, at least when using Win2K/XP's IME. I'm not sure about other
      architectures; is there any reason not to make them simply default to 0?

      Alex, you probably also want to set "imsearch=0" or you'll get the same
      behavior in search mode.

      > 4) I have some gripes with the way the enabled/disabled status of the
      > IME is remembered by vim. There is no reason to ever want to enable the
      > IME in normal or visual mode. But I have frequently enabled the IME in
      > normal mode by mistake, only to change it back when I ineffectually type
      > a few commands and realize my error.
      > Here is what I think would be the best behavior:
      > - The cursor color should always reflect the value of "iminsert", even
      > when in normal mode. Right now in normal mode the cursor always
      > reverts to IME-disabled color, and I can forget whether I had it
      > enabled or not.
      > - When I enable the IME in normal or visual mode, vim "swallows" it and
      > keeps it disabled. But, it toggles the color of the cursor and also
      > toggles iminsert, so that the next time I go into insert mode the IME
      > status is changed.

      I agree that IME mode in these modes is useless, and that the IME should
      never be on in visual and normal modes.

      Glenn Maynard
    • Show all 12 messages in this topic