Lazarus editor feature request

[440bx]

Hello,

The Lazarus editor allows setting bookmarks using shift-ctrl-<0..9>.

When the bookmark is recovered (using ctrl-<0..9>), the editor puts the line on which the bookmark was originally placed in the vertical center of the editor window.  I personally find this less than ideal.

I often place the line on which I am going to set a bookmark at the top of the window and set the bookmark then and there (line at top, i.e, bookmark on top line.)  The idea is to have a full page of information below the bookmark.  Currently, when the editor places the line in the center of the window, half the information of interest is "lost" (need to scroll up to reveal it.)

The feature request is: when the bookmark is recovered, place the line in the same location it was in when the bookmark was set instead of always in the vertical center of the window.

Useful comments welcome,

Thank you for reading.

[Martin_fr]

Interesting idea. Though I wouldn't wanna loose the current mode.

Couple of other notes (that would need to be clarified for an implementation):

* "same location" is not well defined. Same amount of lines from the top? Same amount of lines from the bottom? Same "percentage" in the visible area? Include horizontal scroll location?

* In case of "same amount from top": If the bookmark was 30 lines from top (window may have more), and now the editor is in a window with only 25 lines visible, then it can't be placed 30 lines from top.

* Should the location be adjusted, even if the bookmark is in the visible area? I.e. if the bookmark wants to be on the top line, but currently is visible on the 3rd line? or currently is visible on the 35th line?

* What if the editor window is locked? https://wiki.lazarus.freepascal.org/IDE_Window:_Editor_Options_MultiWindow#Locked.2C_if_text_in_view
Should such an editor be considered for the bookmark (if it isn't on the desired location / the editor wont scroll)? Or should a different editor be found to show the bookmark?

* Currently, if the bookmark is on page, the editor will try to locate it at least IIRC 5 lines away from the top/bottom (except if "locked"). In case of "percentage" this would need to be considered, if it should be applied or not.


There are several ways to make that optional...

- Global option, toggle for all bookmarks.

- New Key-combos (that can replace the old ones), that will "goto as current" or "goto with location"

- New Key-combos (that can replace the old ones), that will SET the bookmark with/without remembering the location. (This could then still have key-combos to "goto ignoring location")


Until a decision is made, it may be possible to add editor macros (not tested). Though a bit tedious, because each bookmark would need a separate macro (and the macro would the be assigned to the ctrl-1 (or whatever bookmark num) key-combo).

[440bx]

Please, refer to the attachments

The first attachment shows the window where bookmark 0 was set.  Note that in that case, it is set with the line at the very top of the window.

The second attachment shows the window _after_ recovering the bookmark.  Note that the bookmark is now in the middle of the window instead of at the very top where it was when it was set.

I would like the line where the bookmark was set to be back in the same relative position in the window where it was originally (in this case at the top but, in reality it could be anywhere within the window.)

In the example I'm using, restoring the bookmark in the middle of the window instead of at the top causes about 40 lines to be "missing" (I have to scroll up 40 lines to be back where I was when the bookmark was set.)

That's as far as "same location" goes.

In the case of "same amount from the top", if the user changes the window size in such a way that the bookmark cannot reestablish the original view, e.g, 30 lines below top but the window is only 25 lines, in that case, IMO, the current behavior would be fine.

I'm not familiar with locked windows.  I've never used that feature but, if the bookmark was set in a locked window then, I'd be of the opinion that restoring the bookmark in a separate window is probably the right thing to do.  The lock in the window is respected and the bookmark is recovered, albeit in a separate window (but that comes with the "locking a window" territory.)

As far as the 5 lines away from top or bottom, I think the main goal of a bookmark is to put things back as closely and accurately as possible to the way they were when it was set.  If that's not possible then whatever is reasonable that makes the line where the bookmark was placed visible.

Succinctly: if a user places a bookmark in an editor window and the editor window's size isn't modified then recovering the bookmark should restore the view ideally exactly as it was when the bookmark was set.  If the user changed the window size then restore the view conserving the vertical distance from the top of the window to the bookmark but, if that is not possible due to the user's changing the size of the window then I'd prefer having the bookmark at the top of the window but, in the case of the window size having changed, I would find it acceptable to have the bookmark be in the vertical center of the window.

No additional comments on the locked window case.

Just for general information, the reason I like this feature is because with bookmarks behaving that way, I use them to quickly get a full page of information (contextual information) that is relevant to whatever I'm coding at the time. 

ETA:

Added the forgotten attachments

ETA:

Added a few words to make the sentence clearer and underlined the sentence where the words were added.

[Martin_fr]

OK, "relative" => then the problem with a lower height window does not exist. If the height changes the "stored offset from top" is scaled accordingly.

accurately as possible

That would mean to look at horizontal scrolling too. (After all, bookmarks already store their x-pos).

That however may need some thought if the line with the bookmark in it, is split before the bookmark => that changes the X pos of the bookmark. It then makes no sense to keep the horizontal scroll pos. Or it would need to be scaled according to the length of the line before/after (and then at the time of restoration, scaled to the width of the editor if that changed).

Sorry, not trying to make it complicated. Just trying to get "exact terms".


Lets see, if others have opinions on how this would work for them...

Feel free to add a feature request. (it will probably be some time before I look at it)

I would suggest, to make toggle the functionality by adding 10 new ecGotoBookmarkAndScrollPos.
That offers more flexibility than just a global option (as diff keys can be assigned to both sets, and both functionalities can be used). Downside, if someone wants the function on the existing key combos, they need to change 10 of them.
Though a global option can be discussed...

[440bx]

That would mean to look at horizontal scrolling too. (After all, bookmarks already store their x-pos).

Yes.  Ideally, restoring a bookmark would bring the view (horizontal and vertical) back the way it was including cursor position.  That would be ideal. 

Sorry, not trying to make it complicated. Just trying to get "exact terms".

No worries at all.  On the contrary, I appreciate the thinking your putting into it.

IMO, if the window size (height/width) changed from the time the bookmark is set to the time it is restored then, the IDE should try to restore something that is reasonably close to when the bookmark was set but, since the "environment" has changed, it won't be able to be fully accurate and the user should be fully aware of that.  Personally, I very rarely resize the editor window.  Once I have it set to a height and width it pretty much stays that way.  The few times I resize a window is when I need to make it wider and that's fairly rare.

Lets see, if others have opinions on how this would work for them...

Yes, it would be nice to have other opinions, whatever they may be.

Feel free to add a feature request. (it will probably be some time before I look at it)

I'll do that and I understand it is just a "nice to have" feature.  Definitely not "critical".

ETA:

created feature request 40912
link: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40912

[VisualLab]

Lets see, if others have opinions on how this would work for them...

Yes, it would be nice to have other opinions, whatever they may be.

It seems to me that this would be a useful functionality.

[440bx]

It seems to me that this would be a useful functionality.

Thank you for expressing your view on the feature.  I suppose the greater the number of people who like it, the better its chances are to be implemented.