Don't set IDE scripts that don't compile #1269
Conversation
|
What will happen if users set this to true and then edit scripts? Currently non-compiling scripts can be saved as works in progress, and this is useful when editing someone else's long scripts. Will there be an indication that the script can not be saved or will this just be a silent failure? The latter would be a red flag for me. |
|
At the moment with this patch there will be a silent failure to set the actual object script although the script editor will highlight the errors so it will be rather obvious as long as people know that |
|
Hmmm... maybe I've used glx2 for so long that I've forgotten how the IDE's editor works, but with glx2 it's certainly possible to save works in progress even if they don't compile. Ah! can you still save the script but not compile it? I'd be fine with that. |
|
I'm not sure what you mean there. The entire point is we dont want to set the script of the object to a script that doesn't compile because doing so removes all its handlers from the message path and this causes uncompiled critical IDE script hell syndrome |
|
heh... yes, I know that syndrome. But saving the text is different from setting the script. And that's the way glx2 has always worked. |
|
...and I see you put a notice in the use-list, so I'll move commenting there. |
|
OK, I don't know how glx2 works but the IDE has an intermediary object it uses to compile the script to check for errors and then it applies the script to the object itself. What this does is skip that last step if there's a compile error and gREVDevelopment is true. If we were implementing this for general use we would most definitely want some warnings at various points. |
|
Yes, I think that's the only way to do this (compile, check for errors, set if possible). As long as there are annoying warnings and it's still possible to save the script text without setting it then I'm happy. I wouldn't want to spend a couple of hours working on a script, still not have it compile-ready, and not be able to save what I had done before going to bed. Working on someone else's 15k-line script (I've been there) gets to be an all-or-nothing marathon in that case. But saving the script/stack and setting the script are two different things to talk about, so I think we're ok. |
|
This is certainly a neat idea for when you are editing certain IDE scripts . However, I tend to run with gREVDevelopment true when I'm not editing the IDE just so I can see if there are any IDE errors being thrown which I can report to get fixed. Also, with the patch which sets gREVDevelopment true (which I believe was recently merged) when building from source, there will be even more scenarios when (even us) will be running and using the IDE when we aren't actually editing it (i.e. pretty much me, all the time when doing engine dev). I wonder if this extra 'bit of safety' should be tied to whether a stack is an IDE stack, rather than all stacks. It should also probably 'do something' in the script editor window when a script didn't compile and thus has not been set on an object so that you can visually see that if you close the script editor, you might lose work. |
|
Yes, it's the "losing work" part that troubles me. I also run with gRevDevelopment true much of the time, partly because I'm working at a system level quite a bit, and also partly because it's enabled me to catch and submit fixes for some IDE errors that have previously gone unnoticed. |
Previously there was a check to ensure script editor scripts were not set if they didn't compile. This has been extended to all IDE scripts. An appropriate warning is displayed if the script editor or tab will be closed offering the chance to save uncompilable work in progress if necessary.
montegoulding
force-pushed
the
dontsetuncompiledscripts
branch
from
8ec3636
to
96a2caf
Compare
|
OK, I've tweaked this a little so that:
I actually think this new IDE behavior would work well in all cases. The only significant hurdle would be crashes while sorting out compile errors but we would like to avoid them regardless... |
|
The script editor save handling probably needs some sorting out as at the moment it will appear to save but the erroring script won’t be applied. I’m looking into that now. I think in the event the script application couldn’t happen it should beep at you or something rather than save. |
|
Hmm... Actually the save behavior is a bit odd. It applies all scripts but only saves the stack with the currently open tab. What if you didn't want some other edit saved? I guess it is a helper if you are eating multiple scripts from the same stack though. Perhaps it should save all stacks too though as it does give that appearance? |
|
Actually I misread the code and it only applies scripts from the stack of the currently being edited script which makes much more sense! |
|
Thanks, @montegoulding this is sounding good to me now. |
This patch ensures that the user receives a warning when trying to save an IDE script from the script editor and one of the open scripts from that mainstack has compilation errors. It also replaces revTargetStack with ideMainStackOfObject to ensure all open scripts within a stackFile are applied during a save. Previously editing the script of a mainstack object and the script of a substack object would not apply them both before save.
montegoulding
force-pushed
the
dontsetuncompiledscripts
branch
from
f653a8e
to
c238c51
Compare
montegoulding
changed the title
|
@livecode-vulcan review ok c238c51 |
|
💙 review by @livecodeali ok c238c51 |
|
Thanks @livecodeali once we have used this for a bit to confirm it covers all bases we can look at enabling this for everyone I think. |
Previously there was a check to ensure script editor
scripts were not set if they didn't compile. This has
been extended to all scripts when gREVDevelopment is
true.
This change makes it much simpler to edit
IDE scripts, however, the team needs to be aware that
scripts with compile errors will not save. If necessary
set gREVDevelopment to false temporarily to work around.