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

Re: Bug report and IME suggestions

Expand Messages
  • Bram Moolenaar
    ... In Normal mode IME should always be off by default (and it can only be switched on by some key chord, I suppose). That it s on sounds like a bug. ... I
    Message 1 of 12 , Jun 4, 2002
    • 0 Attachment
      Glennn Maynard wrote:

      > They made it work this way in X, I believe--I'm not sure it's doing the
      > same thing in Windows. The current default behavior in Windows isn't
      > sane--you get IME input in normal mode by default, which simply doesn't
      > do anything useful.

      In Normal mode IME should always be off by default (and it can only be
      switched on by some key chord, I suppose). That it's on sounds like a
      bug.

      > In Windows, there's always a system encoding; we can always GetACP() and
      > see what the system is. Are there any Japanese users who are using the
      > Win2K/WinXP IME with Vim who can comment on this?

      I suppose most Japanese people are using their specific codepage, thus
      we should be able to check for that. Don't know how many people in
      other Asian countries use Unicode or their specific encoding.

      > >> 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.
      >
      > >This probably depends on what you are doing. You could map characters
      > >entered with IME to something useful.
      >
      > But the IME doesn't really work in normal mode. First, you have to press
      > enter after each input; to do "5j" in normal mode, I have to type
      > "5j(enter)". Second, IME input isn't generally handled cleanly; for
      > example, "5" in my IME gives me a wide 5, and Vim ignores "5". I have
      > to tell my IME (manually) to switch to narrow input. Third, if I do that:
      > "5(space)(enter)j(space)(space)(enter)" (spaces to toggle to narrow) works,
      > but "5j(space)(enter)" (which sends "5j" in a single message) does not; it
      > ignores it completely.
      >
      > If IM input in X is sane, that's fine; but it's not useful at all in
      > the Win2K IM.

      As I said, IME should be off in Normal mode, unless you explicitly typed
      someting to enable it. And then going in/out of Insert mode should
      disable it as well.

      --
      From "know your smileys":
      |-( Contact lenses, but has lost them

      /// 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 ///
    • Glenn Maynard
      ... I don t recall. However, Vim is very exceptional in enabling the IME explicitely (in any mode) by default. ... Who originally implemented the Windows IME
      Message 2 of 12 , Jun 4, 2002
      • 0 Attachment
        On Tue, Jun 04, 2002 at 11:05:09PM +0200, Bram Moolenaar wrote:
        > In Normal mode IME should always be off by default (and it can only be
        > switched on by some key chord, I suppose). That it's on sounds like a
        > bug.

        I don't recall. However, Vim is very exceptional in enabling the IME
        explicitely (in any mode) by default.

        > I suppose most Japanese people are using their specific codepage, thus
        > we should be able to check for that. Don't know how many people in
        > other Asian countries use Unicode or their specific encoding.

        Who originally implemented the Windows IME code? Maybe they can comment.

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

        > As I said, IME should be off in Normal mode, unless you explicitly typed
        > someting to enable it. And then going in/out of Insert mode should
        > disable it as well.

        We're not talking about the default here, we're talking about entering
        IME mode: it's not useful, and it'd be nice if toggling the IME in
        normal mode left the IME off and just toggled iminsert for the next time
        insert mode is entered.

        Also, since most of us use "i" to enter insert mode, we can't simply
        enter insert mode to turn the IME off: hitting i brings up hiragana
        "". (Yeah, I can hit the actual insert key, but I'm more likely to
        stumble for a moment and hit ^I to toggle the IME back off.)

        Anyway, the whole "don't toggle the IME in normal mode" is minor (to me).
        It doesn't happen to me very often, it'd just be a niceity; the iminsert
        default is far more important. Alex, if you want to argue for it (and
        code it), feel free. :)

        --
        Glenn Maynard
      • Glenn Maynard
        ... An incomplete list:
        Message 3 of 12 , Jun 4, 2002
        • 0 Attachment
          On Tue, Jun 04, 2002 at 03:11:09PM -0400, Glenn Maynard wrote:
          > > It would be good to avoid the display to be messed up. If just this one
          > > character isn't displayed correctly that's not much of a problem (leave
          > > out half of the pixel columns or just show one half?).
          >
          > It's at least five characters: U+25CF, U+2018, U+2019, U+201C, U+201D.
          > I'm considering throwing together a program to see if there are others.

          An incomplete list:


















          Putty renders these half-width. That generally looks bad, but is almost
          always better than just rendering the left half of the glyph. It's easy
          to do; create another font with half the normal width, so wide charcters
          end up normal width.

          This doesn't work for quotes. My patch to Putty to fix this (and, as a
          nice bonus, the backslash in Japanese fonts) is working; I'm caching the
          characters in HBITMAPs ahead of time, so it's a lot faster now. This
          fix are font-specific. (I might be able to devise a test to generalize
          the quote fix.)

          Do you want me to try to port this to Vim?

          For those curious, http://zewt.org/~glenn/backslash.jpg contains a
          screenshot of the results: single-width Unicode quotes and a repaired
          backslash in a Japanese font, along with the above characters rendered
          half-width.

          --
          Glenn Maynard
        • Bram Moolenaar
          ... [..] Phew, that s a lot. ... Sounds like a good idea. Does the same trick also work to turn a proportionally spaced font into fixed-width? That s an item
          Message 4 of 12 , Jun 5, 2002
          • 0 Attachment
            Glenn Maynard wrote:

            > On Tue, Jun 04, 2002 at 03:11:09PM -0400, Glenn Maynard wrote:
            > > > It would be good to avoid the display to be messed up. If just this one
            > > > character isn't displayed correctly that's not much of a problem (leave
            > > > out half of the pixel columns or just show one half?).
            > >
            > > It's at least five characters: U+25CF, U+2018, U+2019, U+201C, U+201D.
            > > I'm considering throwing together a program to see if there are others.
            >
            > An incomplete list:
            >
            >
            [..]

            Phew, that's a lot.

            > Putty renders these half-width. That generally looks bad, but is almost
            > always better than just rendering the left half of the glyph. It's easy
            > to do; create another font with half the normal width, so wide charcters
            > end up normal width.
            >
            > This doesn't work for quotes. My patch to Putty to fix this (and, as a
            > nice bonus, the backslash in Japanese fonts) is working; I'm caching the
            > characters in HBITMAPs ahead of time, so it's a lot faster now. This
            > fix are font-specific. (I might be able to devise a test to generalize
            > the quote fix.)
            >
            > Do you want me to try to port this to Vim?

            Sounds like a good idea. Does the same trick also work to turn a
            proportionally spaced font into fixed-width? That's an item on the todo
            list, since there aren't that many fixed-width fonts available. Might
            keep that in mind when writing the code (doesn't need to be implemented
            right away).

            --
            hundred-and-one symptoms of being an internet addict:
            93. New mail alarm on your palmtop annoys other churchgoers.

            /// 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 ///
          • Glenn Maynard
            ... I think it d use too much memory. (I have a different idea, using the width array parameter of the font rendering function.) I ll keep it in mind,
            Message 5 of 12 , Jun 5, 2002
            • 0 Attachment
              On Wed, Jun 05, 2002 at 10:32:28AM +0200, Bram Moolenaar wrote:
              > Sounds like a good idea. Does the same trick also work to turn a
              > proportionally spaced font into fixed-width? That's an item on the todo
              > list, since there aren't that many fixed-width fonts available. Might
              > keep that in mind when writing the code (doesn't need to be implemented
              > right away).

              I think it'd use too much memory. (I have a different idea, using the
              width array parameter of the font rendering function.) I'll keep it in
              mind, though.

              --
              Glenn Maynard
            • alexandre.elias@mail.mcgill.ca
              ... Yeah, I ll look into it and try to come up with a patch when I have the time. From what I ve seen of the code, intercepting and killing the IME in
              Message 6 of 12 , Jun 5, 2002
              • 0 Attachment
                On Tue, Jun 04, 2002 at 05:41:36PM -0400, Glenn Maynard wrote:
                > Anyway, the whole "don't toggle the IME in normal mode" is minor (to me).
                > It doesn't happen to me very often, it'd just be a niceity; the iminsert
                > default is far more important. Alex, if you want to argue for it (and
                > code it), feel free. :)

                Yeah, I'll look into it and try to come up with a patch when I have the
                time. From what I've seen of the code, intercepting and killing the IME
                in normal/visual mode shouldn't be very hard.

                This behavior is obviously desirable with the Windows IME, so IMHO it
                isn't necessary to add a new option. It's extremely silly to map a
                Japanese character to a vim command in Windows: in order to use it,
                you'd have to press alt-~ (IME enable key), type the character, press
                enter to confirm, and then press alt-~ again to disable the IME. It'll
                never happen. And the Windows IME support seems almost completely
                separate from the X support, so any change I would make wouldn't bother
                X users.

                Sounds like you guys are sorting out all of the other issues :). Thanks
                for looking into it.


                Alex
              Your message has been successfully submitted and would be delivered to recipients shortly.