\startuserdata syntax questions
Wolfgang, Hans, et al, The new \startuserdata macro looks very promising, and can simplify some work I have in progress. The first question: the wiki example and the source use \userparameter{optionkey} \userparameter{anotherkey} to retrieve the value of optionkey and anotherkey. Is there a way to provide the key/value pairs in a manner that they can be retrieved with the getparameters mechanism, as: \getrawparameters [XX] [optionkey=,anotherkey=,#1] This has the added advantage of allowing the setting of a default value, as \getrawparameters [XX] [optionkey=2em,anotherkey=,#1] Or is there a reason not to use getparameters in this setting? The second question: Is there the possibility to enhance the syntax so that one can write \startMyStuff [optionalkey=value, anotherkey=value] stuff \stopMyStuff instead of \startuserdata [MyStuff] [optionalkey=value, anotherkey=value] stuff \stopuserdata Such syntactic sugar makes sweeter reading of the text, and makes clearer what is being done when nesting the macro. -- Rik Kabel
On 8/28/2018 10:40 PM, Rik Kabel wrote:
Wolfgang, Hans, et al,
The new \startuserdata macro looks very promising, and can simplify some work I have in progress.
The first question: the wiki example and the source use
\userparameter{optionkey} \userparameter{anotherkey}
to retrieve the value of optionkey and anotherkey. Is there a way to provide the key/value pairs in a manner that they can be retrieved with the getparameters mechanism, as:
\getrawparameters [XX] [optionkey=,anotherkey=,#1]
This has the added advantage of allowing the setting of a default value, as
\getrawparameters [XX] [optionkey=2em,anotherkey=,#1]
Or is there a reason not to use getparameters in this setting?
hardly any of the core mechanisms in mkiv uses get(raw)parameters define a category and then clone it ...
The second question: Is there the possibility to enhance the syntax so that one can write
\startMyStuff [optionalkey=value, anotherkey=value] stuff \stopMyStuff
instead of
\startuserdata [MyStuff] [optionalkey=value, anotherkey=value] stuff \stopuserdata
Such syntactic sugar makes sweeter reading of the text, and makes clearer what is being done when nesting the macro. for such Named environments there are probably other alternatives (depending on what you need it for), like blocks
also, user dat picks up its content (they're buffers) so that would also mean more nested buffers .. it's meant as a simple mechanism Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen schrieb am 29.08.18 um 09:15:
On 8/28/2018 10:40 PM, Rik Kabel wrote:
Wolfgang, Hans, et al,
The new \startuserdata macro looks very promising, and can simplify some work I have in progress.
The first question: the wiki example and the source use
\userparameter{optionkey} \userparameter{anotherkey}
to retrieve the value of optionkey and anotherkey. Is there a way to provide the key/value pairs in a manner that they can be retrieved with the getparameters mechanism, as:
\getrawparameters [XX] [optionkey=,anotherkey=,#1]
This has the added advantage of allowing the setting of a default value, as
\getrawparameters [XX] [optionkey=2em,anotherkey=,#1]
Or is there a reason not to use getparameters in this setting?
hardly any of the core mechanisms in mkiv uses get(raw)parameters
define a category and then clone it ...
\defineuserdata [rik] [name=Rik,alternative=rik] \defineuserdataalternative [rik] [renderingsetup=userdata:rik] \startsetups [userdata:rik] \starttabulate[|l|p|] \NC \userdataparameter{name} \NC \getuserdata \NC\NR \stoptabulate \stopsetups \starttext \startuserdata [rik] \samplefile{greenfield} \stopuserdata \startuserdata [rik] [name=Greenfield] \samplefile{greenfield} \stopuserdata \stoptext
The second question: Is there the possibility to enhance the syntax so that one can write
\startMyStuff [optionalkey=value, anotherkey=value] stuff \stopMyStuff
instead of
\startuserdata [MyStuff] [optionalkey=value, anotherkey=value] stuff \stopuserdata
I can generated environment commands but I haven’t done this at the beginning because I prefer to pass the name of the environment as argument because this allows me to check if the used instance exists.
Such syntactic sugar makes sweeter reading of the text, and makes clearer what is being done when nesting the macro. for such Named environments there are probably other alternatives (depending on what you need it for), like blocks
also, user dat picks up its content (they're buffers) so that would also mean more nested buffers .. it's meant as a simple mechanism
Yes, the environment is meant for short blocks of text (e.g. a blockquote) where you have to set different texts (e.g. the name of a author) for each use of the environment. I thought about adding a switch to change between buffer mode and normal start/stop commands which work like the startstop environment but it wasn’t worth the effort. Wolfgang
On 8/29/2018 11:19, Wolfgang Schuster wrote:
Hans Hagen schrieb am 29.08.18 um 09:15:
On 8/28/2018 10:40 PM, Rik Kabel wrote:
Wolfgang, Hans, et al,
The new \startuserdata macro looks very promising, and can simplify some work I have in progress.
The first question: the wiki example and the source use
\userparameter{optionkey} \userparameter{anotherkey}
to retrieve the value of optionkey and anotherkey. Is there a way to provide the key/value pairs in a manner that they can be retrieved with the getparameters mechanism, as:
\getrawparameters [XX] [optionkey=,anotherkey=,#1]
This has the added advantage of allowing the setting of a default value, as
\getrawparameters [XX] [optionkey=2em,anotherkey=,#1]
Or is there a reason not to use getparameters in this setting?
hardly any of the core mechanisms in mkiv uses get(raw)parameters
define a category and then clone it ...
\defineuserdata [rik] [name=Rik,alternative=rik]
\defineuserdataalternative [rik] [renderingsetup=userdata:rik]
\startsetups [userdata:rik] \starttabulate[|l|p|] \NC \userdataparameter{name} \NC \getuserdata \NC\NR \stoptabulate \stopsetups
\starttext
\startuserdata [rik] \samplefile{greenfield} \stopuserdata
\startuserdata [rik] [name=Greenfield] \samplefile{greenfield} \stopuserdata
\stoptext
Ahh, that does nicely to set defaults. Thank you.
The second question: Is there the possibility to enhance the syntax so that one can write
\startMyStuff [optionalkey=value, anotherkey=value] stuff \stopMyStuff
instead of
\startuserdata [MyStuff] [optionalkey=value, anotherkey=value] stuff \stopuserdata
I can generated environment commands but I haven’t done this at the beginning because I prefer to pass the name of the environment as argument because this allows me to check if the used instance exists.
Such syntactic sugar makes sweeter reading of the text, and makes clearer what is being done when nesting the macro. for such Named environments there are probably other alternatives (depending on what you need it for), like blocks
also, user dat picks up its content (they're buffers) so that would also mean more nested buffers .. it's meant as a simple mechanism
Yes, the environment is meant for short blocks of text (e.g. a blockquote) where you have to set different texts (e.g. the name of a author) for each use of the environment.
I thought about adding a switch to change between buffer mode and normal start/stop commands which work like the startstop environment but it wasn’t worth the effort.
Very well. It is what it is. The ability to set defaults goes a long way.
Wolfgang
-- Rik
On Wed, 29 Aug 2018, Wolfgang Schuster wrote:
The second question: Is there the possibility to enhance the syntax so that one can write
\startMyStuff [optionalkey=value, anotherkey=value] stuff \stopMyStuff
instead of
\startuserdata [MyStuff] [optionalkey=value, anotherkey=value] stuff \stopuserdata
I can generated environment commands but I haven’t done this at the beginning because I prefer to pass the name of the environment as argument because this allows me to check if the used instance exists.
Perhaps adding a `command=yes` key, which can be set to `no` by default. Aditya
participants (4)
-
Aditya Mahajan -
Hans Hagen -
Rik Kabel -
Wolfgang Schuster