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

Re: undo problem for Input Method

Expand Messages
  • Bram Moolenaar
    ... I don t understand why the cursor is moved. This appears to happen after inserting characters, thus moving cursor to before these inserted characters.
    Message 1 of 2 , Aug 25, 2006
    • 0 Attachment
      Yukihiro Nakadaira wrote:

      > I am using GTK2 GUI. When using Input Method, undo sequence is broken at
      > each start of multibyte character. For example, after insert some multibyte
      > characters (A B C),
      > line: A B C
      > Do undo
      > line: A B C
      > Do undo
      > line: A B
      > Do undo
      > line: A
      > Do undo
      > line:
      > I must undo four times to undo one insert command.
      >
      > When using Input Method, Left key is added to typeahead buffer by
      > mbyte.c:im_correct_cursor(). Then, the Left key command is interpreted and
      > later new undo sequence is started. To avoid this problem, check if
      > im_is_preediting() is true in start_arrow().
      >
      > Thanks.
      >
      >
      > *** edit.c.orig Fri Aug 25 06:14:48 2006
      > --- edit.c Fri Aug 25 06:14:55 2006
      > ***************
      > *** 6026,6031 ****
      > --- 6026,6035 ----
      > start_arrow(end_insert_pos)
      > pos_T *end_insert_pos; /* can be NULL */
      > {
      > + #if defined(FEAT_XIM) && defined(FEAT_GUI_GTK)
      > + if (im_is_preediting())
      > + return; /* XIM is busy, don't break an undo sequence */
      > + #endif
      > if (!arrow_used) /* something has been inserted */
      > {
      > AppendToRedobuff(ESC_STR);

      I don't understand why the cursor is moved. This appears to happen
      after inserting characters, thus moving cursor to before these inserted
      characters. Hmm, it appears they are later deleted with the Del key.

      I find it a little bit dangerous to simply return from start_arrow().
      To make this a bit more strict perhaps the call to start_arrow() in
      ins_left() can be skipped when im_is_preediting() returns TRUE?

      --
      A computer without Windows is like a fish without a bicycle.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
    • Yukihiro Nakadaira
      ... Cursor is moved just for displaying. And also cursor can be positioned at middle of preedit string. Those inserted characters are preedit string. Preedit
      Message 2 of 2 , Aug 26, 2006
      • 0 Attachment
        Bram Moolenaar wrote:
        > I don't understand why the cursor is moved. This appears to happen
        > after inserting characters, thus moving cursor to before these inserted
        > characters. Hmm, it appears they are later deleted with the Del key.

        Cursor is moved just for displaying. And also cursor can be positioned
        at middle of preedit string.

        Those inserted characters are preedit string. Preedit string is
        temporarily inserted to show what is to be inserted (like a Vim's
        completion). It can be edited with Input Method until it is committed.
        "commit" means inserting edited string. When preedit string is changed,
        it is deleted and new preedt string is inserted. When preedit string is
        committed, it is deleted and the edited string is inserted really.

        > I find it a little bit dangerous to simply return from start_arrow().
        > To make this a bit more strict perhaps the call to start_arrow() in
        > ins_left() can be skipped when im_is_preediting() returns TRUE?

        I agree with you. I think that im_is_preediting() returns TRUE only
        when start_arrow() is called from ins_left().

        --
        Yukihiro Nakadaira - yukihiro.nakadaira@...
      Your message has been successfully submitted and would be delivered to recipients shortly.