Horizontal scroll bug ?

[440bx]

Hello,

When "Selection"->"Persistent block" is checked and "Overwrite block" is NOT checked and a line length exceeds what is visible in the editor window, moving the caret using the arrow key causes horizontal scrolling that is not needed.

Refer to the attachment.

1. Have a line that is longer than what fits in the editor window.
2. Select text that is not fully visible in the window (blue background in the attachment.)
3. using the Home key (or the mouse) put the caret at the beginning of the line (column 1)
4. using the right arrow key move the caret to the right.

Step 4 doesn't simply cause the caret to move to the right, it causes the entire window to scroll left one character.  Normally window scrolling occurs when the caret is at the end of the visible part of the line, shouldn't this be the case even when there is selected text that is not fully visible ?

ETA:

Lazarus 4.0rc3

[Martin_fr]

Its probably the same as this: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/11482

From memory...

When the caret moves the editor checks if the scroll-pos is correct / ideal.
E.g. if you move the caret off screen, then scrolling follows

But part of that is also to have the selection horizontally in the visible field.
E.g. if you have a very long line, you start at pos 20 and select towards the right. The pos 20 scrolls out to the left. But if you then "deselect leftwards" (shift cursor left) then the pos 20 is scrolled back into view. Even so the caret is on the right side of the editor, and the caret does not force that scroll.

But in other scenarios that is less desirable...

Based on non-persistent selections I hadn't yet decided if to do any change at all... It's rare, and in some cases desired.

With a persistent block that is more of an issue.


You may want to add your case to the existing issue.

Still need to come up with a good solution....

For the persistent issue, it might be a start, to check "selection bounds" only, if the caret is at an selection bound (if it is, check both bounds).
That would make it more similar to what happens for non persistent selections.

[440bx]

It's not the same issue because the text is already selected.  This is not about selecting text (block or otherwise), it's about scrolling taking place at a time when it should not happen.

What happens is that with the caret in column 1, moving the caret to column 2 causes the window to scroll horizontally.  Since column two (all the way to 80 in the snapshot I posted) is visible there is no reason for scrolling to occur. 

if there is nothing selected and the caret is in column 1, moving the caret to column 2 does not make the entire window scroll horizontally and, it seems logical that this behavior should not be any different regardless of any text being selected anywhere.

As it is now, moving the caret to column 2 causes the text to scroll horizontally causing column 1 to no longer be visible and that keeps happening as the caret moves further to the right.  I don't see why moving the caret to the right should cause text on the left to no longer be visible.  Normally, horizontal scrolling happens only when the caret is close to the edge of the visible area and moving it further to the right _requires_ scrolling.

[Martin_fr]

Underlaying it probably is the same code causing it.
The editor does not care if you are selecting. It only checks if there is a selection.

What happens is that with the caret in column 1, moving the caret to column 2 causes the window to scroll horizontally.  Since column two (all the way to 80 in the snapshot I posted) is visible there is no reason for scrolling to occur. 

I will have to test later / too much stuff going on now, than to start playing with my config.

But, the left most part of the selection is not fully visible. The editor wants to "fix" that. When the caret is no longer at column 1, then nothing keeps forcing column 1 to be visible. So the editor bring more of the selected text into the visible area. (and yes, it only looks at horizontal selection bounds, not vertical)

I already acknowledged that this isn't always desired. See my examples.

[440bx]

I understand what you're saying... but, there are many reasons to move the caret, like inserting a word or a character, deleting a character or some other operation.  wanting to see more of the selection _could_ be a reason but, when editing text, it is rarely a reason (text doesn't need to be selected to be edited.)

Honestly, I think it makes no sense at all to scroll the window to show 1 more character on the right.  I think that kind of operation should require a modifier like ctrl, alt, shift or a combination of those because when pressing the arrows, what is expected is the caret to move not the window to be scrolled for no reason.

just my $0.01

It's no big deal but... it's weird.

[Martin_fr]

I understand what you're saying... but, there are many reasons to move the caret, like inserting a word or a character, deleting a character or some other operation.  wanting to see more of the selection _could_ be a reason but, when editing text, it is rarely a reason (text doesn't need to be selected to be edited.)

Did you read

For the persistent issue, it might be a start, to check "selection bounds" only, if the caret is at an selection bound (if it is, check both bounds).

?

[440bx]

Did you read

For the persistent issue, it might be a start, to check "selection bounds" only, if the caret is at an selection bound (if it is, check both bounds).

?

Yes, I read that but, I didn't really understand it then and I still don't understand it now.

I don't see a "selection bounds" anywhere.   I've looked in every page of "IDE Options -> Editor" and don't see it.  Where is that thing ?

[Martin_fr]

Well, if the caret is at the selection (touches either the right or left of it), then you may have just changed the selection.  That is what usually is the case with non-persistent selection.
In that case there is a chance (not always but sometimes) that scrolling would be sensible.

But with a persistent selection, you may be editing (or just caret moving) some where else in the text. So nothing about the selection would have changed. Then there should be no scrolling base on whatever selection there is.

There may be other rules....

I have to review the original issue. But I think if the caret x changed because of the caret went to an other line, then scrolling may also not always be wanted...

Or maybe for a multiline selection, it also depends on which end of the selection the caret is...

But that needs some more thoughts.

[440bx]

But with a persistent selection, you may be editing (or just caret moving) some where else in the text. So nothing about the selection would have changed. Then there should be no scrolling base on whatever selection there is.

That's exactly what I think too and, that's not what's happening.

ETA:

I'm going to change the setting back to not persistent.  IOW, this problem won't affect me anymore.

[Martin_fr]

I "fixed" the worst bit of the scrolling.

When you change the selection then the editor will still scroll. And in some cases that may be useful (at least for some people) but in others its still undesirable. But that needs to be addressed another time.

Anyway, if the selection just is there, purely "being in existence", but not being changed, then it should not affect scrolling in anyway at all.


As for all else, I don't use persistent selection, so I don't know how well it behaves....

E.g. introducing a "clear selection", at first obvious. But how exactly does a cleared persistent selection behave?

Currently a cleared selection (persistent or not) is an empty selection. And if not persistent that empty selection follows the caret. So its start pos is already set.

If persistent, then the empty selection remains where it was last cleared.
You can notice that if you set the begin or end, it will select to the point where it last had a selection.


Sounds strange?

Well don't just say to make it follow as well. Because that actually brings a problem.

Lets say the empty selection follows the caret, so when you set either end, you don't get a "semi random" selection to the point where it was previously cleared.

Now you do set the begin (or end). Ok. But... Now you still have an empty selection at the caret. So now when you move the caret in order to be able to set the end somewhere that empty selection still follow you around. And your just set begin/end is not so persistent... Ouch.

Yes that can be solved too. But then you have a lot of states.

- selection empty, because cleared
- selection empty, because empty (you set start or begin / or both at the same spot)
- selection not empty

Are those 3 states wanted? Because the first 2 are not visually different. And both behave as no selection set.

[440bx]

again, just for the record, I reverted to the non-persistent mode because the persistent one was a bit too problematic for my taste.

That said, since you've worked on it, I'll try again after I install a new (more current) Lazarus version(which isn't something I like to do because of all the settings I have to remember changing to have it work like the old installation.)

I'll probably wait for v4.1

[Martin_fr]

You can just patch it.

But as I said, persistent block may need more work. But that needs feedback.