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

[PATCH] IM support with ATSUI rendering

Expand Messages
  • Kaoru YOSHIDA
    Hi, I wrote the VERY initial patch for supporting Input Manager when users enable ATSUI rendering. Basically what I did so far are followings. 1.
    Message 1 of 16 , Sep 1, 2008
    • 0 Attachment
      Hi,

      I wrote the VERY initial patch for supporting Input Manager when users
      enable ATSUI rendering. Basically what I did so far are followings.

      1. MMAtsuiTextView inherits MMTextView instead of NSview.
      The reason why I did so is simply because I didn't want to
      re-implement the Input Manager code for ATSUI rendering. Although
      I don't know what kind of side effect may occur due to this change,
      I haven't found any issues so far.

      2. draw markedText within drawRect() in MMAtsuiTextView.m
      (markedText is a string when users type characters with IM.)
      Since I couldn't figure out how markedText should be drawn with
      ATSUI rendering, I simply use drawAtPoint() to draw the markedText.
      It seems the position to be drawn is not proper, but I haven't
      figured out how to fix it.

      I really appreciate if anyone can comment or patch for the patch.

      Thanks,



      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Nico Weber
      Hi Kaoru, thanks a lot for helping to improve the Atsui renderer :-) ... Bjorn moved the code that is shared between MMAtsuiTextView and MMTextView to a class
      Message 2 of 16 , Sep 1, 2008
      • 0 Attachment
        Hi Kaoru,

        thanks a lot for helping to improve the Atsui renderer :-)

        On 01.09.2008, at 16:01, Kaoru YOSHIDA wrote:

        > I wrote the VERY initial patch for supporting Input Manager when users
        > enable ATSUI rendering. Basically what I did so far are followings.
        >
        > 1. MMAtsuiTextView inherits MMTextView instead of NSview.
        > The reason why I did so is simply because I didn't want to
        > re-implement the Input Manager code for ATSUI rendering. Although
        > I don't know what kind of side effect may occur due to this change,
        > I haven't found any issues so far.

        Bjorn moved the code that is shared between MMAtsuiTextView and
        MMTextView to a class MMTextViewHelper (see http://repo.or.cz/w/MacVim.git?a=commitdiff;h=8e360a39b9b4b66a758dfd73208bd8a8dce52cbc
        ). Both views delegate commonly needed functionality to this helper
        class. Do you think you could move the code needed for IM stuff to
        MMTextViewHelper and call that from both textview classes? That seems
        cleaner to me.

        >
        Nico

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        Hi Kaoru, ... This is a bad idea. There is a lot of stuff going on inside NSTextView that should not pollute the ATSUI class which is why we derive from
        Message 3 of 16 , Sep 1, 2008
        • 0 Attachment
          Hi Kaoru,

          2008/9/1 Kaoru YOSHIDA <to.kaoru@...>:
          >
          > I wrote the VERY initial patch for supporting Input Manager when users
          > enable ATSUI rendering. Basically what I did so far are followings.
          >
          > 1. MMAtsuiTextView inherits MMTextView instead of NSview.
          > The reason why I did so is simply because I didn't want to
          > re-implement the Input Manager code for ATSUI rendering. Although
          > I don't know what kind of side effect may occur due to this change,
          > I haven't found any issues so far.

          This is a bad idea. There is a lot of stuff going on inside
          NSTextView that should not "pollute" the ATSUI class which is why we
          derive from NSView to begin with. As Nico pointed out: the way to
          implement IM support is to move the current IM code from MMTextView
          into MMTextViewHelper and then call the MMTextViewHelper code both
          from MMTextView and from MMAtsuiTextView. It will require a bit more
          work, but it should not be too hard. I'd appreciate it a lot if you
          did this!

          > 2. draw markedText within drawRect() in MMAtsuiTextView.m
          > (markedText is a string when users type characters with IM.)
          > Since I couldn't figure out how markedText should be drawn with
          > ATSUI rendering, I simply use drawAtPoint() to draw the markedText.
          > It seems the position to be drawn is not proper, but I haven't
          > figured out how to fix it.

          Jiang is the ATSUI expert around here, but I think that you should be
          able to get away without knowing any ATSUI by calling

          - (void)drawString:(UniChar *)string length:(UniCharCount)length
          atRow:(int)row column:(int)col cells:(int)cells
          withFlags:(int)flags foregroundColor:(NSColor *)fg
          backgroundColor:(NSColor *)bg specialColor:(NSColor *)sp

          (phew!) from the ATSUI renderer in order to draw text. Be sure to
          call beginDrawing before that call, and endDrawing as well as
          setNeedsDisplay: after that call. Check out how it is done inside

          - (void)performBatchDrawWithData:(NSData *)data

          Now, I'm not 100% sure this will work but it should be possible to do
          something like it.

          Actually, since you are doing the drawing inside drawRect: you should
          not call setNeedsDisplay:, but you will have to make sure to do all
          the drawing _before_ the code that is currently in drawRect:. The
          idea of the ATSUI renderer is to draw everything to an offscreen
          surface (this happens inside performBatchDrawWithData:) and then
          simply copy the entire contents of that surface to the screen when
          drawRect: is called.

          Let me know if you need more specific help and I'll try to go into more detail.

          Thanks,
          Björn

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Kaoru YOSHIDA
          Hi Nico and Björn, Thank you for your quick responses. ... Yeah, I did know that MMTextViewHelper were implemented. The problem is that I cannot use
          Message 4 of 16 , Sep 1, 2008
          • 0 Attachment
            Hi Nico and Björn,

            Thank you for your quick responses.

            On 2008/09/01, at 23:48, björn wrote:

            > 2008/9/1 Kaoru YOSHIDA <to.kaoru@...>:
            >>
            >> I wrote the VERY initial patch for supporting Input Manager when
            >> users
            >> enable ATSUI rendering. Basically what I did so far are followings.
            >>
            >> 1. MMAtsuiTextView inherits MMTextView instead of NSview.
            >> The reason why I did so is simply because I didn't want to
            >> re-implement the Input Manager code for ATSUI rendering. Although
            >> I don't know what kind of side effect may occur due to this change,
            >> I haven't found any issues so far.
            >
            > This is a bad idea. There is a lot of stuff going on inside
            > NSTextView that should not "pollute" the ATSUI class which is why we
            > derive from NSView to begin with. As Nico pointed out: the way to
            > implement IM support is to move the current IM code from MMTextView
            > into MMTextViewHelper and then call the MMTextViewHelper code both
            > from MMTextView and from MMAtsuiTextView. It will require a bit more
            > work, but it should not be too hard. I'd appreciate it a lot if you
            > did this!

            Yeah, I did know that MMTextViewHelper were implemented.
            The problem is that I cannot use setMarkedText(), markedRante() and
            so on with the current ATSUI implementation, since NSview doesn't
            conform to NSTextInput. Here may be two solutions to call
            setMarkedText() and to support Input Manager with ATSUI rendering.

            1. Implement NSTextInput with NSView.
            2. MMAtsuiTextView inherits from NSTextView instead of NSView.

            I just thought implementing NSTextInput with NSView is kinda hard
            work and inheriting NSTextView seems much easier than it. Because
            NSTextView itself conforms to NSTextInput and I already implemented
            the similar code in MMTextView.m. But, if I should implement
            NSTextInput with NSView, I'll do it. Could you tell me which solution
            I should choose? or Is there another way to call setMarkedText()?

            >> 2. draw markedText within drawRect() in MMAtsuiTextView.m
            >> (markedText is a string when users type characters with IM.)
            >> Since I couldn't figure out how markedText should be drawn with
            >> ATSUI rendering, I simply use drawAtPoint() to draw the markedText.
            >> It seems the position to be drawn is not proper, but I haven't
            >> figured out how to fix it.
            >
            > Jiang is the ATSUI expert around here, but I think that you should be
            > able to get away without knowing any ATSUI by calling
            >
            > - (void)drawString:(UniChar *)string length:(UniCharCount)length
            > atRow:(int)row column:(int)col cells:(int)cells
            > withFlags:(int)flags foregroundColor:(NSColor *)fg
            > backgroundColor:(NSColor *)bg specialColor:(NSColor *)sp
            >
            > (phew!) from the ATSUI renderer in order to draw text. Be sure to
            > call beginDrawing before that call, and endDrawing as well as
            > setNeedsDisplay: after that call. Check out how it is done inside

            I tried to use drawString(). The problem when I used drawString() here
            is that I couldn't find a way to set "flags". You know the "flags" must
            change depending on whether "string" consists of single or multiple
            byte characters. I have no idea how to get such information...
            Is there any way to do that?
            If I use drawAtPoint(), I don't need to care about such issue. So I
            would prefer to using drawAtPoint() to draw characters with Input
            Manager, unless there's an issue to use drawAtPoint().

            Sorry for so many questions...

            Thanks,

            -- kaoru
            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Jjgod Jiang
            Hi Kaoru, ... If I were you, I ll definitely go the NSTextInput way, actually, implementing that protocol in NSView is not that hard, see vim-cocoa [1] and
            Message 5 of 16 , Sep 1, 2008
            • 0 Attachment
              Hi Kaoru,

              On Tue, 2 Sep 2008, Kaoru YOSHIDA wrote:
              > Yeah, I did know that MMTextViewHelper were implemented.
              > The problem is that I cannot use setMarkedText(), markedRante() and
              > so on with the current ATSUI implementation, since NSview doesn't
              > conform to NSTextInput. Here may be two solutions to call
              > setMarkedText() and to support Input Manager with ATSUI rendering.

              If I were you, I'll definitely go the NSTextInput way, actually,
              implementing that protocol in NSView is not that hard, see
              vim-cocoa [1] and Nally [2] for some similar code.

              [1]: http://github.com/jjgod/vim-cocoa/tree/master/src/gui_mac.m
              [2]: https://macbluetelnet.svn.sourceforge.net/svnroot/macbluetelnet/trunk/YLView.mm

              > I tried to use drawString(). The problem when I used drawString() here
              > is that I couldn't find a way to set "flags". You know the "flags" must
              > change depending on whether "string" consists of single or multiple
              > byte characters. I have no idea how to get such information...
              > Is there any way to do that?
              > If I use drawAtPoint(), I don't need to care about such issue. So I
              > would prefer to using drawAtPoint() to draw characters with Input
              > Manager, unless there's an issue to use drawAtPoint().

              Yes, that's trickier to implement, so I'd suggest simply draw marked
              text in -drawRect: with NSString drawAtPoint/drawInRect. The character
              width of these marked text is a bit different from other text (rendered
              by drawString), but it's acceptable.

              - Jiang


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Kaoru YOSHIDA
              Hi Jiang, Thank you for your so quick response!!! ... OK, I ll read the documents and implement with NSTextInput. I may ask you to help, once I face some
              Message 6 of 16 , Sep 1, 2008
              • 0 Attachment
                Hi Jiang,

                Thank you for your so quick response!!!

                On 2008/09/02, at 10:17, Jjgod Jiang wrote:

                > Hi Kaoru,
                >
                > On Tue, 2 Sep 2008, Kaoru YOSHIDA wrote:
                >> Yeah, I did know that MMTextViewHelper were implemented.
                >> The problem is that I cannot use setMarkedText(), markedRante() and
                >> so on with the current ATSUI implementation, since NSview doesn't
                >> conform to NSTextInput. Here may be two solutions to call
                >> setMarkedText() and to support Input Manager with ATSUI rendering.
                >
                > If I were you, I'll definitely go the NSTextInput way, actually,
                > implementing that protocol in NSView is not that hard, see
                > vim-cocoa [1] and Nally [2] for some similar code.
                >
                > [1]: http://github.com/jjgod/vim-cocoa/tree/master/src/gui_mac.m
                > [2]: https://macbluetelnet.svn.sourceforge.net/svnroot/macbluetelnet/trunk/YLView.mm

                OK, I'll read the documents and implement with NSTextInput.
                I may ask you to help, once I face some trouble.

                >> I tried to use drawString(). The problem when I used drawString()
                >> here
                >> is that I couldn't find a way to set "flags". You know the "flags"
                >> must
                >> change depending on whether "string" consists of single or multiple
                >> byte characters. I have no idea how to get such information...
                >> Is there any way to do that?
                >> If I use drawAtPoint(), I don't need to care about such issue. So I
                >> would prefer to using drawAtPoint() to draw characters with Input
                >> Manager, unless there's an issue to use drawAtPoint().
                >
                > Yes, that's trickier to implement, so I'd suggest simply draw marked
                > text in -drawRect: with NSString drawAtPoint/drawInRect. The character
                > width of these marked text is a bit different from other text
                > (rendered
                > by drawString), but it's acceptable.

                I also noticed the character width issue...

                Anyway, thank you again for your nice suggestion.

                -- kaoru

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Kaoru YOSHIDA
                Hi, I rewrote the code to support Input Manager with ATSUI rendering based on guys suggestion. So, what I did are followings. 1. Move some IM related
                Message 7 of 16 , Sep 2, 2008
                • 0 Attachment
                  Hi,

                  I rewrote the code to support Input Manager with ATSUI rendering
                  based on guys' suggestion. So, what I did are followings.

                  1. Move some IM related functions, like setMaredText(), unmarkText()
                  and so on, to MMTextViewHelper.

                  2. IM related functions in MMTextView and MMAtsuiTextView
                  simply call MMTextViewHelper's ones.

                  While the routines of drawing IM characters in both MMTextView and
                  MMAtsuiTextView are relatively similar, I implemented them separately.
                  Because the routine in MMTextView uses variables of MMTextStorage.

                  One big remaining implementation is -firstRectForCharacterRange in
                  MMAtsuiTextView. Since I couldn't figure out a way to implement this,
                  I really appreciate if anyone can do it.

                  Thanks,

                  -- kaoru


                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Jjgod Jiang
                  Hi Kaoru, ... Nice, that s what I ve been thinking. As I skimmed through the patch (btw, you seemed to attached a patch in quoted-printable encoding instead of
                  Message 8 of 16 , Sep 2, 2008
                  • 0 Attachment
                    Hi Kaoru,

                    On Tue, 2 Sep 2008, Kaoru YOSHIDA wrote:
                    > I rewrote the code to support Input Manager with ATSUI rendering
                    > based on guys' suggestion. So, what I did are followings.
                    >
                    > 1. Move some IM related functions, like setMaredText(), unmarkText()
                    > and so on, to MMTextViewHelper.
                    >
                    > 2. IM related functions in MMTextView and MMAtsuiTextView
                    > simply call MMTextViewHelper's ones.

                    Nice, that's what I've been thinking. As I skimmed through the patch
                    (btw, you seemed to attached a patch in quoted-printable encoding
                    instead of plain text), the following logic seemed unclear to me:

                    + if ([text isKindOfClass:[NSAttributedString class]]) {
                    + [self setMarkedTextAttributes:
                    + [NSDictionary dictionaryWithObjectsAndKeys:
                    + [ts fontWide], NSFontAttributeName,
                    ...
                    + nil]];
                    + } else {
                    + [self setMarkedTextAttributes:
                    + [NSDictionary dictionaryWithObjectsAndKeys:
                    + [ts font], NSFontAttributeName,
                    ...
                    + nil]];
                    }

                    Could you explain why would you choose 'fontWide' for marked
                    text in NSAttributedString and 'font' for NSString? Because
                    AFAIK, a marked text can contain both CJK characters *and*
                    Latin characters, say, I'm composing a Chinese word "如果",
                    then in certain state the marked text will be "如guo". In
                    that case, choosing 'fontWide' will not be appropriate since
                    normally we don't want to use 'fontWide' for Latin characters
                    "guo".

                    > One big remaining implementation is -firstRectForCharacterRange in
                    > MMAtsuiTextView. Since I couldn't figure out a way to implement this,
                    > I really appreciate if anyone can do it.

                    I think you can use preEdit{Row,Column} to calculate the rect.
                    In vim-cocoa, I used the following code:

                    - (NSRect) firstRectForCharacterRange:(NSRange)theRange
                    {
                    NSRect rect = NSMakeRect(FILL_X(gui_mac.im_col),
                    FILL_Y(gui_mac.im_row + 1),
                    theRange.length * gui.char_width,
                    gui.char_height);

                    rect.origin = FLIPPED_POINT(self, rect.origin);
                    rect.origin = [[self window] convertBaseToScreen:
                    [self convertPoint: rect.origin toView: nil]];

                    return rect;
                    }

                    Here gui_mac.im_{col,row} are equivalents to preEdit{Column,Row}.

                    - Jiang
                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • björn
                    ... The way it is done is by using int utf_char2cells(int c); which is defined in src/mbyte.c. Of course, being part of Vim you cannot call this function from
                    Message 9 of 16 , Sep 2, 2008
                    • 0 Attachment
                      2008/9/2 Kaoru YOSHIDA <to.kaoru@...>:
                      >
                      > I tried to use drawString(). The problem when I used drawString() here
                      > is that I couldn't find a way to set "flags". You know the "flags" must
                      > change depending on whether "string" consists of single or multiple
                      > byte characters. I have no idea how to get such information...
                      > Is there any way to do that?

                      The way it is done is by using

                      int utf_char2cells(int c);

                      which is defined in src/mbyte.c. Of course, being part of Vim you
                      cannot call this function from MacVim (it is not linked to the MacVim
                      executable). You could cut and paste parts of that function (some
                      bits of it you would not need) I guess but that's not very elegant.
                      Unfortunately, I don't know any other way to do this.

                      > If I use drawAtPoint(), I don't need to care about such issue. So I
                      > would prefer to using drawAtPoint() to draw characters with Input
                      > Manager, unless there's an issue to use drawAtPoint().

                      Well, if it works ok then the difficulties in using drawString: may
                      not be worth the effort. I don't mind sticking with that and seeing
                      how it goes for now.

                      Björn

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Kaoru YOSHIDA
                      Hi Jiang and Björn, ... This is a result of my trial-and-error hacking. The motivation to do so is to draw IM characters properly when the length of IM
                      Message 10 of 16 , Sep 2, 2008
                      • 0 Attachment
                        Hi Jiang and Björn,

                        On 2008/09/03, at 0:41, Jjgod Jiang wrote:

                        > Nice, that's what I've been thinking. As I skimmed through the patch
                        > (btw, you seemed to attached a patch in quoted-printable encoding
                        > instead of plain text), the following logic seemed unclear to me:
                        >
                        > + if ([text isKindOfClass:[NSAttributedString class]]) {
                        > + [self setMarkedTextAttributes:
                        > + [NSDictionary dictionaryWithObjectsAndKeys:
                        > + [ts fontWide], NSFontAttributeName,
                        > ...
                        > + nil]];
                        > + } else {
                        > + [self setMarkedTextAttributes:
                        > + [NSDictionary dictionaryWithObjectsAndKeys:
                        > + [ts font], NSFontAttributeName,
                        > ...
                        > + nil]];
                        > }
                        >
                        > Could you explain why would you choose 'fontWide' for marked
                        > text in NSAttributedString and 'font' for NSString? Because
                        > AFAIK, a marked text can contain both CJK characters *and*
                        > Latin characters, say, I'm composing a Chinese word "如果",
                        > then in certain state the marked text will be "如guo". In
                        > that case, choosing 'fontWide' will not be appropriate since
                        > normally we don't want to use 'fontWide' for Latin characters
                        > "guo".

                        This is a result of my trial-and-error hacking. The motivation
                        to do so is to draw IM characters properly when the length of IM
                        characters is longer than single line. Say if your window has 80
                        single byte character width for each line, and you start typing
                        IM characters at 77th column. In such a case, the third character
                        should appear at the next line as long as you type only two-byte
                        characters, right? To achieve this, I think an IM character should
                        have the same character width of a character which is drawn by
                        'native' MacVim. Based on this motivation, I introduced 'fontWide'.
                        So, this is somehow related to what you pointed out past.

                        My open question is why native and IM characters have different
                        character width. If both has the same width, we don't need to
                        be bothered this...

                        >> One big remaining implementation is -firstRectForCharacterRange in
                        >> MMAtsuiTextView. Since I couldn't figure out a way to implement this,
                        >> I really appreciate if anyone can do it.
                        >
                        > I think you can use preEdit{Row,Column} to calculate the rect.
                        > In vim-cocoa, I used the following code:

                        Great!
                        I implemented new code based on yours. Since I would like to show
                        a pop-up window more precious position, I added a little hack to
                        check which IM characters are selected.

                        Thanks,

                        -- kaoru


                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • björn
                        Hi Kaoru,Thanks for the patch(es). I ve looked at the last one and it is starting to look like it could be merged soon. I did some cleanup to your patch
                        Message 11 of 16 , Sep 3, 2008
                        • 0 Attachment
                          Hi Kaoru,

                          Thanks for the patch(es). I've looked at the last one and it is
                          starting to look like it could be merged soon. I did some cleanup to
                          your patch and am attaching it to this post (my cleanup is in a second
                          commit on top of yours so that you may easily see what I have
                          changed).

                          2008/9/3 Kaoru YOSHIDA <to.kaoru@...>:
                          >>
                          >> Could you explain why would you choose 'fontWide' for marked
                          >> text in NSAttributedString and 'font' for NSString? Because
                          >> AFAIK, a marked text can contain both CJK characters *and*
                          >> Latin characters, say, I'm composing a Chinese word "如果",
                          >> then in certain state the marked text will be "如guo". In
                          >> that case, choosing 'fontWide' will not be appropriate since
                          >> normally we don't want to use 'fontWide' for Latin characters
                          >> "guo".
                          >
                          > This is a result of my trial-and-error hacking. The motivation
                          > to do so is to draw IM characters properly when the length of IM
                          > characters is longer than single line. Say if your window has 80
                          > single byte character width for each line, and you start typing
                          > IM characters at 77th column. In such a case, the third character
                          > should appear at the next line as long as you type only two-byte
                          > characters, right? To achieve this, I think an IM character should
                          > have the same character width of a character which is drawn by
                          > 'native' MacVim. Based on this motivation, I introduced 'fontWide'.
                          > So, this is somehow related to what you pointed out past.
                          >
                          > My open question is why native and IM characters have different
                          > character width. If both has the same width, we don't need to
                          > be bothered this...

                          I think there is some kind of misunderstanding here (perhaps on my
                          part) so I'll try to clarify.

                          There are two different types of characters in Vim: "normal" and
                          "wide". The former take up one column whereas the latter take up two.
                          This distinction is in Vim and has nothing to do with IM. In your IM
                          code you have the check Jiang pointed out which determines if a whole
                          string of characters (the marked text) is wide or not by checking if
                          the string is of type NSAttributedString or NSString. This test, as
                          Jiang points out, is not correct when there are both wide and normal
                          characters in the marked text. The only way I can think of how this
                          (and other related problems in the IM code) could be fixed is to bring
                          over the utf_char2cells() function from Vim and use that to determine
                          which characters are wide or not.

                          >>> One big remaining implementation is -firstRectForCharacterRange in
                          >>> MMAtsuiTextView. Since I couldn't figure out a way to implement this,
                          >>> I really appreciate if anyone can do it.
                          >>
                          >> I think you can use preEdit{Row,Column} to calculate the rect.
                          >> In vim-cocoa, I used the following code:
                          >
                          > Great!
                          > I implemented new code based on yours. Since I would like to show
                          > a pop-up window more precious position, I added a little hack to
                          > check which IM characters are selected.

                          That looks better, but perhaps you can "merge" the MMTextView and
                          MMAtsuiTextView code and put it in the helper class so that both ATSUI
                          and the default renderer may benefit from the better placement of the
                          IM popup window? (You'll have to wrap the
                          boundingRectForCharacterAtRow:column: somehow to do this. You may
                          want to make the convertRow:column:toPoint: method public and
                          implement a similar one in ATSUI and then call this from the helper
                          and get rid of the boundingRectFor... method.) In my attached patch I
                          did something similar for setMarkedText: but I ran out of time for now
                          so maybe you can complete that part?

                          I've noticed that there are still some IM aspects that are missing in
                          ATSUI; e.g. there is no insertion point when editing marked text. If
                          you find the time it would be great if you could make the two
                          renderers have the same features. :-)

                          Thanks for your work,
                          Björn

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Kaoru YOSHIDA
                          Hi Björn, Sorry for late reply. I was kinda busy these days... ... I merged firstRectForCharacterRange: method into MMTextViewHelper class. In
                          Message 12 of 16 , Sep 8, 2008
                          • 0 Attachment
                            Hi Björn,

                            Sorry for late reply. I was kinda busy these days...

                            On 2008/09/04, at 4:26, björn wrote:

                            >

                            > That looks better, but perhaps you can "merge" the MMTextView and
                            > MMAtsuiTextView code and put it in the helper class so that both ATSUI
                            > and the default renderer may benefit from the better placement of the
                            > IM popup window? (You'll have to wrap the
                            > boundingRectForCharacterAtRow:column: somehow to do this. You may
                            > want to make the convertRow:column:toPoint: method public and
                            > implement a similar one in ATSUI and then call this from the helper
                            > and get rid of the boundingRectFor... method.) In my attached patch I
                            > did something similar for setMarkedText: but I ran out of time for now
                            > so maybe you can complete that part?

                            I merged firstRectForCharacterRange: method into MMTextViewHelper
                            class. In MMTextViewHelper, I wrote the following code to check
                            whether textView is MMTextView or MMAtsuiTextView. Since coordinate
                            axes of MMTextView and MMAtsuiTextView is different, I need to check
                            it.

                            + if (![textView isKindOfClass:[MMTextView class]]) {
                            + row = [textView maxRows] - row;
                            + on = -1;
                            + }

                            This may not be a good idea to do this in MMTextViewHelper. If not
                            appropriate, we should define a new function in MMAtsuiTextView
                            and call it from MMTextViewHelper. Since no appropriate function
                            name comes up to my mind, I didn't implement that way.
                            The patch file is 0003-XXXX.

                            > I've noticed that there are still some IM aspects that are missing in
                            > ATSUI; e.g. there is no insertion point when editing marked text. If
                            > you find the time it would be great if you could make the two
                            > renderers have the same features. :-)

                            I implemented this part in 0004-XXXX.
                            While I use drawInsertionPointAtRow: method to draw the insertion
                            point, the arguments are hard coded. If there's a smarter way,
                            could you let me know?

                            The patch 0005-XXX is to fix a drawing issue of Japanese/Chinese
                            characters with ATSUI rendering. So, the problem is when shifting
                            down those characters one or more lines, small black dots show up.
                            I don't know this is a proper way to fix it, but this fixes the
                            issue at least in my environment.

                            0001-XXX and 0002-XXX are patches you posted.

                            Thanks,

                            -- kaoru



                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Kaoru YOSHIDA
                            Hi Björn, Sorry for contiguous posts, but my last patches aren t compilable. The attached one should fix the issue. Thanks, -- kaoru ...
                            Message 13 of 16 , Sep 9, 2008
                            • 0 Attachment
                              Hi Björn,

                              Sorry for contiguous posts, but my last patches aren't
                              compilable. The attached one should fix the issue.

                              Thanks,

                              -- kaoru

                              On 2008/09/09, at 11:45, Kaoru YOSHIDA wrote:

                              > Hi Björn,
                              >
                              > Sorry for late reply. I was kinda busy these days...
                              >
                              > On 2008/09/04, at 4:26, björn wrote:
                              >
                              >>
                              >
                              >> That looks better, but perhaps you can "merge" the MMTextView and
                              >> MMAtsuiTextView code and put it in the helper class so that both
                              >> ATSUI
                              >> and the default renderer may benefit from the better placement of the
                              >> IM popup window? (You'll have to wrap the
                              >> boundingRectForCharacterAtRow:column: somehow to do this. You may
                              >> want to make the convertRow:column:toPoint: method public and
                              >> implement a similar one in ATSUI and then call this from the helper
                              >> and get rid of the boundingRectFor... method.) In my attached
                              >> patch I
                              >> did something similar for setMarkedText: but I ran out of time for
                              >> now
                              >> so maybe you can complete that part?
                              >
                              > I merged firstRectForCharacterRange: method into MMTextViewHelper
                              > class. In MMTextViewHelper, I wrote the following code to check
                              > whether textView is MMTextView or MMAtsuiTextView. Since coordinate
                              > axes of MMTextView and MMAtsuiTextView is different, I need to check
                              > it.
                              >
                              > + if (![textView isKindOfClass:[MMTextView class]]) {
                              > + row = [textView maxRows] - row;
                              > + on = -1;
                              > + }
                              >
                              > This may not be a good idea to do this in MMTextViewHelper. If not
                              > appropriate, we should define a new function in MMAtsuiTextView
                              > and call it from MMTextViewHelper. Since no appropriate function
                              > name comes up to my mind, I didn't implement that way.
                              > The patch file is 0003-XXXX.
                              >
                              >> I've noticed that there are still some IM aspects that are missing in
                              >> ATSUI; e.g. there is no insertion point when editing marked text. If
                              >> you find the time it would be great if you could make the two
                              >> renderers have the same features. :-)
                              >
                              > I implemented this part in 0004-XXXX.
                              > While I use drawInsertionPointAtRow: method to draw the insertion
                              > point, the arguments are hard coded. If there's a smarter way,
                              > could you let me know?
                              >
                              > The patch 0005-XXX is to fix a drawing issue of Japanese/Chinese
                              > characters with ATSUI rendering. So, the problem is when shifting
                              > down those characters one or more lines, small black dots show up.
                              > I don't know this is a proper way to fix it, but this fixes the
                              > issue at least in my environment.
                              >
                              > 0001-XXX and 0002-XXX are patches you posted.
                              >
                              > Thanks,
                              >
                              > -- kaoru
                              >
                              >
                              > <IM080909.tar.bz2>


                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • björn
                              Hi Kaoru, ... Ok, that looks a bit weird so I fixed it. Instead of manually converting from (rows,columns) to a pixel value I now supply the methods: -
                              Message 14 of 16 , Sep 9, 2008
                              • 0 Attachment
                                Hi Kaoru,

                                2008/9/9 Kaoru YOSHIDA <to.kaoru@...>:
                                >
                                > I merged firstRectForCharacterRange: method into MMTextViewHelper
                                > class. In MMTextViewHelper, I wrote the following code to check
                                > whether textView is MMTextView or MMAtsuiTextView. Since coordinate
                                > axes of MMTextView and MMAtsuiTextView is different, I need to check
                                > it.
                                >
                                > + if (![textView isKindOfClass:[MMTextView class]]) {
                                > + row = [textView maxRows] - row;
                                > + on = -1;
                                > + }
                                >
                                > This may not be a good idea to do this in MMTextViewHelper. If not
                                > appropriate, we should define a new function in MMAtsuiTextView
                                > and call it from MMTextViewHelper. Since no appropriate function
                                > name comes up to my mind, I didn't implement that way.
                                > The patch file is 0003-XXXX.

                                Ok, that looks a bit weird so I fixed it. Instead of "manually"
                                converting from (rows,columns) to a pixel value I now supply the
                                methods:

                                - (NSPoint)pointForRow:(int)row column:(int)col;
                                - (NSRect)rectForRow:(int)row column:(int)col numRows:(int)nr
                                numColumns:(int)nc;

                                I amended your patch number 0003 using those methods instead so that
                                the helper does not need to check if the text view is ATSUI or Cocoa
                                (attached).

                                While I was at it I fixed a minor detail in patch number 0002 and the
                                amended patch is also in the attached archive.

                                >
                                >> I've noticed that there are still some IM aspects that are missing in
                                >> ATSUI; e.g. there is no insertion point when editing marked text. If
                                >> you find the time it would be great if you could make the two
                                >> renderers have the same features. :-)
                                >
                                > I implemented this part in 0004-XXXX.
                                > While I use drawInsertionPointAtRow: method to draw the insertion
                                > point, the arguments are hard coded. If there's a smarter way,
                                > could you let me know?

                                I've run out of time now, but I'll check it tomorrow probably. The
                                color for the cursor could be taken from defaultForegroundColor I
                                suppose, but as for the shape and percentage I guess you just have to
                                hard-code it.

                                > The patch 0005-XXX is to fix a drawing issue of Japanese/Chinese
                                > characters with ATSUI rendering. So, the problem is when shifting
                                > down those characters one or more lines, small black dots show up.
                                > I don't know this is a proper way to fix it, but this fixes the
                                > issue at least in my environment.

                                That looks a bit weird, but I haven't had a time to check. What
                                happens if you change the text inset to something big like 10 pixels?
                                Isn't the text going to be drawn in the wrong place then? You can try
                                by typing the following line in Terminal:

                                defaults write org.vim.MacVim MMTextInsetTop 10

                                and restart. When you're done, enter the following in Terminal:

                                defaults delete org.vim.MacVim MMTextInsetTop

                                The patches I've attached replaces the corresponding ones in your
                                archive...so you'll still need to apply your patch 0001 before the two
                                I attach.

                                I'll get back to you when I've had a chance to look at patch 0004 and 0005.

                                Thanks,
                                Björn

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • björn
                                ... I have updated this patch a bit so that the color is now the proper cursor color (and not the foreground color as I suggested above). It is attached as an
                                Message 15 of 16 , Sep 10, 2008
                                • 0 Attachment
                                  2008/9/9 björn <bjorn.winckler@...>:
                                  >>
                                  >>> I've noticed that there are still some IM aspects that are missing in
                                  >>> ATSUI; e.g. there is no insertion point when editing marked text. If
                                  >>> you find the time it would be great if you could make the two
                                  >>> renderers have the same features. :-)
                                  >>
                                  >> I implemented this part in 0004-XXXX.
                                  >> While I use drawInsertionPointAtRow: method to draw the insertion
                                  >> point, the arguments are hard coded. If there's a smarter way,
                                  >> could you let me know?
                                  >
                                  > I've run out of time now, but I'll check it tomorrow probably. The
                                  > color for the cursor could be taken from defaultForegroundColor I
                                  > suppose, but as for the shape and percentage I guess you just have to
                                  > hard-code it.

                                  I have updated this patch a bit so that the color is now the proper
                                  cursor color (and not the foreground color as I suggested above). It
                                  is attached as an archive.

                                  >> The patch 0005-XXX is to fix a drawing issue of Japanese/Chinese
                                  >> characters with ATSUI rendering. So, the problem is when shifting
                                  >> down those characters one or more lines, small black dots show up.
                                  >> I don't know this is a proper way to fix it, but this fixes the
                                  >> issue at least in my environment.
                                  >
                                  > That looks a bit weird, but I haven't had a time to check. What
                                  > happens if you change the text inset to something big like 10 pixels?
                                  > Isn't the text going to be drawn in the wrong place then?

                                  This patch is indeed not working properly. You can't add the text
                                  inset to the drawing position in that way. What is the problem that
                                  you were trying to fix exactly? (A screenshot might help.)

                                  There are still some problems that I have noticed.

                                  1. The IM "popup" window is often too far to the right: see the
                                  attached screenshots

                                  2. The spacing of roman letters is sometimes wide when it should be
                                  normal as is also exhibited in the screenshot. This is the issue
                                  Jiang brought up earlier and which I've commented on twice before.

                                  I realize these issues are a bit hard to deal with because at the
                                  moment there simply isn't enough information to "get it right". If
                                  you find the time, maybe have a look at duplicating some of the code
                                  utf_char2cells() inside mbyte.c. Using such a function you would be
                                  able to decide whether to use the wide or normal font and that would
                                  potentially solve both of the above issues, but it would also
                                  complicate your existing code quite a bit. Since I don't use IM I
                                  can't really judge whether it is "worth it" to implement this just see
                                  this as an idea and decide for yourself if it makes sense.

                                  Finally, please look over the modified patched I've posted here and in
                                  my previous post (numbers 2, 3 and 4) and let me know if they look ok
                                  to you and I can start merging.

                                  Thanks,
                                  Björn

                                  --~--~---------~--~----~------------~-------~--~----~
                                  You received this message from the "vim_mac" maillist.
                                  For more information, visit http://www.vim.org/maillist.php
                                  -~----------~----~----~----~------~----~------~--~---
                                • björn
                                  ... Sorry, I forgot the screenshots. I m attaching them to this post. Björn --~--~---------~--~----~------------~-------~--~----~ You received this message
                                  Message 16 of 16 , Sep 10, 2008
                                  • 0 Attachment
                                    > There are still some problems that I have noticed.
                                    >
                                    > 1. The IM "popup" window is often too far to the right: see the
                                    > attached screenshots
                                    >
                                    > 2. The spacing of roman letters is sometimes wide when it should be
                                    > normal as is also exhibited in the screenshot. This is the issue
                                    > Jiang brought up earlier and which I've commented on twice before.

                                    Sorry, I forgot the screenshots. I'm attaching them to this post.

                                    Björn

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_mac" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  Your message has been successfully submitted and would be delivered to recipients shortly.