On Sun, 14 May 2017 11:38:19 -0600, Wolfgang Schuster <schuster.wolfgang@gmail.com> wrote:

The lua tables in the scite distribution are incomplete. For example, in
scite-context-data-interfaces.lua there is no mention of the commands
for natural tables - \bTABLE etc. This is the reason for taking the
auto-generation approach, to get a comprehensive and complete list.

could be but wolfgang did a huge effort in making them pretty complete
(even low level commands) so ic something is not in there (the i-*.xml
files), it's with good reason

Sure, I was referring to scite-context-data-interfaces.lua, not the i-*.xml files..

Fortunately setup-en.pdf makes all of these concrete commands explicit: setup-en.pdf is as complete as one could ask for. But for editors the abstract commands are superfluous, as you pointed out:

the command reference is quite complete (and user defined instances
will never be part of syntax highlight anyway)

OTOH user-defined commands can be added to the ConTeXt lexer via the Style Configurator (Notepad++) and get their own highlight color. I have found this very useful in writing long documents. See attached (User-defined Keywords dialog).

Environments with custom begin/end-strings (e.g. \bTR)

<cd:command name="TR" type="environment" begin="b" end="e"
file="tabl-ntb.mkiv">
<cd:arguments>
<cd:assignments list="yes" optional="yes">
<cd:inherit name="setupTABLE"/>
</cd:assignments>
</cd:arguments>
</cd:command>

get the default start/stop string in the scite files.

Ah, "setupTABLE" is listed in scite-context-data-interfaces.lua.

Wolfgang: In that case, is there a way to generate an explicit list of all concrete commands that derive from the ["en"] class in scite-context-data-interfaces? If the results are sufficiently complete, we could distinguish high-level mkiv commands from the low-level ones. Such a list might be more beneficial for most users. Put another way, we could have

mkiv-list-high - one syntax highlighting (say, bold)
mkiv-list-low - second syntax highlighting (say, regular)

OTOH, much of this is a matter of taste: I would argue that \unprotect and \protect are high-level (as part of the meta-language used to mark off low-level code) and should therefore go into scite-context-data-interfaces (not there at present).