Idris Samawi Hamid ادريس سماوي حامد <mailto:idris.ha...@colostate.edu>
14. Mai 2017 um 20:55
On Sun, 14 May 2017 12:20:43 -0600, Wolfgang Schuster <schuster.wolfg...@gmail.com> wrote:

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).

You can limit the number of custom commands when you use

     \startnamedsection[topic][title=...]

instead of

     \starttopic[title=...]

First time encountering these two commands; they're not on the wiki, need to learn more about them..

Can you explain or give a complete sample test file illustrating how they apply in the matter under discussion? Thanks.
This is only a example to demonstrate that you can create new commands
without using new command names (and the need to add them to your lexer)
in your document.

In the example below I create a new section but I don’t have to use
a new user generated command in the document itself.

\definehead[topic][subject]

\starttext

\startnamedsection[topic][title=This is a topic]
...
\stopnamedsection

\stoptext
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.
\bTABLE is also listed but Hans script includes it as \startTABLE
(because it ignores the begin/end attributes).
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).
Adding tags to the commands is planned but the question is how to
categorize them (internal, api, user level, low level, primitives,
defininitions (\define...), setups etc.).

This is good to know. At the moment we're working on a full-featured ConTeXt lexer and are experimenting with different ideas of organizing commands for user-friendly syntax highlighting. Currently considering something like the following:

TeX primitives - Knuth
luaTeX primitives - excluding Knuth
The syntax files contain at the moment only ConTeXt specific command, primitives aren’t included.
macro structure - e.g., sectioning etc.
micro structure - e.g., itemizations, tables etc.
mode structure - e.g., metapost, xml, markdown
The XML source has a category attribute for this information.
MkiV - remaining high level
MkIV - low-level [but how to separate them out?]
user-defined
Internal commands can be grouped in official helpers (which should be documented) and internal helpers (which can be hidden).
Perhaps collapse macro and micro structure into one set... Again, just ideas for now, will work this week to work them into a concrete organization for the lexer - once we generate a complete list of concrete mkiv commands.

If we can generate a complete version of the list in scite-context-data-interfaces (including \bTR etc.) then we can subtract that from the complete list of concrete mkiv commands, giving us mutually exclusive and jointly exhaustive high/low-level lists.
The source for the command list are the XML files (search for i-*.xml) and specific lists can be generated by adding metadata to the definitions.

Wolfgang
_______________________________________________
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context

Reply via email to