[Lazarus] Need testers for Pascal-Editor-Macros (latest trunk)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Lazarus] Need testers for Pascal-Editor-Macros (latest trunk)

Free Pascal - Lazarus mailing list
Anyone using lazarus svn trunk and
   https://wiki.lazarus.freepascal.org/Editor_Macros_PascalScript

Please re-test all your macros, and report any breakage. (Or hopefully
the absence thereof)

*** Backup (in your primary config path): EditorMacros.xml  (this
contains your macros, in the worst case....) ***


I made some big changes in
Revision: 61896
Date: 17 September 2019 22:21:38
EditorMacroScript: Use "internal" (none-native) calling for object methods

Hoping this will keep them working with the calling convention change in
fpc trunk for i386 linux....

Thanks for any feedback.
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Need testers for Pascal-Editor-Macros (latest trunk)

Free Pascal - Lazarus mailing list
I find some bugs in EditorMacros, and report to Mantis.

There can be lot more bugs, but them hides in very bad sources style and formatting.
For example, spaces between function name and parameters: inc (i);

Please, do proper formatting. Bad formatting makes debugger crazy (with wrong breakpoints ans steps) and makes code structure difficult to read by eyes.

вт, 17 сент. 2019 г. в 23:33, Martin Frb via lazarus <[hidden email]>:
Anyone using lazarus svn trunk and
   https://wiki.lazarus.freepascal.org/Editor_Macros_PascalScript

Please re-test all your macros, and report any breakage. (Or hopefully
the absence thereof)

*** Backup (in your primary config path): EditorMacros.xml  (this
contains your macros, in the worst case....) ***


I made some big changes in
Revision: 61896
Date: 17 September 2019 22:21:38
EditorMacroScript: Use "internal" (none-native) calling for object methods

Hoping this will keep them working with the calling convention change in
fpc trunk for i386 linux....

Thanks for any feedback.
--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus


--
Bodrov Sergey
software development, IT consulting
Phone (Belarus): +375(25)794-21-58
Skype: sergey.bodrov1


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Need testers for Pascal-Editor-Macros (latest trunk)

Free Pascal - Lazarus mailing list
On 18/09/2019 15:23, Sergey Bodrov via lazarus wrote:
> I find some bugs in EditorMacros, and report to Mantis.
Thanks, I will look at the reports.

>
> There can be lot more bugs, but them hides in very bad sources style
> and formatting.
> For example, spaces between function name and parameters: inc (i);
In which package, please?

>
> Please, do proper formatting. Bad formatting makes debugger crazy
> (with wrong breakpoints ans steps)
Only line breaks should affect the debugger (space/tab should not, if it
does an example would be welcome).


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Need testers for Pascal-Editor-Macros (latest trunk)

Free Pascal - Lazarus mailing list


> There can be lot more bugs, but them hides in very bad sources style
> and formatting.
> For example, spaces between function name and parameters: inc (i);
In which package, please?
Where TIdeMacroEventReader defined.
 
> Please, do proper formatting. Bad formatting makes debugger crazy
> (with wrong breakpoints ans steps)
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.

if a < b then
  Delete(a);
// When condition is true, debugger step on line with Delete(a) and it can be skipped with F8 or visited with F7. And breakpoint can be set on desired condition branch.

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.

--
Bodrov Sergey
software development, IT consulting
Phone (Belarus): +375(25)794-21-58
Skype: sergey.bodrov1


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Need testers for Pascal-Editor-Macros (latest trunk)

Free Pascal - Lazarus mailing list
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.


--
_______________________________________________
lazarus mailing list
[hidden email]
https://lists.lazarus-ide.org/listinfo/lazarus