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

Re: Bug report and IME suggestions

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.