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

56482Re: bug with getpos("'>")[2] with multibyte charactor?

Expand Messages
  • Tony Mechelynck
    Apr 3, 2010
    • 0 Attachment
      On 03/04/10 16:22, Yue Wu wrote:
      > Hi list,
      > Don't know if it's a bug or feature, but when in visual mode, if I select just
      > one multibyte charactor, say "我", getpos("'>")[2] will return a value the
      > same as getpos("'<")[2], but in fact, a multibyte should occupy multi columns
      > so it should be a value larger than getpos("'<")[2]'s.

      Unless 'virtualedit' is set, getpos() returns values corresponding to
      the start position of a character. So if only one character was
      highlighted by the latest Visual selection, '< and '> will be the same,
      even if that character occupies more than one screen column.

      If you set 'virtualedit' to "all", then the cursor can be positioned in
      the middle of the space occupied by a hard tab, or (presumably) on the
      2nd cell of a CJK fullwidth glyph. In that case you'll see a difference
      in getpos('.')[3] which will be nonzero to tell you you aren't at the
      start of a character. getpos('.')[2] will still be on the start cell of
      the character in question IIUC.

      I don't think that marks can be set halfway a character anyway, even
      with 'virtualedit' nonempty. (Or can they?)

      Best regards,
      Parts that positively cannot be assembled in improper order will be.

      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

      To unsubscribe, reply using "remove me" as the subject.
    • Show all 3 messages in this topic