[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