[Lazarus] Source editor navigation

Martin lazarus at mfriebe.de
Sat Nov 12 17:15:10 CET 2011

On 12/11/2011 15:48, Hans-Peter Diettrich wrote:
> When multiple editor windows are open, the navigation back to the 
> previous location (CTRL-H) sucks. When I have source code in one 
> window, and the documentation in another window, both windows should 
> use their own jump history. Currently I cannot search something in the 
> documentation, then go back to source code and navigate back in the 
> source code - instead the focus moves back to the documentation tab 
> and window, and undoes all searches there, before the focus moves back 
> to the previous tab.
> I understand that jumps *by source code navigation* (jump to 
> declaration) should be undone in the exactly same order, even if they 
> switch from one tab to another one. But when the user switches to some 
> *unrelated* tab or window, a different (unrelated) search history 
> should be used in that tab.
> Can the behaviour be modified, to keep jumps to declarations in one 
> history list, and remember other navigation in different lists 
> (separately for every tab)?

Hm, that sounds pretty specific to your situation (yet I can see the 
problem and it is a valid issue)
Currently no such behaviour exist, or can be archived via config.

You can open a window from the view menu, that displays the entire 
history jump list, and allows you to select from it. (I know, not what 
you are looking for)

The problem is how the IDE should know what is "unrelated".
e.g. I usually ave several windows open, but all tabs are somewhat 
related. So if I change windows, I want and need history to take me back.

I do btw have my own wish-list on the topic. If I navigated by code 
jump, and the target was in a different unit, then I want the ability 
not only to return to the location I came from, but also restore the 
topline/caret from the unit I had gone into (and which I leave, by going 
to history)
Yet again, It isn't clear how to activate this versu the plain jump back

> BTW, "Lock Page" doesn't work properly with multiple windows - it does 
> not lock/unlock the tab from which the context menu was invoked, 
> instead a tab in some other (random?) window is locked :-(

Which platform? Win, gtk, qt, mac?

It works fine here on win.

If GTK maybe it is related to some of the focus issues that some people 
have in the past experienced. E.g. maybe if using the context menu, on a 
window, without focusing it before => so maybe a generic issue with the 
context menu applying to the wrong window?

Please report on mantis, but further steps to reproduce may be needed.

More information about the Lazarus mailing list