Possible Solution: Cursor movement in virtual edit mode is inconsistent.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible Solution: Cursor movement in virtual edit mode is inconsistent.

Joseph Miele
I reported this particular issue back on January 21, 2004. Bram was able
to confirm the bug, but that was the last I heard of regarding this bug.

I hadn't patched vim in a while, so I thought I would get my copy up to
date and check to see if the bug was still there. It is. So, here is a
revised versoin of that bug report:


Problem: Cursor movement in virtual edit mode is inconsistent.

Version of Vim: 6.3.80 for Windows or Linux.

Details:

1. Run vim from the command prompt as follows: gvim -u NONE -U NONE -N

2. Next, set virtualedit=all.

3. Create a three line document as follows:

*
***
*

3. While still in insert mode, move the cursor to the end of the second
line and
insert a fourth asterisk.
4. Move the cursor up. The cursor is positioned to the right of the single
asterisk on the first line. Please note that behavior.
5. While still in insert mode, move the cursor back to the end of the second
line of the document.
6. Don't insert a character, just move the cursor up again. This time, the
cursor moves straight up, not directly to the right of the asterisk on
line 1.

Since vim is in virtual edit mode, the cursor should always move
straight up.


I did some digging and I saw something interesting in edit.c:

start_arrow(end_insert_pos)
    pos_T    *end_insert_pos;
{
    if (!arrow_used)        /* something has been inserted */
    {
    AppendToRedobuff(ESC_STR);
    stop_insert(end_insert_pos, FALSE);
    arrow_used = TRUE;    /* this means we stopped the current insert */
    }
}    

The stop_insert routine checks arrow_used, but stop_insert is called by
start_arrow before arrow_used is set to TRUE. I tried setting arrow_used
to TRUE before the call to stop_insert, so the code reads like this:

start_arrow(end_insert_pos)
    pos_T    *end_insert_pos;
{
    if (!arrow_used)        /* something has been inserted */
    {
    AppendToRedobuff(ESC_STR);
    arrow_used = TRUE;    /* this means we stopped the current insert */
    stop_insert(end_insert_pos, FALSE);
    }
}    

I recompiled and then I tried the steps above again. This time the
cursor moved straight up, just like it did in version 6.2.0. The bug is
gone!

So, here is my question. Is this change going to break anything else? If
it's OK, can we get an official patch? :-)

BTW, if anyone is interested, this bug first appeared in version
6.2.336. Patch 6.2.336 was a bug fix for 6.2.227.

Thank you for your time!

- Joe Miele


Reply | Threaded
Open this post in threaded view
|

Re: Possible Solution: Cursor movement in virtual edit mode is inconsistent.

Walter Briscoe
In message <[hidden email]> of Sun, 10 Jul 2005
01:07:21 in , Joseph Miele <[hidden email]> writes

>I reported this particular issue back on January 21, 2004. Bram was
>able to confirm the bug, but that was the last I heard of regarding
>this bug.
>
>I hadn't patched vim in a while, so I thought I would get my copy up to
>date and check to see if the bug was still there. It is. So, here is a
>revised versoin of that bug report:
>
>
>Problem: Cursor movement in virtual edit mode is inconsistent.
>
>Version of Vim: 6.3.80 for Windows or Linux.
>
>Details:
>
>1. Run vim from the command prompt as follows: gvim -u NONE -U NONE -N
>
>2. Next, set virtualedit=all.
>
>3. Create a three line document as follows:
>
>*
>***
>*
>
>3. While still in insert mode, move the cursor to the end of the second
>line and
>insert a fourth asterisk.
>4. Move the cursor up. The cursor is positioned to the right of the single
>asterisk on the first line. Please note that behavior.
>5. While still in insert mode, move the cursor back to the end of the second
>line of the document.
>6. Don't insert a character, just move the cursor up again. This time, the
>cursor moves straight up, not directly to the right of the asterisk on
>line 1.
>
>Since vim is in virtual edit mode, the cursor should always move
>straight up.
>
>
>I did some digging and I saw something interesting in edit.c:
>
>(end_insert_pos)
>   pos_T    *end_insert_pos;
>{
>   if (!arrow_used)        /* something has been inserted */
>   {
>   AppendToRedobuff(ESC_STR);
>   stop_insert(end_insert_pos, FALSE);
>   arrow_used = TRUE;    /* this means we stopped the current insert */
>   }
>}
>The stop_insert routine checks arrow_used, but stop_insert is called by
>start_arrow before arrow_used is set to TRUE. I tried setting
>arrow_used to TRUE before the call to stop_insert, so the code reads
>like this:
>
>start_arrow(end_insert_pos)
>   pos_T    *end_insert_pos;
>{
>   if (!arrow_used)        /* something has been inserted */
>   {
>   AppendToRedobuff(ESC_STR);
>   arrow_used = TRUE;    /* this means we stopped the current insert */
>   stop_insert(end_insert_pos, FALSE);
>   }
>}
>I recompiled and then I tried the steps above again. This time the
>cursor moved straight up, just like it did in version 6.2.0. The bug is
>gone!
>
>So, here is my question. Is this change going to break anything else?
>If it's OK, can we get an official patch? :-)
>
>BTW, if anyone is interested, this bug first appeared in version
>6.2.336. Patch 6.2.336 was a bug fix for 6.2.227.

I had a quick look at applying your patch in a recent vim7.
I saw the original behavior; I applied the patch; I found your change
does nothing. I will look further and try to derive my own patch. I
usually find such problems easy: I run two debugger sessions in parallel
and look for divergence.

BTW, your method of patch presentation makes unnecessary demands on the
intelligence of the reader. diff -c output is OK; diff -u is better.
I have a port of gnu diff, which supports both, on my W2K system.

D:\wfb\vim\bld\vim70aa\vim7 ) diff -c src/edit.c.0 src/edit.c
*** src/edit.c.0        Sun Jul  3 10:45:38 2005
--- src/edit.c  Sun Jul 10 08:11:22 2005
***************
*** 4779,4786 ****
      if (!arrow_used)      /* something has been inserted */
      {
        AppendToRedobuff(ESC_STR);
-       stop_insert(end_insert_pos, FALSE);
        arrow_used = TRUE;      /* this means we stopped the current insert */
      }
  #ifdef FEAT_SYN_HL
      check_spell_redraw();
--- 4779,4786 ----
      if (!arrow_used)      /* something has been inserted */
      {
        AppendToRedobuff(ESC_STR);
        arrow_used = TRUE;      /* this means we stopped the current insert */
+       stop_insert(end_insert_pos, FALSE);
      }
  #ifdef FEAT_SYN_HL
      check_spell_redraw();

D:\wfb\vim\bld\vim70aa\vim7 ) diff -u src/edit.c.0 src/edit.c
--- src/edit.c.0        Sun Jul  3 10:45:38 2005
+++ src/edit.c  Sun Jul 10 08:11:22 2005
@@ -4779,8 +4779,8 @@
     if (!arrow_used)       /* something has been inserted */
     {
        AppendToRedobuff(ESC_STR);
-       stop_insert(end_insert_pos, FALSE);
        arrow_used = TRUE;      /* this means we stopped the current insert */
+       stop_insert(end_insert_pos, FALSE);
     }
 #ifdef FEAT_SYN_HL
     check_spell_redraw();

D:\wfb\vim\bld\vim70aa\vim7 )

Don't be discouraged. ;)
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: Possible Solution: Cursor movement in virtual edit mode is inconsistent.

Joseph Miele
Walter -

I downloaded and compiled vim-7.0106.zip and gave it a whirl. I'm not
sure what problem you saw, but the problem I was describing is no longer
there. The cursor moves as it did in 6.2.0.

Of course, since vim 7 is still an alpha, so a double check on my change
for version 6.3.x would be welcome. :-)

(Ugh, 5:27am EST.... I gotta get some sleep....)

- Joe



Walter Briscoe wrote:

>In message <[hidden email]> of Sun, 10 Jul 2005
>01:07:21 in , Joseph Miele <[hidden email]> writes
>  
>
>>I reported this particular issue back on January 21, 2004. Bram was
>>able to confirm the bug, but that was the last I heard of regarding
>>this bug.
>>
>>I hadn't patched vim in a while, so I thought I would get my copy up to
>>date and check to see if the bug was still there. It is. So, here is a
>>revised versoin of that bug report:
>>
>>
>>Problem: Cursor movement in virtual edit mode is inconsistent.
>>
>>Version of Vim: 6.3.80 for Windows or Linux.
>>
>>Details:
>>
>>1. Run vim from the command prompt as follows: gvim -u NONE -U NONE -N
>>
>>2. Next, set virtualedit=all.
>>
>>3. Create a three line document as follows:
>>
>>*
>>***
>>*
>>
>>3. While still in insert mode, move the cursor to the end of the second
>>line and
>>insert a fourth asterisk.
>>4. Move the cursor up. The cursor is positioned to the right of the single
>>asterisk on the first line. Please note that behavior.
>>5. While still in insert mode, move the cursor back to the end of the second
>>line of the document.
>>6. Don't insert a character, just move the cursor up again. This time, the
>>cursor moves straight up, not directly to the right of the asterisk on
>>line 1.
>>
>>Since vim is in virtual edit mode, the cursor should always move
>>straight up.
>>
>>
>>I did some digging and I saw something interesting in edit.c:
>>
>>(end_insert_pos)
>>  pos_T    *end_insert_pos;
>>{
>>  if (!arrow_used)        /* something has been inserted */
>>  {
>>  AppendToRedobuff(ESC_STR);
>>  stop_insert(end_insert_pos, FALSE);
>>  arrow_used = TRUE;    /* this means we stopped the current insert */
>>  }
>>}
>>The stop_insert routine checks arrow_used, but stop_insert is called by
>>start_arrow before arrow_used is set to TRUE. I tried setting
>>arrow_used to TRUE before the call to stop_insert, so the code reads
>>like this:
>>
>>start_arrow(end_insert_pos)
>>  pos_T    *end_insert_pos;
>>{
>>  if (!arrow_used)        /* something has been inserted */
>>  {
>>  AppendToRedobuff(ESC_STR);
>>  arrow_used = TRUE;    /* this means we stopped the current insert */
>>  stop_insert(end_insert_pos, FALSE);
>>  }
>>}
>>I recompiled and then I tried the steps above again. This time the
>>cursor moved straight up, just like it did in version 6.2.0. The bug is
>>gone!
>>
>>So, here is my question. Is this change going to break anything else?
>>If it's OK, can we get an official patch? :-)
>>
>>BTW, if anyone is interested, this bug first appeared in version
>>6.2.336. Patch 6.2.336 was a bug fix for 6.2.227.
>>    
>>
>
>I had a quick look at applying your patch in a recent vim7.
>I saw the original behavior; I applied the patch; I found your change
>does nothing. I will look further and try to derive my own patch. I
>usually find such problems easy: I run two debugger sessions in parallel
>and look for divergence.
>
>BTW, your method of patch presentation makes unnecessary demands on the
>intelligence of the reader. diff -c output is OK; diff -u is better.
>I have a port of gnu diff, which supports both, on my W2K system.
>
>D:\wfb\vim\bld\vim70aa\vim7 ) diff -c src/edit.c.0 src/edit.c
>*** src/edit.c.0        Sun Jul  3 10:45:38 2005
>--- src/edit.c  Sun Jul 10 08:11:22 2005
>***************
>*** 4779,4786 ****
>      if (!arrow_used)      /* something has been inserted */
>      {
>        AppendToRedobuff(ESC_STR);
>-       stop_insert(end_insert_pos, FALSE);
>        arrow_used = TRUE;      /* this means we stopped the current insert */
>      }
>  #ifdef FEAT_SYN_HL
>      check_spell_redraw();
>--- 4779,4786 ----
>      if (!arrow_used)      /* something has been inserted */
>      {
>        AppendToRedobuff(ESC_STR);
>        arrow_used = TRUE;      /* this means we stopped the current insert */
>+       stop_insert(end_insert_pos, FALSE);
>      }
>  #ifdef FEAT_SYN_HL
>      check_spell_redraw();
>
>D:\wfb\vim\bld\vim70aa\vim7 ) diff -u src/edit.c.0 src/edit.c
>--- src/edit.c.0        Sun Jul  3 10:45:38 2005
>+++ src/edit.c  Sun Jul 10 08:11:22 2005
>@@ -4779,8 +4779,8 @@
>     if (!arrow_used)       /* something has been inserted */
>     {
>        AppendToRedobuff(ESC_STR);
>-       stop_insert(end_insert_pos, FALSE);
>        arrow_used = TRUE;      /* this means we stopped the current insert */
>+       stop_insert(end_insert_pos, FALSE);
>     }
> #ifdef FEAT_SYN_HL
>     check_spell_redraw();
>
>D:\wfb\vim\bld\vim70aa\vim7 )
>
>Don't be discouraged. ;)
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: Possible Solution: Cursor movement in virtual edit mode is inconsistent.

Walter Briscoe
In reply to this post by Walter Briscoe
In message <[hidden email]> of Sun, 10 Jul
2005 08:22:30 in , Walter Briscoe <[hidden email]>
writes

>In message <[hidden email]> of Sun, 10 Jul 2005
>01:07:21 in , Joseph Miele <[hidden email]> writes
>>I reported this particular issue back on January 21, 2004. Bram was
>>able to confirm the bug, but that was the last I heard of regarding
>>this bug.
>>
>>I hadn't patched vim in a while, so I thought I would get my copy up to
>>date and check to see if the bug was still there. It is. So, here is a
>>revised versoin of that bug report:
>>
>>
>>Problem: Cursor movement in virtual edit mode is inconsistent.
>>
>>Version of Vim: 6.3.80 for Windows or Linux.
>>
>>Details:
>>
>>1. Run vim from the command prompt as follows: gvim -u NONE -U NONE -N
>>
>>2. Next, set virtualedit=all.
>>
>>3. Create a three line document as follows:
>>
>>*
>>***
>>*
>>
>>3. While still in insert mode, move the cursor to the end of the second
>>line and
>>insert a fourth asterisk.
>>4. Move the cursor up. The cursor is positioned to the right of the single
>>asterisk on the first line. Please note that behavior.
>>5. While still in insert mode, move the cursor back to the end of the second
>>line of the document.
>>6. Don't insert a character, just move the cursor up again. This time, the
>>cursor moves straight up, not directly to the right of the asterisk on
>>line 1.
>>
>>Since vim is in virtual edit mode, the cursor should always move
>>straight up.

In vim7, I find it is complicated:
If I move to the end of the second line with several arrow key
movements, a vertical movement is truly vertical.
If I move to the end of the second line with a $ command, the vertical
movement is to the end of the adjacent line.
Is the difference intentional?
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: Possible Solution: Cursor movement in virtual edit mode is inconsistent.

Joseph Miele
Hmmmm..... I see where you are coming from.

Your replies have me thinking about this problem from a new angle. I'm
not gving up on this. Stay tuned! :-)

- Joe

Walter Briscoe wrote:

>In message <[hidden email]> of Sun, 10 Jul
>2005 08:22:30 in , Walter Briscoe <[hidden email]>
>writes
>  
>
>>In message <[hidden email]> of Sun, 10 Jul 2005
>>01:07:21 in , Joseph Miele <[hidden email]> writes
>>    
>>
>>>I reported this particular issue back on January 21, 2004. Bram was
>>>able to confirm the bug, but that was the last I heard of regarding
>>>this bug.
>>>
>>>I hadn't patched vim in a while, so I thought I would get my copy up to
>>>date and check to see if the bug was still there. It is. So, here is a
>>>revised versoin of that bug report:
>>>
>>>
>>>Problem: Cursor movement in virtual edit mode is inconsistent.
>>>
>>>Version of Vim: 6.3.80 for Windows or Linux.
>>>
>>>Details:
>>>
>>>1. Run vim from the command prompt as follows: gvim -u NONE -U NONE -N
>>>
>>>2. Next, set virtualedit=all.
>>>
>>>3. Create a three line document as follows:
>>>
>>>*
>>>***
>>>*
>>>
>>>3. While still in insert mode, move the cursor to the end of the second
>>>line and
>>>insert a fourth asterisk.
>>>4. Move the cursor up. The cursor is positioned to the right of the single
>>>asterisk on the first line. Please note that behavior.
>>>5. While still in insert mode, move the cursor back to the end of the second
>>>line of the document.
>>>6. Don't insert a character, just move the cursor up again. This time, the
>>>cursor moves straight up, not directly to the right of the asterisk on
>>>line 1.
>>>
>>>Since vim is in virtual edit mode, the cursor should always move
>>>straight up.
>>>      
>>>
>
>In vim7, I find it is complicated:
>If I move to the end of the second line with several arrow key
>movements, a vertical movement is truly vertical.
>If I move to the end of the second line with a $ command, the vertical
>movement is to the end of the adjacent line.
>Is the difference intentional?
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: Possible Solution: Cursor movement in virtual edit mode is inconsistent.

Bram Moolenaar
In reply to this post by Joseph Miele

Joseph Miele wrote:

> I reported this particular issue back on January 21, 2004. Bram was able
> to confirm the bug, but that was the last I heard of regarding this bug.
>
> I hadn't patched vim in a while, so I thought I would get my copy up to
> date and check to see if the bug was still there. It is. So, here is a
> revised versoin of that bug report:
>
>
> Problem: Cursor movement in virtual edit mode is inconsistent.
>
> Version of Vim: 6.3.80 for Windows or Linux.
>
> Details:
>
> 1. Run vim from the command prompt as follows: gvim -u NONE -U NONE -N
>
> 2. Next, set virtualedit=all.
>
> 3. Create a three line document as follows:
>
> *
> ***
> *
>
> 3. While still in insert mode, move the cursor to the end of the second
> line and
> insert a fourth asterisk.
> 4. Move the cursor up. The cursor is positioned to the right of the single
> asterisk on the first line. Please note that behavior.
> 5. While still in insert mode, move the cursor back to the end of the second
> line of the document.
> 6. Don't insert a character, just move the cursor up again. This time, the
> cursor moves straight up, not directly to the right of the asterisk on
> line 1.
>
> Since vim is in virtual edit mode, the cursor should always move
> straight up.

This has been fixed in Vim 7.  The entry in version7.txt:

        When 'virtualedit' is set, moving the cursor up after appending
        a character may move it to a different column.  Was caused by
        auto-formatting moving the cursor and not putting it back where
        it was.

It's a bit complicated thus I didn't add it to Vim 6.3.

The change you mentioned has side effects, other things will break.

--
TALL KNIGHT OF NI: Ni!
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///