#532 cursor hangup with continuous wrap

release
open-accepted
Program (402)
5
2008-01-04
2006-07-19
Anonymous
No

I typed in following 3 lines:
-------- cut here --------
1>******************
2>******************ab
3>
-------- cut here --------
then:
1. resize window, so the last two characters 'ab'
of line 2 were wraped to the next line by
continuous wrap
2. go to line 1, type key <End>, for end of line
3. scroll to end of file with <cursor down>
4. scroll up with <cursor up>

i got a cursor hangup on the wraped part of line 2

for reproducing the bug i found it is important that
- line 1 needs exactly the size just before line wrap.
- there may by other lines between line 1 and 2

cheers
Jörg

Discussion

  • Thorsten Haude
    Thorsten Haude
    2006-08-11

    Logged In: YES
    user_id=119143

    Confirmed with:
    Enhanced NEdit 5.5
    Nov 24, 2005

    Built on: Linux, 486, GNU C
    Built at: Jan 2 2006, 20:46:10
    With Motif: 2.2.3 [@(#)Motif Version 2.2.3]
    Running Motif: 2.2 [@(#)Motif Version 2.2.3]
    Server: The XFree86 Project, Inc 40399902
    Visual: 16-bit TrueColor (ID 0x22, Default)
    Locale: de_DE

    (Is that you, Jörg? Did you just forgot to login?)

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-11

    • assigned_to: nobody --> yooden
     
  • Thorsten Haude
    Thorsten Haude
    2006-09-03

    • labels: --> Program
    • milestone: --> release
    • status: open --> open-accepted
     
  • Thorsten Haude
    Thorsten Haude
    2006-09-03

    Logged In: YES
    user_id=119143

    Found it. The caret movement you would expect is not
    possible (but attempted, hence the hangup) because the caret
    cannot be placed on the last position of a cont-wrapped
    line. At the moment I don't see a fix that would keep caret
    movement consistent for all cases.

    (Confirmed for 5.1.1.)

     
  • Thorsten Haude
    Thorsten Haude
    2006-09-05

    Logged In: YES
    user_id=119143

    I implemented a solution I saw in Kate and Scite: On
    cont-wrapped lines, the caret is put in the last but one
    position, retaining the preferred column. The current patch
    is buggy on some fringe cases (eg. two-column windows), so I
    will have another look.

     
  • Thorsten Haude
    Thorsten Haude
    2006-09-30

    • priority: 5 --> 9
     
  • Thorsten Haude
    Thorsten Haude
    2006-10-08

    Added consts, changed a few parameter types

     
  • Thorsten Haude
    Thorsten Haude
    2006-12-03

    const and types are in CVS now

     
  • Joerg Fischer
    Joerg Fischer
    2007-10-02

    Logged In: YES
    user_id=918104
    Originator: NO

    I can't follow Kate or Scite. There is no problem in showing the cursor at the start of the next line in case of a non-whitespace wrap. We only have to be consistent and notice that in this case the next and previous lines are different, otherwise Down jumps actually 2 lines down, while Up stays at the same line as reported. I can't attache the simple fix here unfortunately so I submit it to the develop list.

     
  • Thorsten Haude
    Thorsten Haude
    2007-12-28

    Logged In: YES
    user_id=119143
    Originator: NO

    File Added: wrongColumn.diff.txt

     
  • Thorsten Haude
    Thorsten Haude
    2007-12-28

    Logged In: YES
    user_id=119143
    Originator: NO

    File Added: hang-up.diff.txt

     
  • Thorsten Haude
    Thorsten Haude
    2007-12-29

    Logged In: YES
    user_id=119143
    Originator: NO

    I guess it depends on what you consider worse: The jump to the wrong column in affected lines or the fact that <down> from the first column brings you to the last column of the same line. I prefer the former.

     
  • Joerg Fischer
    Joerg Fischer
    2007-12-30

    Logged In: YES
    user_id=918104
    Originator: NO

    If a normal line break occurs at buffer position n0, the next character is a \n. While it isn't visible, it consumes one position, so the next buffer position n0 + 1 is at the start of the next line.

    However, if we have a continuous wrapping, that is, without the \n, there are two diplay positions that equally correspond to the single buffer position n0. So, unavoidably a decision has to be made, where to place the cursor, when the command is, place the cursor at position n0. NEdit decides to place the cursor at the start of the next line.

    Now, please notice, this decision isn't the cause for the bug report. The cause is that NEdit didn't remember on which displayed line the cursor actually is on, which resulted in a two line wide jump in down direction and a zero line jump in up direction (this is the reported part).

    Of course, the loss of the one-to-one relationship of buffer positions with display positions leads unavoidably to a surprise effect of some sort.
    If you like to discuss this, it's somehow off-topic concerning the bug report.

    Anyway, while I heard from the principle of least surprise, in this case I must wonder why the surprise to place the cursor at buffer position n0 - 1 should be smaller, because it is two times wrong -- the wrong buffer position and the wrong display position. It's not the end of the line. To minimize the surprise the other commands like go to end of line should also be transformed into buffer position n0 - 1 then, and hopefully one doesn't end up with more surprise in total. Therefore, I wrote I can't follow Scite or Kate here.

     
  • Thorsten Haude
    Thorsten Haude
    2008-01-04

    • priority: 9 --> 5
     
  • Thorsten Haude
    Thorsten Haude
    2008-01-04

    Logged In: YES
    user_id=119143
    Originator: NO

    There is some discussion to do here, so we should postpone it until after the next release.