F4 - Run to cursor

[duzenko]

Sorry for necroposting, but can we please get one menu item for both debugger backends (in the sake of general sanity)
I'm sure there's a mighty hero somewhere who can add an if/then clause in the right place of the source code?

[Martin_fr]

Sorry for necroposting, but can we please get one menu item for both debugger backends (in the sake of general sanity)
I'm sure there's a mighty hero somewhere who can add an if/then clause in the right place of the source code?

"both debugger backends"

There are 3 main variants: FpDebug, Gdb, Lldb - and then variants thereof....
https://wiki.freepascal.org/Debugger_Status#Available_Debuggers

"get one menu item"

There are 2 different commands. They perform a different action.
(And iirc FpDebug and GDB support both commands.)

"Run to cursor"
"Step over to cursor"

"Run to cursor" => Works like
- breakpoint at cursor
- run(F9)

"Step over to cursor" => Works like
- While
-    not AtCursor()
-    or
-    HasSteppedOut
- do  Step Over(F8)

"Step over to cursor" means you must be able to reach the location at cursor, without leaving the current function.
(But you will not stop at it, inside a recursive call)

"Run to cursor" will stop inside a recursive call

And this is why both commands are important.
- If I am in a function, that has recursion, I may need "Step over to cursor".
- But if I want to run to just any location then I need "Run to cursor"


If you want to start the debugger, and stop at some location, then you need "Run to cursor" - because you aren't inside a function (as the app is not yet running), and so "Step over to cursor" can not work.

----
All this is independent of the Debugger Backend.

As indicated, some backends support both commands.

At the time this thread was created, it may have been the case that any backend supported only one (or none) of those 2 commands. But that is no longer the case.

[Martin_fr]

And, yes: Documentation is needed.

There is some mention here:
https://wiki.freepascal.org/Debugger_Status#Execution_Control_.28Run.2C_Step.2C_....29

There is complete absence here:
https://wiki.freepascal.org/Main_menu#Run

Not sure about other mentions....


Currently waiting for a contributor who wants to help bringing the Documentation up to date.

[duzenko]

Thanks, I see the reasoning behind the current implementation

BUT it also makes Lazarus an odd duck in the world of IDE's where there is exactly one Run to cursor and it's always the same keyboard shortcut
I don't argue the usefulness of step over to cursor but what I suggest is to make this compatible in UX with at least one other popular IDE, i.e. Delphi
So have F4 to do what it does in Delphi/FPIDE/etc and add a special kbd shortcut to the other one so that we don't have to reset the keymappings after each installation/config reset

[Martin_fr]

The problem with changing existing keymappings is that people are used to the current layout.
I.e. everyone who has not (recently) switched for Delphi - but used Lazarus for a while - is used to the existing keymap.

I don't know how many other keymap diffs we have from Delphi, and maybe a "Delphi like" keymap would be useful.
There is currently an issue on the bugtracker about a VisualStudio like keymap.
Also an argument about it being build in, or something to download and "import" (using the import button).

Maybe get in contact there / Maybe create a feature request, and refer the other issue.
Afaik someone from the team is looking at the VS-map issue, so maybe they can look at helping with a Delphi like keymap too.

This may even go further than just the keymap. Afaik we have many other settings, that have Lazarus defaults.
So there may be interest in having a complete preset, for those options.... But that would probably require some one to contribute it.

I also recall, that an simplified vs advanced option has been suggested in the past. But on one had ever had the time to do anything about it.

As a workaround, if you have more than one install of Lazarus, you can copy the EditorOptions.xml file from one config dir to another.
But of course that is at best a workaround.