I took the tools/documentation folder from the app bundle of LC 9.6.10 and put it into the Tools folder in the app bundle of 0.9.5.
Then I deleted
/Users/me/Library/Application Support/HyperXTalk/Documentation Cache/9_7_0_dp_1_
folder.
Then I restarted HyperXTalk 0.9.5.
The dictionary was functional but also the guide which should be removed from the documentation folder. I did not try that.
The documentation is fixed for 0.9.6 and we’ll see what to do with the Guide afterwards
The documentation should get properly copied from the application bundle to the Application Support folder. Fixed in 0.9.7
James Hale created some stacks to create and read Dash.app-compatible documentation which is incredibly helpful for use who use Dash or open source alternatives. Is this something worth thinking of?
Everybody has their own preferences, I have grown to consult solely dictionary incarnations on the web. First the one that Brian Milby put up, and as this is gone now, I mostly look at:
I guess all the content comes from a common data set, so there need not be religious wars on which tools to choose. There were many debates on this over the years in forums. As I have no deeper idea about what I’m talking about, ask @BerndN the expert. He has build the really enchanting TinyDictionary not so long ago:
The point about future dictionary work in my view would be that we have an agreed workflow to improve the content of dictionary entries in a shared effort, then all work there will have value. The content is all it is about. If you go into details, the dictionary currently is only helpful up to a certain point, the rest you often have to find out writing test code. This is why I use the afore mentioned sources, caring little about which exact version they have. The information might be a bit off a bit anyway. 
When I was using OpenXTalk, I would use the LiveCode website documentation LiveCode Script | LiveCode Documentation but with HyperXTalk, I use the built-in documentation. The documentation is stored in a SQLite database so would be easy for other tools to extract and use it in their own interface.
thanks @ToolGuy for mentioning TinyDict. I use it with HyperXTalk without any problems. It pulls its data from the SQLite database so it is always in sync with the dictionary of the current version. But of course I am biased. As a display it uses my homemade “ModTableField”.
The funny thing is that the dictionary itself doesn’t use the SQL data but rendered JS.
I also have relied on tinyDictionary for years. I’d like to see it built into HxT but there are some obstacles in the way. Primarily that the IDE launches the Dictionary stack with the line
goToEntry pLibrary, pTag, pType
and tinyDictionary doesn’t yet have an analog for this. Meanwhile tinyDictonary works fine as an HxT plugin stack.
Does it handle the on-the-fly loading of documentation from installed extensions?
Not sure what you mean by on-the-fly but yes, it handles extensions documentation.
Launch HXT, install an extension, the new documentation is loaded into the existing web based documentation. Does this happen in tinyDictionary or does it need an IDE relaunch?
TinyDict is usually installed as a plugin and I start it when the IDE loads. It then gets it information from the SQLite database. (api.sqlite)
What is not installed then is not loaded and would need a restart of HXT for newly on the fly added extensions.
I did add a feature to extract inline documentation for LCB widgets and LCS widgets on the fly to test formatting that accesses those widgets directly during development of those widgets. That does not need a restart. That works but applies only to a certain style of documentation.
Any chance of updating it so the on-the-fly loaded documentation can be put into tinyDictionary?
That should be relatively easy… the sql is updated when the extension is installed. Should just be a call to reinitialize.
What really would be best is publish/subscribe for dictionary changes. IDE would post that the dictionary was updated and any plugins subscribed would be able to adjust.
Yeah, that’s a good idea. LiveCode has a system in place for that, but they didn’t include everything.