Volunteer github guru for documentation submissions?

[Kay C Lan]

On Tue, Apr 12, 2016 at 10:31 AM, J. Landman Gay <jacque at hyperactivesw.com>
wrote:

>
> I think it says "object" should only be used for glossary entries:
>
> No that is not what it's saying. You will find that there are 3 separate
lcdocs relating to fields: keyword, object and glossary - you can tell from
the URL without clicking on them.

https://github.com/lan-kc/livecode/blob/develop/docs/glossary/f/field.lcdoc

https://github.com/lan-kc/livecode/blob/develop/docs/dictionary/keyword/field.lcdoc

https://github.com/lan-kc/livecode/blob/develop/docs/dictionary/object/field.lcdoc

Where this becomes important is that within the 'body' of the text if you
use the word 'field' and you are going to link it to another lcdoc you need
to know what context it is in so that in the Reference section of the lcdoc
you have the correct link: field (glossary). More importantly, if in the
'body' you refer to a field generically, so - field (glossary) and then as
an object, so field (object) link, and then again you refer to creating a
field, and therefore the use of field as a keyword, then you also need a
field (keyword) link. BUT THESE THREE need to be made unambiguous with the
way you <> the links in the 'body' so that each link will point to the
correct lcdoc

This entry is with the LiveCode Documentation Format Reference refers:

If the target name is shared by two references, then the link should be
> disambiguated by including the type in brackets:
> We might want to link to the <other(function)> function and the
> <other(command)> command in the same entry, if the references contain
> "other (function)" and "other (command)".


AND THEN MUST in the reference section have:

References: field (glossary), field (keyword), field (object) ... etc to
other links

HTH