Feature request/suggestion

[440bx]

Hello,

When using the scrollwheel to scroll source code, if _after_ scrolling, a caret arrow is pressed, the editor jumps back to where the caret is thus undoing all the scrolling that was done with the mousewheel.

The request/suggestion is: bring the caret into the visible text window instead of jumping back to where the caret is. 

A possible variation of this request is to keep the caret's window-relative position constant, i.e, if the caret is in the middle of the visible window then scrolling using the mousewheel keeps the caret in the same place while the text moves to reflect the mouse scrolling (I believe this is the ideal choice as it leaves nothing out of view at anytime.)  Effectively, mousewheel scrolling changes the line where the caret is but does not change its position in the source code window.

Comments welcome.

[dsiders]

Hello,

When using the scrollwheel to scroll source code, if _after_ scrolling, a caret arrow is pressed, the editor jumps back to where the caret is thus undoing all the scrolling that was done with the mousewheel.

The request/suggestion is: bring the caret into the visible text window instead of jumping back to where the caret is. 

A possible variation of this request is to keep the caret's window-relative position constant, i.e, if the caret is in the middle of the visible window then scrolling using the mousewheel keeps the caret in the same place while the text moves to reflect the mouse scrolling (I believe this is the ideal choice as it leaves nothing out of view at anytime.)  Effectively, mousewheel scrolling changes the line where the caret is but does not change its position in the source code window.

Comments welcome.

Not sure if this is what you're asking for:

There is an option setting in Tools > Options > Editor > General > Caret (Text Cursor) > Always keep Caret in visible area of editor. It forces the Caret to be on-screen... but not in the vertical center of the screen.

[440bx]

Thank you @dsiders, that's close enough.

I am using that now.

[munair]

Perhaps "SOLVED" in the title would be appropriate.

[440bx]

Perhaps "SOLVED" in the title would be appropriate.

What @dsiders offered is _really_ close and it certainly prevents the jumping which is what I found annoying.  Most definitely a large step in the right direction.

But the "complete" feature is to have the caret stay _still_ while text is scrolled up/down.  If there is a way to get it to behave that way, I'll mark it "SOLVED".

[Martin_fr]

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40949  ?

The request/suggestion is: bring the caret into the visible text window instead of jumping back to where the caret is. 

A possible variation of this request is to keep the caret's window-relative position constant, i.e, if the caret is in the middle of the visible window then scrolling using the mousewheel keeps the caret in the same place while the text moves to reflect the mouse scrolling (I believe this is the ideal choice as it leaves nothing out of view at anytime.)  Effectively, mousewheel scrolling changes the line where the caret is but does not change its position in the source code window.

That leaves a lot of interpretations, with side-effects

"bring the caret into the visible"
 => Even if it was outside?
 => And where in the visible exactly (top/bottom border, keeping the caret-X if possible?)

"window-relative position", that is better defined, but
 => if the caret is outside the visible (e.g. one line above the top-visible), should it be kept at relative Y= -1 ?

Then there is the option you did not mention:
Keep the caret under the mouse cursor (assuming the mouse is over the text area / otherwise as close as possible at the border, but do not trigger scrolling, i.e. horiz scrolling)
=> Of course:
  if the editor is scrolled to the right, and you vertically wheel scroll over the left gutter, then the caret wants to go to the scrolled-out X that is under the gutter.
  Should it: Stick to the visible left most? OR Go to the desired X, but do not scroll (therefore leave the visible area)?



There is a set of advanced option that do something almost like it.
Well, its 2 options, that were not meant to go together.

In advanced mouse, find the wheel scroll (normal / without ctrl-keys).
You need to find both: up / down
Edit them, and select "Move Caret"

The caret will almost stay under the mouse.
It gets the order wrong, it move to the mouse pos, but before the scroll. So it ends up one scroll away from the mouse. (Can be several lines).

[Martin_fr]

Try

Code: Diff  [Select][+][-]

1. diff --git a/components/synedit/synedit.pp b/components/synedit/synedit.pp
2. index f5507e0377..6488ec61cc 100644
3. --- a/components/synedit/synedit.pp
4. +++ b/components/synedit/synedit.pp
5. @@ -3663,6 +3663,7 @@ function TCustomSynEdit.DoHandleMouseAction(AnActionList: TSynEditMouseActions;
6.            if ACommand = emcWheelHorizScrollUp then i := -i;
7.            if i <> 0 then begin
8.              LeftChar := LeftChar + i;
9. +            AnInfo.NewCaret.CharPos := AnInfo.NewCaret.CharPos + i;
10.              if fStateFlags * [sfMouseSelecting, sfWaitForMouseSelecting] <> [] then begin
11.                FStateFlags := FStateFlags - [sfWaitForMouseSelecting] + [sfMouseSelecting, sfMouseDoneSelecting];
12.                ResetMouseCapture := False;
13. @@ -3679,6 +3680,7 @@ function TCustomSynEdit.DoHandleMouseAction(AnActionList: TSynEditMouseActions;
14.            if ACommand = emcWheelVertScrollUp then i := -i;
15.            if i <> 0 then begin
16.              TopView := TopView + i;
17. +            AnInfo.NewCaret.LinePos := AnInfo.NewCaret.LinePos + i;
18.              if fStateFlags * [sfMouseSelecting, sfWaitForMouseSelecting] <> [] then begin
19.                FStateFlags := FStateFlags - [sfWaitForMouseSelecting] + [sfMouseSelecting, sfMouseDoneSelecting];
20.                ResetMouseCapture := False;
21.  

with the advanced option.

Though it wont work, when using word-wrap. And it wont work if there is folded text.

[440bx]

That leaves a lot of interpretations, with side-effects

"bring the caret into the visible"
 => Even if it was outside?
 => And where in the visible exactly (top/bottom border, keeping the caret-X if possible?)

if the feature is implemented then it should not be possible for the caret to ever be outside the visible window.  The "where" is simple: where-ever the caret was before scrolling started.  IOW, if the caret was about 1/4 down from the top of the visible window then it should stay in that spot no matter what scrolling takes place.

"window-relative position", that is better defined, but
 => if the caret is outside the visible (e.g. one line above the top-visible), should it be kept at relative Y= -1 ?

It should never be possible for the caret not to be visible.  If there is a way to make the caret not visible then that's a bug.

Then there is the option you did not mention:
Keep the caret under the mouse cursor (assuming the mouse is over the text area / otherwise as close as possible at the border, but do not trigger scrolling, i.e. horiz scrolling)
=> Of course:
  if the editor is scrolled to the right, and you vertically wheel scroll over the left gutter, then the caret wants to go to the scrolled-out X that is under the gutter.
  Should it: Stick to the visible left most? OR Go to the desired X, but do not scroll (therefore leave the visible area)?

I'm not sure I'm visualizing the situation correctly but, the position of the caret should always be totally independent of the mouse cursor's position until a mouse button is clicked which normally has the effect of placing the caret where the button click occurred.   An important thing is, the horizontal position of the caret should _not_ change regardless of scrolling _vertical_ or _horizontal_.  IOW, under any circumstances, scrolling does not and cannot affect the position of the caret.  IOW, again, say the caret is position (x, y) in pixels relative to the top left corner of the editor window (iow, pixel client coordinate), no matter what scrolling takes place, horizontal, vertical, both and, in whatever amount, the pixel (x,y) coordinate of the caret must remain constant.

There is a set of advanced option that do something almost like it.
Well, its 2 options, that were not meant to go together.

In advanced mouse, find the wheel scroll (normal / without ctrl-keys).
You need to find both: up / down
Edit them, and select "Move Caret"

The caret will almost stay under the mouse.
It gets the order wrong, it move to the mouse pos, but before the scroll. So it ends up one scroll away from the mouse. (Can be several lines).

I tried that, it comes really close and I'm keeping that setting.  Thank you.

For some reason it doesn't quite stay in the same spot but, it stays fairly close.  There is a little bit of vertical and horizontal movement but, the caret remains in the visible area which is the most important part.


Thank you for the patch... now I owe you applying two (2) patches.   Got to somehow get them applied.

Thanks again.

[Martin_fr]

Oh btw out of curiosity.

Is there any example editor out there that can be used to see the desired behaviour?

[440bx]

Is there any example editor out there that can be used to see the desired behaviour?

Yes, there is but, it is now a defunct editor.  Of course, I'm talking about Multi-Edit.

[dsiders]

Is there any example editor out there that can be used to see the desired behaviour?

Yes, there is but, it is now a defunct editor.  Of course, I'm talking about Multi-Edit.

I was a big fan of Brief back in the day... until Borland bought and killed it. Who tanked Multi-Edit?

[440bx]

Who tanked Multi-Edit?

It died a slow death because it's just an editor, by that I mean it's not like the typical IDE that internally indexes methods which allows for features like Codetools, intellisense, etc.   It could be extended to do that,  its macro language is plenty powerful enough to do it but, that's very programming language "flavor-specific" and the developers avoided getting very deep into language specific features.

Multi-Edit is just an editing engine, a concept that has been lost with the passage of time and modern editors that, if they were a woman, would wear stiletto heels, spend their day painting their toe-nails while watching soap operas with their equally talented friends.  Today's editors do all kinds of acrobatics but, they are really, truly appallingly miserable editing engines. That said, I have to say that the Lazarus editor, unlike every other editor I know of, is at least usable.  The only other editor, I have used that was as good as and in some areas even better than Multi-Edit was a Wang _dedicated_ word processing machine.  That was the atomic-missile-capable aircraft carrier of editors.  Using that thing was a pleasure.

One of the most disgraceful editors out there is the one in Visual Studio (not code), every time I use that thing, I relate to how Galileo must have felt when the grand inquisitor showed him the torture devices that would be used on him unless he stopped saying that earth wasn't the center of the universe.  how anyone can use that thing is beyond my comprehension.  What a torture!!!  and, to top that pain, you gotta code in C or Pain++.

Fortunately, I'm old enough that this stuff isn't going to bother me much longer... proves there is a silver lining to everything... no visual studio editor and no more taxes!!. There is some good stuff at the end of the line ...  <chuckle>