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

Bug report and IME suggestions

Expand Messages
  • alexandre.elias@mail.mcgill.ca
    Hi, I ve been using vim 6.1/w2k/GUI with GIME support for my Japanese text editing for some days now. Generally I ve been impressed by how solid the support
    Message 1 of 12 , Jun 3, 2002
    • 0 Attachment
      Hi,

      I've been using vim 6.1/w2k/GUI with GIME support for my Japanese text
      editing for some days now. Generally I've been impressed by how solid
      the support is, but I found a bug and some misfeatures. Here they are:


      These two problems are unrelated to the IME:

      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.

      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.

      Also, it really needs to be a separate variable: using the value of
      "termencoding" is no good. My "termencoding" needs to be latin1,
      because I also use vim to input French accented characters, and that
      won't work with any other encoding. Also, if I set my "termencoding" to
      SJIS, weird stuff happens like my tilde key producing a square and my
      backslash key producing a yen symbol.



      These two problems are with the IME support:

      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.

      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.



      Thanks,

      Alexandre Elias
    • Glenn Maynard
      ... 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
      Message 2 of 12 , 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
      • Bram Moolenaar
        ... This sounds like a font problem. I don t find a remark in the Unicode list for character 0x25CF to be double width. ... This has been discussed, and the
        Message 3 of 12 , Jun 4, 2002
        • 0 Attachment
          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.

          This sounds like a font problem. I don't find a remark in the Unicode
          list for character 0x25CF to be double width.

          > 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.
          >
          > Also, it really needs to be a separate variable: using the value of
          > "termencoding" is no good. My "termencoding" needs to be latin1,
          > because I also use vim to input French accented characters, and that
          > won't work with any other encoding. Also, if I set my "termencoding" to
          > SJIS, weird stuff happens like my tilde key producing a square and my
          > backslash key producing a yen symbol.

          This has been discussed, and the conclusion was a bit too complicated to
          explain here. Ron Aaron sent a patch to the vim-dev list for this May 6.

          > These two problems are with the IME support:
          >
          > 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.

          Isn't it so that most IMEs allow you to type English by default?

          I notice that when you do ":help IME" you don't find 'iminsert'. You
          probably didn't get the idea to read the introduction in this file...
          I'll copy the remark from the start of the file to here.

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

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

          Sounds like a good idea to use the color to indicate whether IME is
          enabled (not using 'iminsert'). But do we really always know when IME
          is on?

          > - 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 don't understand this. You just said the cursor color doesn't
          changed, and now it does?

          --
          I AM THANKFUL...
          ...for the mess to clean after a party because it means I have
          been surrounded by friends.

          /// 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 ///
        • Bram Moolenaar
          ... 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
          Message 4 of 12 , Jun 4, 2002
          • 0 Attachment
            Glenn Maynard wrote:

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

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

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

            Well, the Asian people made it work this way for a reason. Perhaps we
            should let it depend on the locale being used on the system? When using
            some latin encoding, it doesn't make sense to start IME. On the other
            hand, when using Unicode it won't be possible to guess what to do.

            --
            From "know your smileys":
            :.-( Crying

            /// 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
            ... 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. ... They
            Message 5 of 12 , Jun 4, 2002
            • 0 Attachment
              On Tue, Jun 04, 2002 at 08:50:03PM +0200, Bram Moolenaar 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.

              > Well, the Asian people made it work this way for a reason. Perhaps we
              > should let it depend on the locale being used on the system? When using
              > some latin encoding, it doesn't make sense to start IME. On the other
              > hand, when using Unicode it won't be possible to guess what to do.

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

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

              --
              Glenn Maynard
            • Glenn Maynard
              ... The IME in Windows, when enabled, enters Japanese by default. If I want to enter English, I turn it off. (Actually, reverse that; if I want to type
              Message 6 of 12 , Jun 4, 2002
              • 0 Attachment
                On Tue, Jun 04, 2002 at 08:35:44PM +0200, Bram Moolenaar wrote:
                > > 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.
                >
                > Isn't it so that most IMEs allow you to type English by default?

                The IME in Windows, when enabled, enters Japanese by default. If I want
                to enter English, I turn it off. (Actually, reverse that; if I want to
                type Japanese, I turn it on, because *all* applications--except Vim--have
                it off by default.) Vim's the only application being odd here; it
                explicltely enables the IME, which is something that no other program I
                know of does.

                Remember that different IM's will behave differently. Sanee defaults for
                iminsert and imsearch are dependent upon which IM is being used. For
                Windows IMs, the sane default is 0.

                > > 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.
                >
                > Sounds like a good idea to use the color to indicate whether IME is
                > enabled (not using 'iminsert'). But do we really always know when IME
                > is on?

                Err, I'm a little confused. You agree with him, but the idea you say
                you agree with is the opposite of what he suggested. :)

                Right now, the cursor color reflects whether the IME is enabled (which
                is what you say); he's suggesting that, in normal and visual mode, it
                reflect iminsert instead of the real IME state. This depends upon his
                second suggestion (below), that the IME always be off in normal/visual
                mode. Since the current behavior may be preferable in X (or other
                environments), both of these would be better as an option (tied
                together), with the current behavior available, too.

                > > - 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 don't understand this. You just said the cursor color doesn't
                > changed, and now it does?

                This is under the heading "what I think would be the best behavior";
                it's a suggestion.

                --
                Glenn Maynard
              • 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 7 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 "$B#5(B". 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 8 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 9 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 10 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 11 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 12 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.