Removed text that shouldn't be seen in syntaxes

[livecodealice]

Removed (glossary) from <control(glossary)> - it was visible in the syntaxes.

[livecodepanos]

@livecode-vulcan review ok a6f7928

[livecode-vulcan]

💙 review by @livecodepanos ok a6f7928

[jameshale]

A bit confused here.
The docs tell us to add the qualifier to the lookup when there could be confusion as in <term(category)>
exists both as a glossary entry and as a keyword entry, hence <control(glossary)> to direct to the glossary entry for “control”.
The existing syntax included the angle brackets, which I left in.
The addition of (glossary) was as per the docs on the dictionary syntax.
If the (glossary) text is to be removed, shouldn’t the angle brackets be removed as well?

[livecodeali]

The qualifier only needs to be added when there are two or more of the given term in the references for that entry. So I think the correct fix here would be to add control (glossary) to the list of related entries. Where angle brackets exist with no referend in the related section, they will be stripped, hence this change prevents (glossary) from appearing, but does not fix the fact that it is not currently rendered as a link.

[livecodeali]

Ah, well ignore that because I wasn't reading the changes correctly.
Angle brackets within the Syntax: element tell the docs parser that those things are considered to be parameters which should be described in the parameters section. There is currently no way to add a general reference link in the syntax - this would be quite cool as we would be able to auto-generate common parameter types (such as control above) and prevent

Parameters:
control: A reference to a control

appearing in tons of docs entries.

What this change does then is make control appear as intended in the syntax. Warnings are emitted when compiling for any parameters in the syntax not documented in the entry, so this doesn't change anything there - previously it would have been complaining that the <control(glossary)> parameter wasn't documented.

Ultimately having it like this means that at some point we can come up with a scheme for auto-substituting param descriptions for common parameter types, rather than adding param descriptions for all such things.

[jameshale]

Ok, so <> in syntax examples are not parsed in the same way as they are elsewhere.
A note to that effect would be good in the documentation format reference.

[livecodeali]

Done: livecode/livecode#6557
Part of the problem was that in the rendered version, the fourth bullet point saying that parameters should be in angle brackets in syntax was not appearing because it wasn't in <code> blocks

[jameshale]

Thanks @livecodeali