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

Bug report: Mouse events are interpreted with the wrong column

Expand Messages
  • Kevin Goodsell
    Using Vim built with GUI support in a terminal, and ttymouse set to xterm2, mouse clicks (as well as dragging events) in column 123 consistently register as
    Message 1 of 2 , Jun 30, 2013
    • 0 Attachment
      Using Vim built with GUI support in a terminal, and ttymouse set to
      xterm2, mouse clicks (as well as dragging events) in column 123
      consistently register as being in column 96. E.g., if a line of text
      contains 123 characters, clicking on the last character will position
      the text cursor on the 96th character instead of the 123rd.

      This seems to be caused by an inconsistency in how CSI (0x9b) is encoded
      in the input buffer. In getchar.c, fix_input_buffer() encodes CSI as a
      sequence of three bytes: K_SPECIAL, KS_EXTRA, and KE_CSI. (This only
      happens when GUI support is compiled in, but the GUI is not in use.)

      However in term.c, get_bytes_from_buf assumes that K_SPECIAL can only be
      followed by KS_ZERO or KS_SPECIAL. If it's not KS_ZERO, the result is
      treated as KS_SPECIAL.

      The result looks something like this:

      - When the user clicks in column 123, the terminal sends the column as
      123+32=155=CSI.
      - fix_input_buffer gets a CSI character, and replaces it with K_SPECIAL,
      KS_EXTRA, KE_CSI.
      - get_bytes_from_buf reads a K_SPECIAL character. It checks the next
      character and finds it is not KS_ZERO. It assumes the character must
      therefore be KS_SPECIAL, and produces the byte K_SPECIAL.
      - K_SPECIAL is 128. Interpreted as a terminal column, that is 128-32=96,
      so Vim sees the reported mouse column as 96.

      I see at least three contradictory ways for CSI to be encoded:

      1) In get_bytes_from_buf, the code appears to be looking for the
      sequence CSI, KS_EXTRA, KE_CSI.
      2) In get_bytes_from_buf, the comment says that CSI is encoded using the
      sequence CSI, KS_SPECIAL, KE_CSI.
      3) The actual sequence get_bytes_from_buf receives, and fix_input_buffer
      writes, is K_SPECIAL, KS_EXTRA, KE_CSI.

      I tested this on few different versions of Vim 7.2 and 7.3, including a
      new build of 7.3 patch 1278 from Mercurial, on Debian Squeeze and
      Jessie and Fedora 17, using xterm, Gnome terminal, Xfce terminal, and
      rxvt.

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... I can reproduce it. Strange that it works fine when ttymouse is set to sgr . Changing the unescaping in get_bytes_from_buf() appears to fix it. Thanks
      Message 2 of 2 , Jul 1, 2013
      • 0 Attachment
        Kevin Goodsell wrote:

        > Using Vim built with GUI support in a terminal, and ttymouse set to
        > xterm2, mouse clicks (as well as dragging events) in column 123
        > consistently register as being in column 96. E.g., if a line of text
        > contains 123 characters, clicking on the last character will position
        > the text cursor on the 96th character instead of the 123rd.
        >
        > This seems to be caused by an inconsistency in how CSI (0x9b) is encoded
        > in the input buffer. In getchar.c, fix_input_buffer() encodes CSI as a
        > sequence of three bytes: K_SPECIAL, KS_EXTRA, and KE_CSI. (This only
        > happens when GUI support is compiled in, but the GUI is not in use.)
        >
        > However in term.c, get_bytes_from_buf assumes that K_SPECIAL can only be
        > followed by KS_ZERO or KS_SPECIAL. If it's not KS_ZERO, the result is
        > treated as KS_SPECIAL.
        >
        > The result looks something like this:
        >
        > - When the user clicks in column 123, the terminal sends the column as
        > 123+32=155=CSI.
        > - fix_input_buffer gets a CSI character, and replaces it with K_SPECIAL,
        > KS_EXTRA, KE_CSI.
        > - get_bytes_from_buf reads a K_SPECIAL character. It checks the next
        > character and finds it is not KS_ZERO. It assumes the character must
        > therefore be KS_SPECIAL, and produces the byte K_SPECIAL.
        > - K_SPECIAL is 128. Interpreted as a terminal column, that is 128-32=96,
        > so Vim sees the reported mouse column as 96.
        >
        > I see at least three contradictory ways for CSI to be encoded:
        >
        > 1) In get_bytes_from_buf, the code appears to be looking for the
        > sequence CSI, KS_EXTRA, KE_CSI.
        > 2) In get_bytes_from_buf, the comment says that CSI is encoded using the
        > sequence CSI, KS_SPECIAL, KE_CSI.
        > 3) The actual sequence get_bytes_from_buf receives, and fix_input_buffer
        > writes, is K_SPECIAL, KS_EXTRA, KE_CSI.
        >
        > I tested this on few different versions of Vim 7.2 and 7.3, including a
        > new build of 7.3 patch 1278 from Mercurial, on Debian Squeeze and
        > Jessie and Fedora 17, using xterm, Gnome terminal, Xfce terminal, and
        > rxvt.

        I can reproduce it. Strange that it works fine when 'ttymouse' is set
        to "sgr".

        Changing the unescaping in get_bytes_from_buf() appears to fix it.
        Thanks for analyzing that.

        --
        Windows
        M!uqoms

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      Your message has been successfully submitted and would be delivered to recipients shortly.