On Sun, 14 May 2017 11:38:19 -0600, Wolfgang Schuster
<[email protected]> 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).
Idris
--
Idris Samawi Hamid, Professor
Department of Philosophy
Colorado State University
Fort Collins, CO 80512
_______________________________________________
dev-context mailing list
[email protected]
https://mailman.ntg.nl/mailman/listinfo/dev-context
