Bug getting group name, plse check
Kay C Lan
lan.kc.macmail at gmail.com
Sun Aug 16 22:46:47 EDT 2015
On Mon, Aug 17, 2015 at 12:04 AM, Richard Gaskin
<ambassador at fourthworld.com> wrote:
>
>
> We definitely need tagging in the Dictionary, something I'll be pushing for as we finally get the ball rolling with the Community Documentation Team soon.
>
> With searchable tags anyone can add terms that will help others find relevant tokens.
>
I appreciate this is a bit late to the game, and this Doc Team may
already be heading in a certain direction, but I'm wondering if
there's been an thought of adopting some kind of 'Industry Standard'
docset format? Admittedly I didn't know that such a thing existed
until I picked up an App called Dash as part of a bundle purchase:
https://kapeli.com/dash
I didn't buy the bundle because of this app but when I looked into it
I was very intrigued and from my limited fooling around with it I've
got to say I'm very impressed. What is clear though is that out there
there are a couple of docset standards:
Supports AppleDoc docsets
Supports Doxygen docsets
Supports CocoaDocs docsets
Supports Python / Sphinx docsets
Supports Ruby / Yard docsets
Supports Javadoc docsets
Supports Scaladoc docsets
Supports GoDoc docsets
Supports Any HTML docsets
Previously I've been of the opinion that the LC Dictionary should be a
shining example of what can be done with LC - much like the old HC
Dictionary. Unfortunately, currently it is not that. As I get older &
lazier, I'm more of the opinion that one should avoid reinventing the
wheel whenever possible.
IMO, the Doc Team should either:
1) Go for a 100% LC built Dictionary that is a shining example of it's
feature set = a lot of thought, planning and effort required.
2) Adopt a Docset format that can be used by 3rd Party Apps like Dash
and requires a simple LC Docset Viewer = far less effort.
For case 2 it would simply be a matter of the team investigating those
various docsets and determining which provides the greatest
flexibility, adaptability and feature set - a great time save as
someone else has already done the hard yards developing a schema. A LC
built Dictionary viewer would still need to be made but at least
you've saved a lot of predevelopment time and hopefully avoided all
the pitfalls some of the earlier implementations these other docsets
may have suffered. It would mean that the LC Docset and LC Docset
Viewer would not have to be created concurrently; the Docset could be
created and viewable immediately by 3rd party apps whilst the inbuilt
LC Dictionary Viewer is being worked on. I believe there might also be
a bit of a knock on effect if developers using Python/Ruby/Java
discover they can use the same Document Utility they are using to
access the LC Docset.
Just a thought.
More information about the use-livecode
mailing list