[Lazarus] Need testers for Pascal-Editor-Macros (latest trunk)
Martin Frb
lazarus at mfriebe.de
Thu Sep 19 11:17:10 CEST 2019
On 19/09/2019 09:25, Sergey Bodrov via lazarus wrote:
>
> 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".
> 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?
> 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>
More information about the lazarus
mailing list