From: Rik Kabel <context@rik.users.panix.com>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: \startuserdata syntax questions
Date: Wed, 29 Aug 2018 12:56:15 -0400 [thread overview]
Message-ID: <74c9b873-3e27-c55e-b792-baf138576296@rik.users.panix.com> (raw)
In-Reply-To: <80fca181-ee5e-a059-622e-645a9c69b572@gmail.com>
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
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
next prev parent reply other threads:[~2018-08-29 16:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-28 20:40 Rik Kabel
2018-08-29 7:15 ` Hans Hagen
2018-08-29 15:19 ` Wolfgang Schuster
2018-08-29 16:56 ` Rik Kabel [this message]
2018-08-29 17:29 ` Aditya Mahajan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74c9b873-3e27-c55e-b792-baf138576296@rik.users.panix.com \
--to=context@rik.users.panix.com \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).