#532 cursor hangup with continuous wrap

[Anonymous]

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

[Thorsten Haude]

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]

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]

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]

Added consts, changed a few parameter types

[Thorsten Haude]

const and types are in CVS now

[Joerg Fischer]

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]

http://www.nedit.org/pipermail/develop/2007-October/013510.html

[Thorsten Haude]

Logged In: YES
user_id=119143
Originator: NO

File Added: wrongColumn.diff.txt

[Thorsten Haude]

http://www.nedit.org/pipermail/develop/2007-October/013520.html

[Thorsten Haude]

Logged In: YES
user_id=119143
Originator: NO

File Added: hang-up.diff.txt

[Thorsten Haude]

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]

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]

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.