External Script Editor

[richmond62]

Stumbled on this:

https://www.sonsothunder.com/devres/liv ... Editor.htm

The BBEdit thing might still work . . .

[OpenXTalkPaul]

I think it’s a fantastic idea to facilitate external Script editing. I’ve read somewhere that the OXT ancestor Metacard originally had no script editor at all (used emacs ). And at least in MC v2.2, it still allowed external editing, while also having it’s own script editor built into its IDE. I know this is still possible. I’ve mention previously in these forums that there are hooks for that (plus other things like auto-complete) in the IDE libraries scripts.

DD1A3F8D-8F12-4092-BCA4-C013FD5073EC.jpeg (404.07 KiB) Viewed 1429 times

[OpenXTalkPaul]

Notice that the MC script editor window had its own menus that appear to be “menuStack” Mode (Stacks used as custom menus) custom menus. And they’re set up so that one can navigate them and make a selection using the arrow keys on your keyboard.

F4E85167-9198-42B6-97F3-AEF852307010.jpeg (760.91 KiB) Viewed 1424 times

1) was ‘option’ ever used as a command. Perhaps that’s a mistakenly put into that category?
2) what’s the ‘place’ command? I’ve never used that before.

Also notice that there’s a nice helpful window listing stack properties to the right.

To get back on topic external editors, there can be lots of advantages, beyond most code editors having some sort of autocomplete, which might not be so obvious. Like some code editors facilitate actually running or compiling code, particularly if there’s a REPL loop command line thing for a language, I believe Ferris Logic guys we’re doing something to that effect with VSCode using lc-compile directly for extension builder stuff, and lc engine in no-GUI mode, or the server engine, to evaluate xTalk script within VSCode.

[tperry2x]

So the inevitable question is: what is the required / recommended way to convince the IDE to use an external program to handle the editing of scripts (across all platforms, not just MacOS)?

[OpenXTalkPaul]

So the inevitable question is: what is the required / recommended way to convince the IDE to use an external program to handle the editing of scripts (across all platforms, not just MacOS)?

I would think that however MetaCard did that is likely the best way to do it.
But I can imagine how it could work in a way similar to the way you can edit stack-embedded pixel image data in an external image editor. The formula is:
1) In the temp directory it create a temp file of the image data of the selected image
2) then it launches that temp file in your (revPreferences) selected image editor while presenting a dialog asking to update the image.
3) you edit this temp image and save it then when you return to the IDE you select update from the dialog and it swaps the edited temp version pixels into your selected image control.

For a script it would do the same but with a file like 'temp12343531234234.xtscript' and the contents of that file would replace the script of the selectedObject and recompile the script upon returning to the IDE.

[tperry2x]

1) In the temp directory it create a temp file of the image data of the selected image
2) then it launches that temp file in your (revPreferences) selected image editor while presenting a dialog asking to update the image.
3) you edit this temp image and save it then when you return to the IDE you select update from the dialog and it swaps the edited temp version pixels into your selected image control.

For a script it would do the same but with a file like 'temp12343531234234.xtscript' and the contents of that file would replace the script of the selectedObject and recompile the script upon returning to the IDE.

I assume as a side-effect, that the entire IDE would be effectively locked (effectively non-responsive) whilst waiting on the external editor to be saved and closed, then would update itself.

[axwald]

Hi,

found both commands in the 6.7.10 dictionary. 9.6.3 still has them:

1) was ‘option’ ever used as a command. Perhaps that’s a mistakenly put into that category?

"Use the option command to display a stack menu as an option menu in situations where it is not possible to attach the menu to a button (for example, if the contents of the menu are not known in advance)."

2) what’s the ‘place’ command? I’ve never used that before.

"Adds an existing group of objects to a card and sets the sharedBehavior property to true."

Have fun!

[axwald]

Hi,

I assume as a side-effect, that the entire IDE would be effectively locked (effectively non-responsive) whilst waiting on the external editor to be saved and closed, then would update itself.

Why? It's not much different to having a script open in new script editor window, right?
Could look like this (red):

Screen.png (14.05 KiB) Viewed 1161 times

When activated, OXT removes the editor tab, writes the contents to a temp file & calls the selected ext. editor with this file. And keeps a handle on the file & checks periodically (esp. on resume) if it has changed. If yes, it asks & updates the object.

When editing LC server scripts with Filezilla & EditPad this works like a charm already. Filezilla asks "what to do?" as soon as the shared file has been saved, and EditPad even recognizes when the file has only been changed (but not saved yet) by something else. And offers functional help.

Would be a cool thing anyways, _always_ having a file version of an edited script in a selectable folder, updated with each "apply". This way "file history" could make backups, and an IDE going haywire, clandestinely modifying your script & then crashing would be less disastrous ...

Have fun!

[richmond62]

Have fun!

I am not entirely convinced Tom is 'having fun' right now, and that 'having fun' was being used by some other people while they were successfully pulling the wool over our eyes about an Open Source version being present 'for ever', and sliding out of promises made during some fund-raisers.

Personally I think we should ban that phrase; and, even, possibly, replace it with something like "How's your headache?"

[axwald]

Personally I think we should ban that phrase; and, even, possibly, replace it with something like [...]

This reminds me of something:

Once upon a time, on a beautiful, sunny morning, an evil person looked up and mentioned "The sky is blue today!" to its minions, before beginning its day's evil work.

Now good citizens faced a dilemma, especially on beautiful, sunny mornings - would they really want to repeat the utterances of this evil person? Wouldn't such speech act mean they were condoning that evil person's evil deeds?

Thus the Ministry of Righteousness ("miniRight") has decreed that, under threat of social ostracization, the following changes are to be made in general language usage:
- That which is above us, and is blue on a beautiful, sunny morning (previously denoted with the "s" word) shall from now on be referred to as "grass".
- The color of the grass (see above) on a beautiful, sunny morning (previously denoted by the "b" word) shall from now on be referred to as "brown".

May your grass always be brown!

Disclaimer: What I write is what I mean. What whoever has said/ written/ thought/ hallucinated wherever whenever, outside the context, it doesn't matter.
I used my "greeting/ well wishing line" already before the "internet as we know it" was invented, and I'll not stop using it only because some punk stole it once, and used it in an objectionable way.

End offTopic

[richmond62]

Wow!

There was an element of teasing in my post, as well as a dig at some naughty people.

At University, studying Philosophy, I learnt that some grass was 'grue'.

[richmond62]

Of course Tom may understand what is objectionable about

select a pikey

[tperry2x]

Yes, that is indeed one of the many offensive names for a group of romany travellers.
I steer clear of "Pigeonholing" people into certain groups. Even down to "Emos", "Millenials" or "Gen-Z" - because no two people are alike, and to make sweeping judgements about anyone before you know them is (at best an incorrect assumption) - at worst, it just makes the "pigeonholer" come across as the one who should crawl back under their rock.

Some people see that as a "Woke" attitude - I don't subscribe to that either, or any of this woke terminology. Just don't assume anything of anybody until proven (good or bad, one way or the other). If not being an a-hole about certain groups of people is being 'woke', then I guess I am "woke" - or at least I'm awake.

The same reasoning that the old saying "clothes maketh the man". Which is also BS - you can put a monkey in a suit. Doesn't make them any more intelligent. The most qualified person in the building might be wearing jeans and a scrappy old tshirt. How they dress, their appearance, has absolutely nothing to do with what they might have going on upstairs.

[tperry2x]

When activated, OXT removes the editor tab, writes the contents to a temp file & calls the selected ext. editor with this file. And keeps a handle on the file & checks periodically (esp. on resume) if it has changed. If yes, it asks & updates the object.

Yes, I use Filezilla and the approach works well. It's aware of edits, because it continuously checks if the file has been modified. Where it falls down is if you save a couple of times. In the meantime, filezilla (or our IDE) spots the first save, and updated the script of the object you were editing. If you left your text editor window open and carry on editing, subsequent changes aren't picked up on. Filezilla has that problem too.

Would be a cool thing anyways, _always_ having a file version of an edited script in a selectable folder, updated with each "apply". This way "file history" could make backups, and an IDE going haywire, clandestinely modifying your script & then crashing would be less disastrous ...

Yes, I totally agree - and would love to add it. There's a heck of a lot that would need to be changed, because as default - it always seems to want to use the SETemplate stack - and weaning it off that seems to be quite hard.

The other approach I was pondering was to write to the user's /tmp directory (okay, it's not as simple on Windows or especially MacOS) but these temporary directories exist. They get wiped out at OS boot time, so in theory the edits can sit in there and be checked for (multiple) edits from external script editors. I just wondered if anyone knew how to do it already, rather than me reinventing the wheel. And rather than me having to dig through legacy metacard scripting.

No problem though, I'll make this a future option in the preferences, where you select an external script editor application. Of course, it'll be cross-platform - no good making it just for MacOS or Linux - it has to work on Linux, Windows and MacOS.

[richmond62]

That's funny, I thought it was "manners maketh man", which is also @#£%^&.

[tperry2x]

That's funny, I thought it was "manners maketh man", which is also @#£%^&.

It probably was that originally, but got ditched because nobody seems to have any manners. You could be the most approachable and agreeable person, but you put your elbows on the dinner table. For some, that's completely objectionable and shows a huge lack of manners. Likewise, you could be full of dinner-table-manners, but could be a total github.

[axwald]

Hi,

[...] Filezilla has that problem too. [...]

Hmmm. Test:
- Using Filezilla, I create an empty file on the server, then "view/ edit". It opens in EditPad.
- I write "one" to it, and save. Filezilla pops its window "Upload this file back ..."
- I ignore the window, write "two" to the file & save again. Then I click "OK" in Filezillas window.
- File content on server: "two".

So it actually transfers the temp file in the state it is when you say "OK". There was a problem with this functionality some months ago, may be that there was a change during this.

Yes, I totally agree - and would love to add it. There's a heck of a lot that would need to be changed, because as default - it always seems to want to use the SETemplate stack - and weaning it off that seems to be quite hard.

Be careful, this smells like a road to madness ;-) The way the IDE is scripted gives me the creeps, already in v6. In v9 it's much worse even - guess it's the reason for the new "Create": They don't find any devs anymore capable to handle this mess ...

The other approach I was pondering was to write to the user's /tmp directory [...]

Would you want to have file versioning for one of the standard temp folders? Me not.
I'd rather think: This is a feature for experienced devs that know what they do - after all it comes with a certain overhead, thus may be "off" by default. To really have a use the dev may need to designate a special folder for it, and turn it on.

But there's more to it: You want to have one file for each script affected (or one per stack), how to name it? Since we have no unique identifiers for a stack we need the filePath. But a path doesn't work well in a filename, so we have to replace the delimiters, and we need to find chars that can be used in a filename, but aren't yet ... Best guess would be to have a sqlite (or CSV) in this folder that translates filenames (maybe "stackName" & "_" & UUID()) to the actual filePaths. Sounds like a major headache.

I could imagine hooking into the "apply" mechanism, probably "save" too, and just adding an additional command call. When called, the new code would grab the contents of the current editor tab, check where its file is, and overwrite it. The OS does whats left, according to the devs settings for "file history", shadow copy or whatelse. As I'm thinking of it, I may actually try it in my trusty v6 ;-)

No problem though, I'll make this a future option in the preferences, where you select an external script editor application. Of course, it'll be cross-platform - no good making it just for MacOS or Linux - it has to work on Linux, Windows and MacOS.

Making it work for Win should be comparable easy: There's only one flavor and very few active versions of it, and these are maintained for a quite long time. MS is very consistent as long as you follow their guidelines, keeps its backward compatibility for insane time spans, and only rarely disrupts its devs.

May your grass always be brown! ;-))

[tperry2x]

I agree wholeheartedly with 99% of this. All apart from the SQLite bit - I'll steer clear of attempting to handle SQLite databases in the LCC engine entirely, at all costs.
I'll have a ponder - like you said, it may be best to allow the user to select a location for temporary script file edits. Probably in the same prefs screen where they choose their external editor.

I know what you mean about LCC9 engine. I'd have loved to base OXT on the LCC7 engine instead. Unicode be damned. It's so so much faster than 9 will ever be. Why did LC make a 64-bit version of the v7 engine for Linux, and not do a 64-bit version until v8 on the Mac?

[richmond62]

Unicode be damned.

Ouch: I am largely dependent on Unicode outside daft games for Christmas and the stuff for my EFL school.

[tperry2x]

I'm not likely to go back to a LCC7 engine though, having done as much work as I have on the IDE in the LCC9 engine. It doesn't all translate to an earlier version of the LCC engine directly. (Aside from the retro edition when I revisit that again at some point), but even that is based on 8.2.0-dp2 of the LCC engine.