Sergey Bodrov wrote 9 lines
Only line breaks should affect the debugger (space/tab should not,
if it
does an example would be welcome).
Example:
if a < b then Delete(a);
// When debugging step-by-step with F8, that line will be skipped in
one step, and it remains unclear, that Delete(a) executed.
Ok, so linebreaks. Just wanted to be sure there was not something about the debugger that I was not aware of.
Not sure how much of that I will change. The downside is, that it produces extra commits in an "svn blame".
Show quoted text 5 lines
Spaces between function name and parameter make function be like a
variable. I personally always add empty parenthesis to every
procedure, function and method, even if they don't have parameters. It
helps distinguish, when indentifier can be stepped in (with F7) or
skipped (with F8) and inspected by watch.
I see, but that's not gonna change for this unit.
------------------------------------
Your question from the bugtracker:
https://bugs.freepascal.org/view.php?id=36083#c118112 I try to keep general discussions of the bug tracker. Also the above could go on the bugtracker as a feature request => But then it was a different issue, from the reported bug. Discussing it as part of the bug, will distract from the core of the issue.
It may be that I am overlooking something, and it is indeed relevant for reproducing the issue, in which case it would belong, but for now lets take it here.
So far I still need a way to reproduce the bug.
Is there a way to visually separate Editor Macro window tabs to
'macros' and 'scripts'?
Currently there is no visual indicator to show if a macro would work without PascalScript. Except of course if you uninstall PascalScript, in which case scripts would be shown as having an error (red dot with exclamation mark:
https://wiki.lazarus.freepascal.org/IDE_Window:_Editor_Macros#Display ).
There is also no plan to indicate this. (So that is open to discussion).
The reason is that a "recorded macro", is a script too (well as a script it gets enclosing begin/end).
For PascalScript ecChar() and ecDelecte are defined as functions. So the "recorded macro" is proper Pascal.
Implementing a check would not be complicated. The PascalScript-macro-class could just call the inherited class to check if it can be parsed as "recorded".
Adding a visual indicator, would need to be an icon. For once a macro (either) is defined, normally both types can be used in the same way. Having separate list, would make it harder to find the correct one. Personally I ever think, that adding an indicator icon would might be contra productive. People would wonder what the icon means.
Normally there should not be a need to distinguish, if you have PascalScript macros, then PascalScript works on your system. There is no reason why it should stop working (Except for updates like the one I just did). So you never need to know. You can use either type of macro.
If they do stop working, then there is an indicator. Of course the same indicator is used if your EditorMacro.xml becomes corrupted. Recorded macros that can not be read, get the same indicator.
If you uninstall PascalScript then the IDE does not know what a script macro is. So at that point it could no longer show an indicator icon. At that point, a script macro is just a broken recorded macro. Even if PascalScript is installed, how do you know the difference between "ecLeft;" "thrash ecLeft;" and "if a then ecLeft" vs "ifa then ecLeft". At what point does it become a Pascal-script?
Show quoted text 6 lines
Macro - plain text, sequence of editor action names. Can be recorded
from user actions and edited in simple text editor, with trivial
validation. Maybe, there can be some action to run desired script
Script - Pascal script, edited in main editor, with sintax checking,
autocompletions, hints and other features. There can be function, that
run desired macro. Scripts disabled if PasScript not available.
Both can be edited in the IDE. Codetools (auto complete) is very limited, as it does not know the macro is not part of your project sourced. And also does not know the "ecLeft" or "Caller".
But when you save a macro, you should get an error with line number.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190919/1a8955cf/attachment.html>
