Slow Script Editor

[TheOtherBob]

I've worked with several different IDE's over the years, but I'm new to LiveCode. I'm running 9.6.6 on Windows 10.

I have a very small project (single stack, 3 cards, almost no code as yet) and I've noticed that the script editor can be very slow at times. I'll type as many as 10 to 20 characters before they appear in the script, and then they all appear at once. I've read other posts whose authors describe the same issue, and have followed the steps recommended to alleviate them, such as closing the Project Browser, and disabling Script Debug Mode, which have helped a bit, but the performance of the script editor is still very slow. Oh yeah, this occurs even while not in 'run mode'.

Is there anything else I could disable that might alleviate this?

Thanks!

[stam]

Personally i prefer to use state-of-the-art code editors rather than the built-in editor.

As much as it is OK for many things it is just not as good as a dedicated code editor such as VSCode or Atom, both of which have plugins that provide code formatting, syntax colouring, linting etc, on top of the standard features like code-folding, dark mode and so on.

To be able to use this moderately effectively, i've converted all my scripts where possible to scriptOnlyStacks. It's fairly straightforward to use these as stack scripts, card scripts or even object scripts (by setting the scriptOnlyStacks to be behaviour stacks) and can be loaded as backscripts where needed. This then makes using GitHub more meaningful and if a project is on GitHub it can be directly opened in it's entirety in VSCode (or Atom) and can be sync'ed between machines via git. Another benefit is that by using scriptOnlyStacks i can then break down massive scrips in to smaller entities and organise these in an MVC type pattern - easier to organise and easier to reuse in other projects.

The way i set my current project up is that i have a scriptOnlyStack who's only job is to dynamically serve up file paths for the scripts depending on whether in IDE or standalone, so i can just pass the functions as filepaths for the scripts and load them at start up, or where needed.

I'm relatively happy with this setup; it's of course not quite the same as using a properly integrated setup (for example when debugging i end up using the built in editor in parallel with VSCode) and the ideal would be that the IDE would provide a code editor on par with VSCode, or at the very least allow full integration with 3rd party editors... but for now this will do...

[stam]

PS: if you are considering replacing scripts with scriptOnlyStacks as i've done, you may find Richard Gaskin's expertly detailed post on the messagePath useful.

It's definitely worth a read: https://fourthworld.com/embassy/article ... _path.html

in summary:

The yellow boxes are easy to replace with scriptOnlyStacks - but the missing bit is that both groups, cards, substacks and mainstack can also have behaviours (which can be scriptOnlyStacks as well), so that 90% of your code can be in text files that work perfectly with code editors like VSCode.

[bn]

Hi Bob,

There are some reports about the Script Editor being slow on Windows (I am on a Mac and have not experienced this)

https://www.mail-archive.com/use-liveco ... 09768.html

From that discussion:
in case you use Microsoft Defender as antivirus you might try to exclude the Livecode program folder and its
support folders (like preferences) from realtime scanning in MS Defender.

Kind regards
Bernd

[stam]

I'm on a mac too and haven't experienced severe lag when typing either - but i do find it a bit slow with larger scripts, in a way that 'proper' code editors just aren't... i wonder if the 'compiled' version of LC stacks which i read somewhere is a planned feature will improve that?

[bn]

I'm on a mac too and haven't experienced severe lag when typing either - but i do find it a bit slow with larger scripts, in a way that 'proper' code editors just aren't... i wonder if the 'compiled' version of LC stacks which i read somewhere is a planned feature will improve that?

I see the slowdown with larger scripts also. And I also wonder what 'compiled' will mean.

As an explanation/excuse for the script editor I consider it quite a feast to use a simple Livecode field and pile a _LOT_ of code on top of it to edit scripts.

Kind regards
Bernd

[richmond62]

Well . . . I'm doing most of my work on MacOS 12.4, and using LC 9.6.3 Community,
and recently (i.e. since I upgraded from MacOS 11 to MacOS 12) working in scripts that contain about 6000
lines in my Devawriter Pro I have noticed a significant lag with post-and-replace actions . . .

. . . but as that gives me time to take a gulp of coffee, I'm not getting worked up about it.

[jacque]

Start by turning off all the options in the Edit menu you don't use. They cause slowdowns.
https://forums.livecode.com/viewtopic.p ... te#p182698
I have all of them off except for auto-bracketing.

[TheOtherBob]

General reply to all who have responded thus far...

First, thank you for sharing your insights.

I have wondered whether the Mac version of LC might be more robust than the Windows version, because I've seen a similar situation with other apps that were created first for MacOS and later converted to run on Windows.

I started programming 45 years ago, using punch cards and waiting hours for turn-around to see the results of a single run of my application. Software development tools have come a looooooong way since then.

LC appears to have numerous very cool features that enhance application development, but some of those features actually get in the way. The sluggishness of the script editor appears very similar to application behavior in which a user interface thread does not get a high enough priority over other threads, and should not be too difficult to fix, one would think. It's as if the code that's doing syntax checking 'live' while I type is 'trying too hard', and as a result gets in the way.

Also, the fact that application code ends up being 'spread all over the place' comes with the territory of LC's style of object-oriented development, but presents another challenge -- source code version control becomes cumbersome at best and impossible at worst.

Workarounds don't appeal to me. I'm completely spoiled by debuggers that work reliably and editors that are 'invisible'. I'm planning to develop for Android and iOS, and wondering if going native might present less of a learning curve and obstacle course than using LC.

[richmond62]

I started programming 45 years ago

I started in 1976 with Hollerith cards, a horrible machine that looked like a steam-drive number-pad, and FORTRAN IV.
-

-

Then I thought things were no end of posh when they introduced us to a newq type of Hollerith card where, instead of punching
holes, you filled in tiddly-widdly rectangles with a carbon pencil.
-

-

Unlike some sentimentalists, I cannot tell you how glad I am those days are gone.

but some of those features actually get in the way

That's why, when 'things' get too intrusive and I start getting attacks of GUISD (Graphic User Interface Stress Disorder)
I crank up either my BBC Model B or my BBC Master Compact and faff around with BBC BASIC on a nice, wholesome
black screen.

Workarounds don't appeal to me.

I don't suppose they appeal to anyone as, after all, they are work arounds, which is as far as I understand
a polite way of saying: a kaka way of getting a programming language to do what it should do had the
developers of that programming language been aware of that requirement and implemented it.

If you can find a programming language that can do absolutely everything with a WYSIWYG interface please let
me know.

a learning curve and obstacle course than using LC

Well; two thoughts occur to me:

1. I wonder if you would not be swapping one learning curve and obstacle course for another?

2. As I am 60 and my brain is about 75% fossilised by this point, I really wonder whether I have still got the mental
'oomph' to learn a new programming language at least up to the level I have managed in LiveCode.

I stuck #2 in there, because, TheOtherBob, if you started programming 45 years ago we must be much of an age.

As LiveCode does what I need (and that means NO walks on the wild mobile device side), slow script editor or not, I am perfectly happy with it.

[stam]

Workarounds don't appeal to me. I'm completely spoiled by debuggers that work reliably and editors that are 'invisible'. I'm planning to develop for Android and iOS, and wondering if going native might present less of a learning curve and obstacle course than using LC.

Fair enough - I was just sharing my preferred option. I too started out with the same mindset as you, but gradually got quite tired of the idiosyncrasies of the SE and also the dictionary, so i have replaced both with other 3rd party options and am personally much happier - but that's just me. But perhaps it's you too, as you wouldn't be posting the question if the script editor was reliable as you'd like. It's not bad mind you, it's just not great.
'Invisible' is fine, but using the best tool for the job is better!

similar to application behavior in which a user interface thread does not get a high enough priority over other threads

One of the issues is that the Script Editor is built as a normal LC stack; and LC is not multithreaded; there are no thread priorities because there is only one thread

It's not just a matter of speed either; for an IDE that encourages long scripts (eg script and card scripts that can contain thousands of lines) there is a notable lack of helpful features like split screen editing, code folding, dark mode, modifiable syntax colouring etc.

Bernd has a point in that it is remarkable for what they've achieved creating this as a normal stack, but if i'm honest i wouldn't mind if the SE wasn't built in LiveCode, if a compiled app did it better. It will be interesting to see if the newer developments with compiled scripts will mean for this.

Also, the fact that application code ends up being 'spread all over the place' comes with the territory of LC's style of object-oriented development, but presents another challenge -- source code version control becomes cumbersome at best and impossible at worst.

Version control need not be as difficult or cumbersome as you may think. ScriptOnlyStacks are great.They are just text files - and ideally suited.

Neither does code have to be spread all over the place; the more i've used LC the more i've centralised code putting the absolute minimum into controls and using card scripts as 'view' code (obviously some 'view' code in controls as well) and the stack scripts for 'controller' and 'model' code in an MVC approach; and from there I've began splitting out code into libraries.
As my projects have grown in size it's been increasingly difficult managing code split into interface elements and massive stack/card scripts with > 2000 lines.
The scriptOnlyStack method i mention above allows me to centralise all code in one place - an external editor like VSCode - while keeping each script reasonably sized and partitioned in logical compartments - essential for my sanity


As a sidenote, you may also at some point want to look at Dictionary alternatives: on Windows Zeal (free) and Velocity (free/nagware) are great alternatives to Dash for mac.
Dash is an absolutely excellent API documentation app - like the Dictionary, but orders of magnitude better - i really can't manage without it now...
What's even better is that all 3 of these apps automatically integrate with VSCode as well and you can launch documentation blazingly fast from there as well - while LiveCode ltd has done nothing to bring liveCode to Dash docsets, James Hale maintains maintains a user contributed docset that can be installed via Dash and he's also created a great stack to create your own documentation: https://livecodeshare.runrev.com/stack/ ... ke-DocSet/

I know none of this will currently appeal to you @theOtherBob, but just mentioning alternatives... you never know, it may appeal in the future or others may find the discussion useful...

[jacque]

The one objection I have with script-only stacks is that you can't use remote debugging with them, and since most of my work these days involves mobile apps that's a major drawback. On the other hand, my Mac doesn't display the slowness that Windows does, so using the native SE works well enough.

[richmond62]

Start by turning off all the options in the Edit menu you don't use. They cause slowdowns.
https://forums.livecode.com/viewtopic.p ... te#p182698
I have all of them off except for auto-bracketing.

Thank you so, so much . . . I really wish I had known about that ages ago.
-

[richmond62]

My question about external text editors for scripts relates to the
copy-past cafuffle between those and the in-built editor . . .

[stam]

My question about external text editors for scripts relates to the
copy-past cafuffle between those and the in-built editor . . .

I do not copy/paste...

I use scriptOnlyStacks (henceforth known as SOS because i'm lazy )
I edit these in VSCode and reload these as needed in LC to test.
Needs a 1-time setup to load all SOS and a handler to reload them after external editing.
As all my SOS are in one folder all my scripts (including all stack/card behaviours which will replace the stack/card scripts) all show up in the same place as project folder in VSCode.

Bit of a minor hassle for the 1-time set up to do this and still tweaking some minor bits with this system but i expect this to be transferrable to my other projects and so far works well.
Downsides are these are not binary files but text files, so in production unless you convert everything back to 'proper' stacks rather that SOS they are viewable/editable by the user. And Jacque mentioned this stops her from doing remote-debugging on mobile (not an area i've looked into). Obviously debugging isn't done in VSCode as LC have not provided integration for this (but many other IDEs have), so still use the native SE for that.

But upsides are that VSCode has so many useful features it's a joy to use (apart from syntax colouring, code formatting, linting etc - provided by FerrusLogic - its a blazing fast code editor that can display split screen multiple tabs, code-folding, dark mode etc. More importantly it has helped me properly compartmentalise my long scripts into logical MVC units so they are both smaller and easier to maintain.

As there is no full integration with external editors inevitably there is mix-and-match and i end up coding in both the native SE and VSCode, but for working on long scripts it's just much nicer using a well established, nimble and very capable code editor...