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 -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
