LiveCode Forums.

Hi all,
I'm curious what proportion of people here use external code editors to edit longer scripts (probably not many I suspect), how many would like to be able to do this and how many think this is a waste of time...

As you know there are some options allowing use of external code editors such as Atom, BBEdit and VSCode (the latter is my preference) for editing of LiveCode scripts.

Other than vastly superior performance speedwise, these offer many other advantages such as high performance split screen editing (same or multiple files, horizontal or vertical), direct/automatic integration with GitHub, snippet manager integration etc, and a huge variety of code colouring schemes created for any number of languages.

Almost all options for this are free and with freely available addons, you get LiveCode syntax formatting, syntax colouring, syntax error checks/linting. The only thing you can't do is step through running code to debug.

I really like the idea of this, but wondered what others thought...

Stam

superior performance speedwise

Quite possibly: the 'only' problem is that my brain does not work 'superior performance speedwise'.

I do use VSCode - most specifically for server scripts, where debugging is a horse of a different colour to IDE development.

Without live debugging I am loathe to leave the IDE for computer app development.

I haven't really done anything for Android for ages, and never on iOS so not sure how I would view scripting for mobile. Overall I do feel most comfortable doing LiveCode work "in" LiveCode. Definitely there are dome advantages in VSCode for server work though.

(I voted option 2 "cumbersome")

SparkOut wrote: ↑

Fri Sep 16, 2022 4:02 pm

Without live debugging I am loathe to leave the IDE for computer app development.

Hey SparkOut,

Without formal integration there is no way to do live debugging outside the IDE (several IDEs for other languages do provide this type of integration, would be nice if LC would consider this with the new IDE).
But then that's not really what i had in mind anyway. I was thinking more of when writing multiple and long scripts and when working with multiple libraries.

Currently it is quite cumbersome to do outside the IDE - but there is a way around this using script-only stacks for almost everything (obviously code that can't be moved out of IDE objects has to stay in the IDE, but that can be quite short code - for buttons etc)

The reason for the poll is primarily to consider an enhancement request - eg for the new IDE which is in the works. Full integration would be wonderful.

But in the mean time i'm also working a tool (for my own use) to create a system where practically all longer scripts can be edited in for example VSCode, directly uploaded to github etc, while making the changes instantly available to the IDE - and which of course can be edited in either the iDE or externally... If there is interest I'll spruce it up for public consumption...

S.

I export all of my scripts for GitHub tracking but don’t do much of my editing outside of LC. ScriptTracker makes this easy though. It just watches the folder of scripts and updates the object script when it changes. I could edit in anything and scripts would update when saved.

I am using an editor for LC Server scripts (Sublime and sometimes Ultraedit) and sometimes i copy very large scripts from LC IDE to an external editor to do some tasks that are done faster with an external editor.
I voted for option 2 (cumbersome) as i really would prefer a much better editor.

It seems the main driver for external editors is performance with large scripts, is that correct?

I suppose the sensible thing to do now is find a common feature-set for a 'much better editor.'

I suspect that 'the main driver for external editors' is the ability to see different
parts of an enormously long script in different windows.

That is my only 'grunt' about the LiveCode script editor.

FourthWorld wrote: ↑

Sat Sep 17, 2022 10:05 am

It seems the main driver for external editors is performance with large scripts, is that correct?

Not entirely Richard, although it does matter.

For me at least, many other features like code folding, split screen editing, things like clicking on a variable instantly highlights all instances of the variable and many such very well thought out features are as important. Autoindenting, syntax colouring and syntax checking are a given.
These code editors are very mature and feature complete.

To me it makes sense to use these but ideally would be integrated with IDE so you wouldn’t have that back-and-forth, and the best code editors make such integrations very possible…

Stam

MetaCard had external editor integration but I don't think it always worked very well. For a while it was retained when LC acquired the company but was eventually discontinued.

I stay in the LC editor, partly because speed isn't an issue on my Mac, and partly because I probably don't know any better. I've turned off most of the auto-entry script options so it runs without any lag.

I am just about to fiddle around with this:

https://codingfriends.github.io/Tincta/

They don’t mention on their site which 65 languages this supports… is LC supported?

I do nearly all my Livecode coding in Sublime text using the Sublime to LC integration provided as part of the Levure framework. I also use Levure framework on nearly all my projects unless they are super-basic. Commit all code to Github repositories and uses Typora to write documentation in Markdown. For other coding I use VS Studio on a daily to weekly basis (NodeJS and frontend javascript mainly)

I appreciate the global search in Sublime allowing me to quickly search across codebase of a project. The script integration in LIvecode having to delare and import behaviour scripts into the stack and assign to objects is a bit of a pain, but more than offset by coding productivity benefits IMO.

Rodney

Re: Tincta:

1. Their website is sparse (that's a polite way of stating it contains almost no information at all).

2. I have NO idea what programming languages it, supposedly, supports:
- -
My response to that, also, being sparse:
- -
Oops: Silly Richmond should have checked a few things first:
- -
My machine is an Intel Mac Mini, but it seems the processor type is not the problem.