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

68326Re: [patch] [test] test if :mksession saves cursor columns correctly in presence of tab and multibyte characters

Expand Messages
  • Bram Moolenaar
    Feb 17, 2013
    • 0 Attachment
      Christian Brabandt wrote:

      > Hi Roland!
      >
      > On Sa, 16 Feb 2013, Roland Eggner wrote:
      >
      > > On 2013-02-06 Wednesday at 23:08 +0100 Bram Moolenaar wrote:
      > > > Roland Eggner wrote:
      > > > > > > :mksession writes wrong column number of cursor position in presence of
      > > > > > > multibyte characters.
      > > > > > >
      > > > > > > I have been using vim-7.3.135 with this patch applied for several
      > > > > > > months … it works for me:
      > > > > >
      > > > > > I do not see the problem. How to reproduce?
      > > > > >
      > > > > > Your patch can't be right, the "l" command moves over characters, not
      > > > > > columns.
      > > > >
      > > > > Session files created with :mksession restore cursor line and column,
      > > > > as long as there is no multibyte character between start of line and
      > > > > cursor. Otherwise, without my patch restored column is off by the
      > > > > difference between character position and byte position counted from
      > > > > start of line.
      > > > >
      > > > > With my patch applied, cursor line and column is restored correctly,
      > > > > with and without multibyte characters, with and without changing of
      > > > > options fileencoding or binary, even with files preprocessed by
      > > > > BufRead autocommands gzip -dc, bzip -dc, xz -dc, pdftotext, elinks
      > > > > -dump, antiword, … which I find pretty cool, use and enjoy it nearly
      > > > > every day.
      > > >
      > > > I asked how to reproduce. I suspect your 'encoding' matters.
      > > > Please start with "vim -u NONE" and check what the default value of
      > > > 'encoding' is then.
      > > >
      > > > Note that your patch most likely is wrong when there is a Tab before the
      > > > cursor, try that.
      > >
      > > Indeed, you are right: my patch beeing wrong was hidden by autocommands
      > > restoring cursor positions based on textmarks.
      > >
      > > For investigation of the problem I have created test{91,92}.
      > > In my environment (TERM=linux, unicode-mode) and with locale
      > > en_US.ISO-8859-1 both succeed, whereas with locale en_US.utf8 both fail:
      > >
      > >
      > > pushd vim-7.3.816
      > > patch -p1 -N -u -i my.patch.provided.below
      > > pushd src/testdir
      > > rm -f test{91,92}.{out,failed,messages}
      > > env {LANG,LC_CTYPE,LC_MESSAGES}=en_US.ISO-8859-1 make -j1
      > >
      > > Test results:
      > > ALL DONE
      > >
      > > grep '[=.]' test91.messages
      > > LANG=en_US.ISO-8859-1
      > > LC_MESSAGES=en_US.ISO-8859-1
      > > LC_ALL=
      > > test91.in
      > > fileencoding=utf-8
      > > termencoding=
      > > encoding=latin1
      > >
      > > grep '[=.]' test92.messages
      > > LANG=en_US.ISO-8859-1
      > > LC_MESSAGES=en_US.ISO-8859-1
      > > LC_ALL=
      > > test92.in
      > > fileencoding=latin1
      > > termencoding=
      > > encoding=latin1
      > >
      > >
      > > rm -f test{91,92}.{out,failed,messages}
      > > env {LANG,LC_CTYPE,LC_MESSAGES}=en_US.utf8 make -j1
      > >
      > > Test results:
      > > test91 FAILED
      > > test92 FAILED
      >
      > I see the error. The problem is, curwin->w_cursor.col is the byteindex
      > in the buffer and not the screen-index (which is by what 'l' moves)
      >
      > I think, the attached patch fixes it.

      I think using mb_string2cells() is wrong, because it counts double-wide
      characters as two, while "l" counts them as one.

      How about using w_cursor.vcol but move with "|" instead of "l"?
      Then no conversions are required.


      --
      "I've been teaching myself to play the piano for about 5 years and now write
      most of my songs on it, mainly because I can never find any paper."
      Jeff Lynne, ELO's greatest hits

      /// 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.
    • Show all 16 messages in this topic