DASH docset updated to LC 10 dp4 what yoy

[mtalluto]

You will find it in the stack "revseutilities"

Thank you, Mark. In hindsight the name makes sense, and knowing what it is makes it easy to look for. I'd tried tracing the call chain, but I'm guessing that function is a callback from _intetnal, or did I miss where it's called from script?

It has been so long since I worked on that feature for our Dev Tools. If there was no prominent call to the handler, I bet it is coming from the engine. If you make a front script, it will undoubtedly get your updated version of the colors you like.

[mwieder]

Bernd turned me onto the internal colorization routines a while back, and they're incorporated into the glx2 script editor, fwiw.
I find it unfortunate that they're pretty rigidly constrained, though. While you can set custom colors for the different classes/groups/keywords, you can't add to or change the list of classes etc.

[mtalluto]

Bernd turned me onto the internal colorization routines a while back, and they're incorporated into the glx2 script editor, fwiw.
I find it unfortunate that they're pretty rigidly constrained, though. While you can set custom colors for the different classes/groups/keywords, you can't add to or change the list of classes etc.

The GLX script editor has amazing color control. Back in the day, Jerry added the chalkboard mode per my request.

[FourthWorld]

The GLX script editor has amazing color control. Back in the day, Jerry added the chalkboard mode per my request.

Chalkboard mode?

[mwieder]

Chalkboard mode.

CodeFolding.png (21.74 KiB) Viewed 4729 times

[mtalluto]

The GLX script editor has amazing color control. Back in the day, Jerry added the chalkboard mode per my request.

Chalkboard mode?

It was dark mode before dark mode became a thing. We were ahead of our time.

[rodneyt]

DASH is a documentation/snippet manger details can be found -> https://kapeli.com/dash
DASH allows user contributed documentation sets (docsets) and I provide one for LC.
i also have a stack in the user stacks section (available from the help menu in LC’s IDE) which constructs the LC docset.

James - thank you - this Dash documentation set is a great addition. It's easier to switch to another app to search docs than use the Rev API docs in Livecode. As I am SetApp subscriber I have the Dash app available, so this was a no-brainer.

I wonder whether having a community driven snippets collection (extracted from these discussions and elsewhere) to complement the docs would be useful (perhaps this is already done), so you could have the official docs + the community learnings associated with keywords.... Just a musing.

[stam]

Community driven snippets is a great idea, but don't think this can be supported with Dash - i'm not entirely sure but think these are stored in a local SQLite database.

Not sure it's realistic to that someone takes on curating a website for these... But maybe something like Gist would be do the job?

[FourthWorld]

Community driven snippets is a great idea, but don't think this can be supported with Dash - i'm not entirely sure but think these are stored in a local SQLite database.

Not sure it's realistic to that someone takes on curating a website for these... But maybe something like Gist would be do the job?

I think that's the best approach for now.

It's easy to dream of ideal tooling, but to make that actionable requires an amortization of sorts across the user base. Everything costs time; even free dev services require some ability to demonstrate some form of ROI to be sustainable.

Besides, one of the changes to the business environment over the years has been the plethora of specialized tooling.

For the segment of experienced pro devs, integration with existing tools has displaced much of yesteryear's custom development.

If Gist can do the job, kinda hard to go wrong with that.

True, something natively LiveCode that integrates more directly in the IDE would be ideal for less experienced segments. But a certain baseline needs to be in place for such an undertaking to be sustainable.

For now, use what's available, get at least good results today, and later on the question of supercool results can be revisited as opportunity permits.

[jameshale]

I haven’t used the snippet feature much. I think I added a switch and if-then-else snippet at one time but I tend to use the auto complete of the IDE now.
What I do use are the plugins to other apps.
BBedit, sublime etc which gives me access to the dictionary when I am using them for scripting.
And for Mac users the popclip plugin works a treat no matter what you are writing in.
I share Richards concern that curating community snippets would be a big job.
BTW if you have installed other widgets, and they a documented within the lcb file, as is recommended, the make docset stack should be able to extract their documentation.

[stam]

True, something natively LiveCode that integrates more directly in the IDE would be ideal for less experienced segments. But a certain baseline needs to be in place for such an undertaking to be sustainable.

Agree completely and that was my point - a workable solution would need not only sharing but a way to document, fork, raise issues etc - something you get for free with Gist/GitHub and requires no curation or funding. I'll probably start putting things on Gist with the term 'livecodescript' in the title so should show up on searching, but be super-cool if other did as well...


As a side-note:
The value of shared snippets increases significantly if the IDE supports using these, which I don't think LC really does.

My personal preference at present is to use VSCode for coding larger projects - as much as the SE in LC is an impressive tool, it comes nowhere near 'proper' code editors like VSCode. Sadly there is no direct integration with LC so you can't debug/step through running code in it, but you can do everything else.
I haven't yet explored Gist integration with VSCode but expect this to be good...

I use VSCode by abstracting as much as possible to script-only stacks, which can be loaded as behaviours for stacks/cards (in place of stack/card scripts), libraries and backscripts. SO stacks are just text files eminently suited for editing in VSCode and thanks to the add-on by FerrusLogic, you get both liveCode syntax colouring, code formatting and syntax checking/linting in VSCode.

This works very nicely but with one caveat - the LC IDE doesn't automatically reload the SO Stack if saved externally, so requires the dev to do this.
I'm nearly done with an tool that does this automatically for all the numerous SO stacks in various roles in my project and have abstracted it to be generalisable across my projects. I'm happy to share this if there is interest...

[mwieder]

Stam-

Very interested. A while back I worked out a mechanism for automatically importing script-only stacks as substacks but got bogged down in automatically exporting changes back to the .livecodescript files. Haven't revisted that in some time now. So if you've got something workable and generic then yes, I've got a use for it.

[stam]

Stam-

Very interested. A while back I worked out a mechanism for automatically importing script-only stacks as substacks but got bogged down in automatically exporting changes back to the .livecodescript files. Haven't revisted that in some time now. So if you've got something workable and generic then yes, I've got a use for it.

Sure - there's a few more things to fine tune on my end and i'll post it, probably in a new thread - my actual job and free time permitting... In any case, feedback is always good.

This is a sidetrack i fell into while working on a much larger app, after FerrusLogic released their add-on that allowed me to edit scripts in VSCode and made me keen to use VSCode for as much as possible... It's just taken a lot more time than i expected

This solution of course heavily influenced by my needs and may not fit your use-case - i don't for example import *any* SO stacks as substacks, i either set the SO stack to be behaviour for card or stack, or 'start using' it as a library, or 'insert it into back' so the handlers are always accessible from anywhere. I expect this will be using at least 20 SO stacks, if not more, in my 'main' app and having to hand code the load/unload handlers would be cumbersome to maintain otherwise (as i discovered after my initial attempts at this technique...)

Anticipating i would forget 50% of what i've done in a year or two i've added some in-app documentation for myself, but can polish it up as well so it's readable by human beings (this was also a opportunity to create my own version of an 'accordion' control, another sidetrack )

The main issue for now is: i created this with the new polyList and powerButton widgets (mainly to test these - and i do like them), so to run this as is, you'd either need these widgets installed or i could build this as a standalone...

The stack does 3 things: It creates a 'paths' SO stack that returns the correct locations for SO stacks depending on whether in IDE (all in one folder, or subfolders of this one folder) or standalone (read-only or writeable locations), and then creates a couple of scripts to load and unload these using data from the 'paths' stack (to be pasted into the main stack's script)

The load/unload scripts generated mean that i can with one call load all stacks immediately (eg at startup) and running unload/load scripts allow me to reload all scripts pretty much instantly after editing externally.
If SO stacks change (new files, different names etc), I just generate new scripts (hand-coding these gets very tedious very quickly).
I envisioned this to work as a plugin (eventually), but no reason really why this couldn't work as a standalone...

On the other hand the underlying code can take datagrids with no change, i could just put a datagrid and normal buttons in instead of polyList/powerbuttons...

I haven't looked into it, but presume there's a straightforward way to check for presence of a specific extension like polyList; i could just add some cards with datagrid as well and have it automatically switch depending on whether people have polyList... (a bit more work on my end!)

S.

[bwmilby]

Stam-

Very interested. A while back I worked out a mechanism for automatically importing script-only stacks as substacks but got bogged down in automatically exporting changes back to the .livecodescript files. Haven't revisted that in some time now. So if you've got something workable and generic then yes, I've got a use for it.

A while back I wrote a stack to “descriptify” Navigator. I created a single substack and imported each script as a button and reassigned the behavior. I can’t recall if I properly handled nested behaviors, but could check that. Then I would just use ScriptTracker to export the scripts for external editing. ST watches a folder and when a file changes it imports that script back into the stack.

[stam]

Hi stam,

The function I use:

Code: Select all

 function colorscript ptoken
   --use SE utils to colorise syntax
   --ptoken is the syntax to colorise
   -- color field -> fld "fToColor"
   
   local thtml
   put ptoken into fld "fToColor"
   _internal script colorize char 1 to (the number of chars in field "fToColor") of field "fToColor"
   --now need to convert the html to use css
   put the htmltext of fld "fToColor" into thtml
   --return thtml
   --from the IDE
   replace "<font color=" & quote & "#000000" & quote & ">" with "<span class=" & quote & "normal" & quote & ">" in thtml
   replace "<font color=" & quote & "#7F7F00" & quote & ">" with "<span class=" & quote & "command" & quote & ">" in thtml
   replace "<font color=" & quote & "#007F7F" & quote & ">" with "<span class=" & quote & "property" & quote & ">" in thtml
   replace "<font color=" & quote & "#007F00" & quote & ">" with "<span class=" & quote & "comment" & quote & ">" in thtml
   replace "<font color=" & quote & "#7F007F" & quote & ">" with "<span class=" & quote & "function" & quote & ">" in thtml
   replace "<font color=" & quote & "#7F007F" & quote & ">" with "<span class=" & quote & "keyword" & quote & ">" in thtml
   replace "<font color=" & quote & "#00007F" & quote & ">" with "<span class=" & quote & "normal" & quote & ">" in thtml
   replace "</font>" with "</span>" in thtml
   
   --return colorised text
   return thtml
end colorscript

Hi James, thank you for sharing this!
I thought i could use your colorScript function to set the htmlText of a field, but although it did style the text of that field, it seems setting the htmlText doesn't cater for colours :-/

In the end it was simplest just to use:

Code: Select all

_internal script colorize char 1 to (the number of chars in field "<fieldTolColorise>") of field "<fieldTolColorise>"

That certainly works for what i need it for - thank you once again!
Stam