# [dev-context] A few questions

Fri Aug 7 11:46:27 CEST 2009

Am 06.08.2009 um 23:42 schrieb Hans Hagen:

>> 1. texdefinition
>> I like start/stoptexdefinition because it makes the source for
>> than \def allows me but is there a way to use it for macros without
>> parameters?
>
> this works
>
> \starttexdefinition test {}
> oeps
> \stoptexdefinition
>
> [\test]

not very nice and don't look pleasant to me

> we can consider something like:
>
> \starttexdefinition test optional,optional,argument,argument
> oeps
> \stoptexdefinition
>
> which then becomes
>
> \def\test[#1][#2]#3#4%
>
> etc but i'm only willing to support that if we can stick to
> reasonable definitions
>
> or even
>
> \starttexdefinition test optional:ns,argument:name
> oeps
> \stoptexdefinition
>
> which then automatically makes you a \getvariable{ns}{key} as well
> as \name
>
> or maybe like xml:
>
> \starttexdefinition test ns:optional,argument
> oeps
> \stoptexdefinition
>
> with then makes an \getvariable{ns}{first} and so
>
> needs a bit of thinking

i get the feeling we're moving towards latex3 (brr), before this
happens drop the whole
thing and i don't like \getvariable in this context anyway

>> 2. commalists
>> Together with texdefinition I use now start/stopprocesscommalist
>> (feature request: I need also
>> start/stopprocessassignmentlist) but I can use the list value
>> without the need to define a command
>> where I specify what should happen with it
>>  \startprocesscommalist[a,b,c,...]
>>  the current list value is #1\par
>>  \stopprocesscommalist
>> but why is there not something equivalent for the normal
>> processcommalist because the start/stop
>> method is not the best method when you need nested lists, something
>> like this would be nice then
>> (I know \doprocesscommalist is already defined):
>>  \doprocesscommalist[a,b,c,...]%
>>    {\processcommalist[x,y,z,...]%
>>       {do something with #1 and ##1}}
>
> hm, probably possible but not trivial (maybe not even robust) ...
> needs thinking (also a bit slower as we explicitly need a trick
> similar to the one used in dorecurse

when the inner list is used inside of a group the following works

\long\def\processcommalistwithcontent[#1]#2%
{\def\currentcommalistcommand##1{#2}%
\processcommalist[#1]\currentcommalistcommand}

\processcommalistwithcontent[a,b,c]
{{\processcommalistwithcontent[x,y,z]{This is subelement ##1 of
element #1.\par}}}

but the extra pair of braces is kind of akward. Working without them
is not the problem

\newcount\commalistdepth

\long\def\processcommalistwithcontent[#1]#2%
\long\expandafter\def\csname list:\number\commalistdepth
\endcsname##1{#2}%
\def\currentcommalistcommand{\csname list:\number\commalistdepth
\endcsname}%
\processcommalist[#1]\currentcommalistcommand

\processcommalistwithcontent[a,b,c]
{\processcommalistwithcontent[x,y,z]{This is subelement ##1 of element
#1.\par}}

but as you mentioned above some kind of check (depth counter) is needed.

>> 3. setups
>> The various start/stopsetups environments another nice feature but
>> what's the correct method when
>> I want my own setup environment, should I adapt the following line
>> from core-env to my own command
>>  \def\startsetups     {\xxstartsetups\plusone  \stopsetups     }
>> \let\stopsetups     \relax
>> and use method from lxml-ini to access/flush the content?
>
> you mean that you want to pass an argument to a setup? (mandate in
> xmlsetup)

yes, more or less what you do with xml in mkiv

\startxmlsetups ...
do this in that
\xmlflush{#1}
do more things
\stopxmlsetups

in my games module for the input for chess, go ...

\startpgnsetups move
do a few things before the move
\pgnflush{#1}
do a few things after the move
\stoppgnsetups

>> 4. Mixed assignment/comma lists
>> Are mixed lists of normal comma elements and assignments are
>> allowed by ConTeXt’s syntax because
>> there is a command in the source (\processassignlist) to process
>> the non assignment values from
>> the list? On the other side these values generate a error message
>> on the terminal where one can read
>> there is a missing '=' in the element and this message can't be
>> disabled (without hacks).
>
> yeah, a matter of choice ... we can drop the message if users don't
> mind
>
> we shouldn't end up with too many variants and personally i don't
> like the mix (i.e. foo==yes can be used)

if the context way is to avoid comma values and assignment values in
the same list the message should better remain

Wolfgang