[dev-context] A few questions

Wolfgang Schuster schuster.wolfgang at googlemail.com
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  
>> certain macros more readable
>> 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%
     {\advance\commalistdepth\plusone
      \long\expandafter\def\csname list:\number\commalistdepth 
\endcsname##1{#2}%
      \def\currentcommalistcommand{\csname list:\number\commalistdepth 
\endcsname}%
      \processcommalist[#1]\currentcommalistcommand
      \advance\commalistdepth\minusone}

   \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



More information about the dev-context mailing list