[SOLVED] SynEdit: how reset scrollbar's x-pos to 0

[d7_2_laz]

I'd once ported one of my tools (a full text searcher and viewer) to Lazarus and oftenly use it. But from time to time an obviously self-made little flaw does bother me (a text search within the Lazarus IDE's editor does Not show up this behaviour).

Example scenario:
- A search for a text pattern may find some hits in a line, and stepping to those (via F3) may require a horizontal scrolling.
- Now, a next hit in a next line may be found near the line's beginning. But the scrollbar is not fully moved back to the beginning though.
So unneccesarily the text is not very well readable here.
See example screenshot (the 'orange' color indicates the current search position here).

So, what i would like to achieve is: if (eg. triggered via F3) a hit is found at a position that does not require a horizontal scrolling, then to reset the scrollbar's x-position to the line's begin.
Probably it's trivial, but i simply don't see the command ...

Btw, the search itself is done calling a "SynEdit1.SearchReplace(....)".

[Martin_fr]

You can just call

Code: Pascal  [Select][+][-]

1. synedit.LeftChar := 1;

before doing the next search.

Alternatively you can check LeftChar, CharsInWindow and *physical* caret/selection pos after the search and decide what scroll position you would like.

"physical": https://wiki.freepascal.org/SynEdit#Logical,_Physical_or_Viewed_caret_position


There are no settings to control how scrolling behaves after search.  At least not such a you are looking for.

If the editor is scrolled (in your case horizontally) it does not know why this scroll-position is set.
I.e. the editor will not store a history of what caused it to scroll. It just know it is scrolled. And that could be result of a previous search, or the user explicitly moving the scrollbar.
Therefore the editor also does not know if the user would want to keep the scrolling (or as much of it as possible), or if it should be reset.

So the editor just scrolls as much as required to get the new selection (as set for the search result) into view.

[d7_2_laz]

Martin, i was just about to add that i could fully unexpected reproduce the behaviour using the "SearchAndReplace" example from the examples\SynEdit subfolder (screenshot)
as i saw your reply.

And yes .... obviously "LeftChar := 1" does the job to avoid the undesired behaviour.
Thousand thanks !!

I'll dig into a deeper understanding of your answer tomorrow but i'd expect this can be set to 'Solved' then.
What appears to make sense to me is that the component cannot be expected to track if the user explicitely had moved the scrollbar earlier - it wouldn't be a good idea to cancel this user's intentional interaction. Sounds very reasonable ....

[Martin_fr]

IIRC, the relevant code for the moving is in EnsureCursorPosVisible.
There you can see what is taken into account.

There are some edge cases, like if the selection is wider than the screen. (there is somewhere an issue on the tracker that I created before I started to maintain SynEdit / still not decided if/how to solve it).


Btw, I am always interested on how other editors handle the various situations that come up. Maybe it inspires some ideas.

[d7_2_laz]

Martin, what i can say so far is that i saw it with UltraEdit (an older version) and Notepad++ as well, but i had not recognized it yet within the Lazarus IDE (need to re-check).

So far it might have good reasons (user decision, typical 'target conflict'), but using the search item navigation for myself i some day felt increasingly that it didn't meet my own usage expectation.
Crazy enough, after months of usage some day one may stumble upon such "edge cases" surprisingly ...

Anyhow - 'workaround' via LeftChar appears to be available .... 

[Martin_fr]

Yes Notepad++ seems to keep the scroll too.

And, even if the editor would know that the scroll pos was set by the last search... If my next search result is immediately an the next line, and there are e.g. 80 visible columns:

Code: Text  [Select][+][-]

1. {90columst} |found|
2. {70 columns} |found|

Then it is possible to reset the scroll completely.
But to a user it may actually be helpful to keep the last "found" in view.

When you first reported I briefly thought, if there could be a simple set of rules (that most people might be able to agree on).
E.g., if the next result is outside the current page (or better, at least one full page away). Or is one paragraph enough, but that goes into interpreting the text content.... Not every empty line is the same separation of content.
There isn't an easy way to define when to reset scroll.

Yet, I know from myself when going through code, that there is the one over-long line that scrolls the text out, and then for the next  (and all further) find result, I can't read the context...

And then, I am sure, if it was always reset, then I would start noticing the code with 2 over long lines, and one shorter in between, where I really don't want the scroll reset (just don't know it yet).

[Martin_fr]

What might be helpful (in terms of the IDE) is a keycombo that resets the scroll to as far left as possible without scrolling the selection out of view. So that its possible to change reset the scroll without changing the caret pos.

Of course to really make use of that, I also need a keyboard with an extra 2 dozen keys... (or more)

[d7_2_laz]

Of course a keycombo could be a possible approach (personally i'm not a fan of remembering dozends of key combos), but there will be a natural end for such, just as you say ...
Or an additional option (sth like 'xyzTryPreserveLinestartVisible') .... but where should such end up?
No, i'd not vote for any change here that increases complexity (possibly unless multiple similar complaints could be heard). The more as a way around on the application side is available, for any kind of conscious decision for this specific behaviour.

Indeed my need came up having recognized that i'd oftenly moved the scrollbar a bit, not only because having seen "ocedure" instead of "procedure", but more i hadn't always been sure where i am due to a possible truncated indentation ("is it still part of a declaration, or am i already within the implementation part?").

Maybe worthy to mention: a window's width as determining factor. Whereas the IDE imo will be rather opened near full-width, a personalized tool more likely is opened in smaller widths so that the occurance of the phaenomenon becomes more obvious.
But on self-written app's level it's manageable now with the information you gave 

[Martin_fr]

And you can always word-wrap (using 4.99). Then horizontal scrolling isn't an issue.

[Martin_fr]

I given it some more thought....
Just collecting some ideas, for maybe someday.

Basically it affects search and similar commands. => They set the selection.

1) We can not know if the current selection was set by a search (including  incremental, or next-word, or tab-syncro-cell). Because after IDE restart the selection comes from the session instead.

2) We do know if there is a selection.
3) We know if the selection moves (not extends / but begin *and* end are relocated)

The last one means the selection is changed by a command (that may be a search or undo).

Then there may be rules such as

A) black or whitelist of commands during wich scroll may be reset.
B) context of the new selection


(B)
Is the one that could be interesting.

- If the selection moves in the same line (backward search) then IMHO scroll should not fully reset. You may still want to see the previous location...
- If it moves just one line, and the next line is equally over long, then even if it is further left on the next line, maybe (optional?) NO reset....

There could be a minimum amount of lines to move the selection (in a single move) to allow reset.
Or there could be "leaving current paragraph" (paragraphs separated by empty line).

There could also be, if the new line (or new paragraph (any line within)) are all short enough to fit onto the screen (or partial reset, according to longest line in paragraph / avoid empty scrolled area on right)

[d7_2_laz]

This topic here is one of the rare cases where i heavily hesitated to propose some very special need as part of a change, as it's very subjective and most others might feel different, and it depends on other factors. Already named: had the scroll position earlier being choosen by intention? Or a conflict of objectives: where is the priority: to see the previous location of a 'hit', or to leave a beginning of a line visible if possible? Which special use-case, habit or expectation might be behind if someone is searching and scrolling?

Myself i liked to keep the context (ie. indentation) of "procedure" and "function" (in declaration and implementation) in view as far as possible, for better orientation within the context ... and here the reset turned out to fully serve this need within a programmed app (see attached sample video). Surely such wouldn't meet everybody's wishes ...

- If the selection moves in the same line (backward search) then IMHO scroll should not fully reset. You may still want to see the previous location...

Yes, in that case a previous match (placed more rightmost) might rather be shifted out of view, whereas the current match might be more anchored to the line's start. Depends subjectively on one's preference what's preferred ...

- If it moves just one line, and the next line is equally over long, then even if it is further left on the next line, maybe (optional?) NO reset....

There could be a minimum amount of lines to move the selection (in a single move) to allow reset.
Or there could be "leaving current paragraph" (paragraphs separated by empty line).

But if, e.g., a next line contains another procedure's declaration, independently of empty lines, it could be the case that's just expected to recognize that better too, by seeing the beginning of the line.

Completely subjective such of course, very difficult to derive some 'ergonomical' conlusion i'd guess.
Fortunately Lazarus incl. it's components is such a strong environment to allow everyone to write his supporting tools and apps according to it's needs 

[Martin_fr]

I wasn't planing on a SynEdit feature. Rather than adding something to the IDE.
I.e. the IDE would get an option, with a few choices.

Or, maybe... Just got had another idea, the IDE could allow calling an Pascalscript event, and that could deal with it.

Anyway, all subject to me finding actual time for it.