Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2011-11

Source editor navigation

6 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Hans-Peter Diettrich

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)?

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 :-(

DoDi

Reply by email

Martin
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 18 lines
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

Show quoted text 5 lines
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.

Reply by email

Hans-Peter Diettrich
to Martin
Show quoted text 7 lines
> 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.

No, it doesn't work on Windows :-(

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

Reproduction is a problem. The behaviour might be related to unsaved changes...

DoDi

Reply by email

Martin
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 6 lines
> Please report on mantis, but further steps to reproduce may be needed. Reproduction is a problem. The behaviour might be related to unsaved changes...

just re-read:

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

Do you click (right click / popup) on the actual tab? or on the text of the source editor?

Please note that even if you click on a tab, the popup menu always belongs to the active tab, never the tab over which the mouse currently hovers.

That's just how it currently works. (and how apparently it always has in Lazarus)

Reply by email

Hans-Peter Diettrich
to Martin
Show quoted text 16 lines
On 12/11/2011 22:32, Hans-Peter Diettrich wrote: > >> Please report on mantis, but further steps to reproduce may be needed. > > Reproduction is a problem. The behaviour might be related to unsaved > changes... > just re-read: > > 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 Do you click (right click / popup) on the actual tab? or on the text of the source editor?

On the text in the active editor, of course :-)

Editor tabs are another (or related?) problem, sometimes the Focus is set to the tabs instead of the text. Perhaps this is reproducible:

Navigate from a method declaration to the implementation, in an include file. Save, leave and restart the IDE. The caret should be in the include file again. Now navigating to the declaration shows the correct unit but makes the caret disappear, and further cursor movements (up/down...) select another tab.

One more, possibly related: The Code Explorer does not always follow the active editor window. Make it display the unit name in its Caption, for easier verification. Then activate a different editor window (click into the text), and the Code Explorer doesn't react. I often have to switch to another tab (of the same window), before Code Explorer notices the changed unit.

DoDi

Reply by email

Martin
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 5 lines
Martin schrieb: > Do you click (right click / popup) on the actual tab? or on the text > of the source editor? On the text in the active editor, of course :-)

Strange..., but no idea.

Maybe another window you have open (like fpdoc, code explorer ,... or a package you have installed...
Docked or undocked IDE?

What version of Winodws

Show quoted text 9 lines
Editor tabs are another (or related?) problem, sometimes the Focus is set to the tabs instead of the text. Perhaps this is reproducible: Navigate from a method declaration to the implementation, in an include file. Save, leave and restart the IDE. The caret should be in the include file again. Now navigating to the declaration shows the correct unit but makes the caret disappear, and further cursor movements (up/down...) select another tab.

Unfortunately not happening here. I I restart the IDE, it makes the main IDE bar active, So I first need to set focus to an editor, but then it behaves....
Same questions as above...

I know that used to happen, but I haven't had it for some years now.

Show quoted text 7 lines
One more, possibly related: The Code Explorer does not always follow the active editor window. Make it display the unit name in its Caption, for easier verification. Then activate a different editor window (click into the text), and the Code Explorer doesn't react. I often have to switch to another tab (of the same window), before Code Explorer notices the changed unit.

Then maybe internally the ActiveWindow did not change? That would explain the wrong "locked" window.

Maybe some focus or activate message reaches the wrong editor at the wrong time?

Try compiling with VerboseFocus defined, and watch the console output/log file

Reply by email