How to check syntax without AutoIt saving the script?

[c.haslam]

In SciTe, of course

[argumentum]

No can do.

Now if you feel like getting the data from scite, save it to another temp file and running the syntax utility and then, sending that to the SciTE console ( all that would be something you or someone else codes ), then yes.

[Dan_555]

You could write an user tool, which you set to not save on execute https://www.autoitscript.com/wiki/Adding_utilities_to_the_SciTE_Tools_menu

Then the script would copy all text from the scite window, save that to a temporary file, let the syntax checker check the code, catch the output and display somehow the errors (for e.g. in a msg box) if there are some ofc.

Or copy the code manually into a new tab, save that and run the checker ...

Edited December 5 by Dan_555

[CYCho]

--Deleted--

Edited December 5 by CYCho

[Musashi]

A simple solution would be to start SciTEConfig.exe (located in the directory ..\AutoIt3\SciTE\SciTEConfig ).
There you can specify how many backup steps should be created (e.g. 5 previous versions of your source code). If you now execute a RUN within  SciTE, the code will be saved, but you can return to previous versions.

  

[Nine]

The strategy I prefer, as I am using it ALL the time, is the Tidy backup.  You decide when you want to make your backup.  If you are making a lot of changes and want to rollback to few days ago, then Tidy is more adapted to that situation.  And one non-negligible benefit of Tidy is of course to have your scripts all cleaned-up. 

[c.haslam]

Thanks. Where are the various tools documented?

[Jos]

Can somebody please explain why this would be needed at all?

[Musashi]

10 minutes ago, Jos said:

Can somebody please explain why this would be needed at all?

No, at least I can't . It looks like a typical XY problem to me - https://en.wikipedia.org/wiki/XY_problem

[c.haslam]

To me, it is desirable to have a script that has bugs in it, bugs that AutoIt catches, not be saved automatically. It makes sense to be able to avoid saving such code until it has been fixed.

 

[Jos]

Not really to me. It makes sense not to put it into production before it's error free and bug free, but to be able to check and test it, you always will have to save it one way or the other.

So one thing you could think of is to create a script that will copy the clicked file to a development directory before opening it, but that will open a whole other can of worms, like missing local includes and wrong paths for opening files.

So to me one needs to setup a development environment for those scripts that are important.

My 2 cents :-)

 

 

[c.haslam]

Thank you for your 2 cents.