The visual counter module

The visual counter module

[Aditya Mahajan]

Hi,

This is to announce an alpha release of the visual counter module. See 
http://randomdeterminism.wordpress.com/2010/11/14/visualcounter-module/ 
for some examples, in particular 
http://randomdeterminism.files.wordpress.com/2010/11/theorem.pdf

The idea is to display a counter visually, in the same spirit as 
interactions bars. There is no support for interaction, but, on the plus 
sides, these work for any conter, not just the page counter. The idea of 
the module comes from the counters designed by Thomas as part of the 
simpleslides module.

The module only works with MkIV because I am using the new namespace 
code. So MkII support is unlikely.

Anyone else interested in such counters?

Aditya
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: The visual counter module

[Hans Hagen]

On 15-11-2010 12:16, Aditya Mahajan wrote:
> Hi,
>
> This is to announce an alpha release of the visual counter module. See
> http://randomdeterminism.wordpress.com/2010/11/14/visualcounter-module/
> for some examples, in particular
> http://randomdeterminism.files.wordpress.com/2010/11/theorem.pdf
>
> The idea is to display a counter visually, in the same spirit as
> interactions bars. There is no support for interaction, but, on the plus
> sides, these work for any conter, not just the page counter. The idea of
> the module comes from the counters designed by Thomas as part of the
> simpleslides module.
>
> The module only works with MkIV because I am using the new namespace
> code. So MkII support is unlikely.
>
> Anyone else interested in such counters?

fun!

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: The visual counter module

[Mathieu Boespflug]

Awesome! I'm sure this will come in handy one day.

-- Mathieu


On Mon, Nov 15, 2010 at 12:16 AM, Aditya Mahajan <adityam@umich.edu> wrote:
> Hi,
>
> This is to announce an alpha release of the visual counter module. See
> http://randomdeterminism.wordpress.com/2010/11/14/visualcounter-module/ for
> some examples, in particular
> http://randomdeterminism.files.wordpress.com/2010/11/theorem.pdf
>
> The idea is to display a counter visually, in the same spirit as
> interactions bars. There is no support for interaction, but, on the plus
> sides, these work for any conter, not just the page counter. The idea of the
> module comes from the counters designed by Thomas as part of the
> simpleslides module.
>
> The module only works with MkIV because I am using the new namespace code.
> So MkII support is unlikely.
>
> Anyone else interested in such counters?
>
> Aditya
> ___________________________________________________________________________________
> 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://tex.aanhet.net
> archive  : http://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________
>
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: The visual counter module

[Philipp Gesang]

[-- Attachment #1.1: Type: text/plain, Size: 1191 bytes --]

On 2010-11-14 <18:16:05>, Aditya Mahajan wrote:

<snip/>

> The module only works with MkIV because I am using the new namespace
> code. So MkII support is unlikely.

Hi Aditya,

you seem to be familiar with some of the features of the new
namespace model that I was not able to infer from Wolfgang’s
code. Could you please comment on what the keys ‘setup’, ‘type’,
and ‘command’ in ‘\definenamespace’ accomplish?

Thanks in advance, Philipp


> 
> Anyone else interested in such counters?

PS: Great idea!


> 
> Aditya
> ___________________________________________________________________________________
> 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://tex.aanhet.net
> archive  : http://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

\definenamespace (was: The visual counter module)

[Wolfgang Schuster]

Am 17.11.2010 um 20:10 schrieb Philipp Gesang:

> Hi Aditya,
> 
> you seem to be familiar with some of the features of the new
> namespace model that I was not able to infer from Wolfgang’s
> code. Could you please comment on what the keys ‘setup’, ‘type’,
> and ‘command’ in ‘\definenamespace’ accomplish?

I’m not Aditya but i hope you will also accept my explanation.

I will start with the first argument and the „type“ key, e.g.

   \definenamespace
     [fancybreak]
     [type=module]

will produce the namespace „@@@@fancybreak“ with the short form
(the name itself has the same length but for TeX it’s only a single
tokens instead of many with the @@@@... form) \????fancybreak.

The is currently only one argument with the name „module“ but
another one like „core“ or „base“ can appear in the future but
this will be then reserved for Hans to replace the \definesystemvariable
command from the core to produce a namespace in the form „@@xx“.

When you define a namespace you should use three or more letters
because two letter namespaces are reserved for Hans itself,
e.g. is already used by the database module.


The second key you need is „name“ because it’s argument is used
when all the „\setup...“ and „\define...“ commands are created.


The key „style“ creates the command „\doset<NAME>attributes“ which
takes two arguments where the first is to change the style (font)
in your new created command and the second for the color.

The setup

   \definenamespace
     [fancybreak]
     [type=module,
      name=fancybreak,
      style=yes]

creates the command \dosetfancybreakattributes which can be used like
\dosetfancybreakattributes\c!style\c!color and will take the „style“
and „color“ argument from the \setupfancybreak command.


The setup key creates the command „\setup<NAME>“ where you can control
whether the commands accepts a list of environment in the two argument
form or only a single environment, e.g. „setup=yes“ let you write

   \setupfancybreak[one][..,..=..,..]

and

   \setupfancybreak[..,..=..,..]

while „setup=list“ let you use

   \setupfancybreak[one,two][..,..=..,..]

and

   \setupfancybreak[..,..=..,..]


The key “command“ creates a bunch of macros, besides the „\define...“
commands to create new environment and commands with your code it creates
the following macros to access the values from your setup commands:

   - \<Name>parameter
   - \named<NAME>parameter
   - \detokenized<NAME>parameter

The command key has like the setup key the two values yes and list,
with „command=yes“ you can write

   \define<NAME>[one][..,..=..,..]

or (clone a setup like \definehead[mysection][section])

   \define<NAME>[two][one]

while „command=list“ allows

    \define<NAME>[one,two][..,..=..,..]

or

   \define<NAME>[two,three][one]


For parent it’s the best to give as argument always the same value
as you defined for the namespace, e.g. for the fancybreak module
one should write „parent=fancybreak“.

Wolfgang

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace (was: The visual counter module)

[Philipp Gesang]

[-- Attachment #1.1: Type: text/plain, Size: 4708 bytes --]

On 2010-11-17 <22:53:20>, Wolfgang Schuster wrote:
> 
> Am 17.11.2010 um 20:10 schrieb Philipp Gesang:
> 
> > Hi Aditya,
> > 
> > you seem to be familiar with some of the features of the new
> > namespace model that I was not able to infer from Wolfgang’s
> > code. Could you please comment on what the keys ‘setup’, ‘type’,
> > and ‘command’ in ‘\definenamespace’ accomplish?
> 
> I’m not Aditya but i hope you will also accept my explanation.

Hi Wolfgang,

of course you are always welcome to deliver this kind of
thorough discussion! The wiki is grateful …

Just two keys remain unexplained: “version” and “comment”. I
guess they are not as critical but for sake of completeness and
out of curiosity I wouldn’t mind having my guesses refuted or
confirmed:

comment -  string: non-functional information that will be
           stored along with the namespace?? 
version -  number: versioning information?? Functionality not
           yet known.

Many thanks anyways, rewriting some module code will make
christmas _much_ more interesting.

Philipp



> I will start with the first argument and the „type“ key, e.g.
> 
>    \definenamespace
>      [fancybreak]
>      [type=module]
> 
> will produce the namespace „@@@@fancybreak“ with the short form
> (the name itself has the same length but for TeX it’s only a single
> tokens instead of many with the @@@@... form) \????fancybreak.
> 
> The is currently only one argument with the name „module“ but
> another one like „core“ or „base“ can appear in the future but
> this will be then reserved for Hans to replace the \definesystemvariable
> command from the core to produce a namespace in the form „@@xx“.
> 
> When you define a namespace you should use three or more letters
> because two letter namespaces are reserved for Hans itself,
> e.g. is already used by the database module.
> 
> 
> The second key you need is „name“ because it’s argument is used
> when all the „\setup...“ and „\define...“ commands are created.
> 
> 
> The key „style“ creates the command „\doset<NAME>attributes“ which
> takes two arguments where the first is to change the style (font)
> in your new created command and the second for the color.
> 
> The setup
> 
>    \definenamespace
>      [fancybreak]
>      [type=module,
>       name=fancybreak,
>       style=yes]
> 
> creates the command \dosetfancybreakattributes which can be used like
> \dosetfancybreakattributes\c!style\c!color and will take the „style“
> and „color“ argument from the \setupfancybreak command.
> 
> 
> The setup key creates the command „\setup<NAME>“ where you can control
> whether the commands accepts a list of environment in the two argument
> form or only a single environment, e.g. „setup=yes“ let you write
> 
>    \setupfancybreak[one][..,..=..,..]
> 
> and
> 
>    \setupfancybreak[..,..=..,..]
> 
> while „setup=list“ let you use
> 
>    \setupfancybreak[one,two][..,..=..,..]
> 
> and
> 
>    \setupfancybreak[..,..=..,..]
> 
> 
> The key “command“ creates a bunch of macros, besides the „\define...“
> commands to create new environment and commands with your code it creates
> the following macros to access the values from your setup commands:
> 
>    - \<Name>parameter
>    - \named<NAME>parameter
>    - \detokenized<NAME>parameter
> 
> The command key has like the setup key the two values yes and list,
> with „command=yes“ you can write
> 
>    \define<NAME>[one][..,..=..,..]
> 
> or (clone a setup like \definehead[mysection][section])
> 
>    \define<NAME>[two][one]
> 
> while „command=list“ allows
> 
>     \define<NAME>[one,two][..,..=..,..]
> 
> or
> 
>    \define<NAME>[two,three][one]
> 
> 
> For parent it’s the best to give as argument always the same value
> as you defined for the namespace, e.g. for the fancybreak module
> one should write „parent=fancybreak“.
> 
> Wolfgang
> 
> ___________________________________________________________________________________
> 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://tex.aanhet.net
> archive  : http://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace (was: The visual counter module)

[Wolfgang Schuster]

Am 18.11.2010 um 01:36 schrieb Philipp Gesang:

> Hi Wolfgang,
> 
> of course you are always welcome to deliver this kind of
> thorough discussion! The wiki is grateful …
> 
> Just two keys remain unexplained: “version” and “comment”. I
> guess they are not as critical but for sake of completeness and
> out of curiosity I wouldn’t mind having my guesses refuted or
> confirmed:
> 
> comment -  string: non-functional information that will be
>           stored along with the namespace?? 
> version -  number: versioning information?? Functionality not
>           yet known.

Both keys contain only information about the purpose of the module
and version number of the file like you have a the top of the file
in the „%D \module[...]“ block. They are used when you print
the table of namespaces with the \listnamespaces command.

Wolfgang

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace (was: The visual counter module)

[Philipp Gesang]

[-- Attachment #1.1: Type: text/plain, Size: 1715 bytes --]

On 2010-11-18 <04:56:27>, Wolfgang Schuster wrote:
> 
> Am 18.11.2010 um 01:36 schrieb Philipp Gesang:
> 
> > Hi Wolfgang,
> > 
> > of course you are always welcome to deliver this kind of
> > thorough discussion! The wiki is grateful …
> > 
> > Just two keys remain unexplained: “version” and “comment”. I
> > guess they are not as critical but for sake of completeness and
> > out of curiosity I wouldn’t mind having my guesses refuted or
> > confirmed:
> > 
> > comment -  string: non-functional information that will be
> >           stored along with the namespace?? 
> > version -  number: versioning information?? Functionality not
> >           yet known.
> 
> Both keys contain only information about the purpose of the module
> and version number of the file like you have a the top of the file
> in the „%D \module[...]“ block. They are used when you print
> the table of namespaces with the \listnamespaces command.

Yet another place to stuff away meta-info … alright, it’s been
wikified. Thanks! Philipp


> 
> Wolfgang
> 
> ___________________________________________________________________________________
> 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://tex.aanhet.net
> archive  : http://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace (was: The visual counter module)

[Aditya Mahajan]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3780 bytes --]

On Wed, 17 Nov 2010, Wolfgang Schuster wrote:

> I’m not Aditya but i hope you will also accept my explanation.

This is a much better explanation than I could have written. Just a few 
points:

> I will start with the first argument and the „type“ key, e.g.
>
>   \definenamespace
>     [fancybreak]
>     [type=module]
>
> will produce the namespace „@@@@fancybreak“ with the short form
> (the name itself has the same length but for TeX it’s only a single
> tokens instead of many with the @@@@... form) \????fancybreak.
>
> The is currently only one argument with the name „module“ but
> another one like „core“ or „base“ can appear in the future but
> this will be then reserved for Hans to replace the \definesystemvariable
> command from the core to produce a namespace in the form „@@xx“.
>
> When you define a namespace you should use three or more letters
> because two letter namespaces are reserved for Hans itself,
> e.g. is already used by the database module.
>
>
> The second key you need is „name“ because it’s argument is used
> when all the „\setup...“ and „\define...“ commands are created.
>
>
> The key „style“ creates the command „\doset<NAME>attributes“ which
> takes two arguments where the first is to change the style (font)
> in your new created command and the second for the color.
>
> The setup
>
>   \definenamespace
>     [fancybreak]
>     [type=module,
>      name=fancybreak,
>      style=yes]
>
> creates the command \dosetfancybreakattributes which can be used like
> \dosetfancybreakattributes\c!style\c!color and will take the „style“
> and „color“ argument from the \setupfancybreak command.
>
>
> The setup key creates the command „\setup<NAME>“ where you can control
> whether the commands accepts a list of environment in the two argument
> form or only a single environment, e.g. „setup=yes“ let you write
>
>   \setupfancybreak[one][..,..=..,..]
>
> and
>
>   \setupfancybreak[..,..=..,..]
>
> while „setup=list“ let you use
>
>   \setupfancybreak[one,two][..,..=..,..]
>
> and
>
>   \setupfancybreak[..,..=..,..]
>
>
> The key “command“ creates a bunch of macros, besides the „\define...“
> commands to create new environment and commands with your code it creates
> the following macros to access the values from your setup commands:
>
>   - \<Name>parameter
>   - \named<NAME>parameter
>   - \detokenized<NAME>parameter

In order to use these commads, you must set a value for \current<name>. 
For example, if you have

\define<name>[one][width=10cm]

In order to access the value of width of "one", you must do:

\def\current<name>{one}

\<name>parameter{width}

(I do not remember the distinction between \<name>parameter,
\named<name>paramter, and \detokenized<name>parameters).

> The command key has like the setup key the two values yes and list,
> with „command=yes“ you can write
>
>   \define<NAME>[one][..,..=..,..]
>
> or (clone a setup like \definehead[mysection][section])
>
>   \define<NAME>[two][one]
>
> while „command=list“ allows
>
>    \define<NAME>[one,two][..,..=..,..]
>
> or
>
>   \define<NAME>[two,three][one]
>

I did not know that cloning was possible. The \defineenumeration commands 
allows for

\defineenumeration[new][old][..=..]

This clones a selected options from old to new (using copyparamters) and 
then sets the values of the third arguments.

Would it make sense to add support for

\define<name>[two,three][one][..=..]?

>
> For parent it’s the best to give as argument always the same value
> as you defined for the namespace, e.g. for the fancybreak module
> one should write „parent=fancybreak“.

I thought that you have to write "parent=\????fancybreak".

Aditya

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace (was: The visual counter module)

[Wolfgang Schuster]

[-- Attachment #1.1: Type: text/plain, Size: 2265 bytes --]


Am 18.11.2010 um 22:20 schrieb Aditya Mahajan:

> Just a few points:
> 
>> The key “command“ creates a bunch of macros, besides the „\define...“
>> commands to create new environment and commands with your code it creates
>> the following macros to access the values from your setup commands:
>> 
>>  - \<Name>parameter
>>  - \named<NAME>parameter
>>  - \detokenized<NAME>parameter
> 
> In order to use these commads, you must set a value for \current<name>. For example, if you have
> 
> \define<name>[one][width=10cm]
> 
> In order to access the value of width of "one", you must do:
> 
> \def\current<name>{one}
> 
> \<name>parameter{width}
> 
> (I do not remember the distinction between \<name>parameter,
> \named<name>paramter, and \detokenized<name>parameters).

\<name>parameter use the value from \current<name> while \named<name>parameter
has two argument where the first argument is the name of a command or environment
created with \define<name>. \detokenized... is important when you pass values
from tex to lua and the value contains a tex command, e.g. \thinspace which
is normally expanded in this case.

> 
>> The command key has like the setup key the two values yes and list,
>> with „command=yes“ you can write
>> 
>>  \define<NAME>[two][one]
> 
> I did not know that cloning was possible. The \defineenumeration commands allows for
> 
> \defineenumeration[new][old][..=..]
> 
> This clones a selected options from old to new (using copyparamters) and then sets the values of the third arguments.

\copyparameters is only used for code which doesn’t use the new parameter command
with the parent handling but this method isn’t necessary in mkiv

> Would it make sense to add support for
> 
> \define<name>[two,three][one][..=..]?

You can redefine \define<name> or leave it out from \definenamespace.
What’s also is to write \define<name>[clone][parent=\????parent].

>> For parent it’s the best to give as argument always the same value
>> as you defined for the namespace, e.g. for the fancybreak module
>> one should write „parent=fancybreak“.
> 
> I thought that you have to write "parent=\????fancybreak".

That happens in the backend hidden from the user/author.

Wolfgang


[-- Attachment #1.2: Type: text/html, Size: 3500 bytes --]

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace (was: The visual counter module)

[Aditya Mahajan]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2598 bytes --]

On Thu, 18 Nov 2010, Wolfgang Schuster wrote:

> \<name>parameter use the value from \current<name> while \named<name>parameter
> has two argument where the first argument is the name of a command or environment
> created with \define<name>. \detokenized... is important when you pass values
> from tex to lua and the value contains a tex command, e.g. \thinspace which
> is normally expanded in this case.

Thanks.

>>> The command key has like the setup key the two values yes and list,
>>> with „command=yes“ you can write
>>>
>>>  \define<NAME>[two][one]
>>
>> I did not know that cloning was possible. The \defineenumeration commands allows for
>>
>> \defineenumeration[new][old][..=..]
>>
>> This clones a selected options from old to new (using copyparamters) and then sets the values of the third arguments.
>
> \copyparameters is only used for code which doesn’t use the new parameter command
> with the parent handling but this method isn’t necessary in mkiv

I am not sure how this is supposed to work. Consider this example:

\definenamespace
   [one]
   [type=module,
    name=one,
    setup=yes,
    parent=]

\definenamespace
   [two]
   [type=module,
    name=two,
    command=yes,
    parent=one]

\setupone[whatever=one]

\definetwo[test1]
\definetwo[test2][something=two]
\definetwo[test3][test2]

\starttext
\startlines
>>\namedtwoparameter{test1}{whatever}<<
>>\namedtwoparameter{test2}{whatever}<<
>>\namedtwoparameter{test2}{something}<<
>>\namedtwoparameter{test3}{something}<<
\stoplines
\stoptext


This gives

>>one<<
>><<
>>two<<
>><<

Why is the value of whatever not set for test2?

Why is the value of something not set for test3?

>> Would it make sense to add support for
>>
>> \define<name>[two,three][one][..=..]?
>
> You can redefine \define<name> or leave it out from \definenamespace.

I meant that why not \define<name> as follows:

\def\define<name>%
   {\dotripleargument\dodefine<name>}

\def\dodefinename<name>[#1][#2][#3]%
  {\doifassignmentelse{#2}
    {\getparameters[<name>#1][parent=<name>, #2]}
    {\getparameters[<name>#1][parent=<name>#2, #3]}}

> What’s also is to write \define<name>[clone][parent=\????parent].
>
>>> For parent it’s the best to give as argument always the same value
>>> as you defined for the namespace, e.g. for the fancybreak module
>>> one should write „parent=fancybreak“.
>>
>> I thought that you have to write "parent=\????fancybreak".
>
> That happens in the backend hidden from the user/author.

Ah, I see. Thanks.

Aditya

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: The visual counter module

[Willi Egger]

Hi Aditya,

Downloaded your new module. This is fun. Very suitable for all kind of presentations!

Willi
On 15 Nov 2010, at 00:16, Aditya Mahajan wrote:

> Hi,
> 
> This is to announce an alpha release of the visual counter module. See http://randomdeterminism.wordpress.com/2010/11/14/visualcounter-module/ for some examples, in particular http://randomdeterminism.files.wordpress.com/2010/11/theorem.pdf
> 
> The idea is to display a counter visually, in the same spirit as interactions bars. There is no support for interaction, but, on the plus sides, these work for any conter, not just the page counter. The idea of the module comes from the counters designed by Thomas as part of the simpleslides module.
> 
> The module only works with MkIV because I am using the new namespace code. So MkII support is unlikely.
> 
> Anyone else interested in such counters?
> 
> Aditya
> ___________________________________________________________________________________
> 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://tex.aanhet.net
> archive  : http://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace

[Wolfgang Schuster]

Am 19.11.2010 um 02:05 schrieb Aditya Mahajan:

> I am not sure how this is supposed to work. Consider this example:
> 
> [...]

There is a bug in the code for the \define... commands, you need this definition for \doinstalldefinehandler:

\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
  {\unexpanded\def#2{\dodoubleempty#5}%
   \newtoks#6%
   \newtoks#7%
   \def#5[##1][##2]%
     {\edef#4{##1}%
      \the#6% predefine
      \ifsecondargument
        \doifassignmentelse{##2}
          {\getparameters[#1#4][\s!parent=#3,##2]}
          {\getparameters[#1#4][\s!parent=#1##2]}%
      \fi
      \the#7}}

To have three arguments for the \define... commands like \defineenumeration change the above command to:

\unprotected\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
  {\unexpanded\def#2{\dotripleempty#5}%
   \newtoks#6%
   \newtoks#7%
   \def#5[##1][##2][##3]%
     {\edef#4{##1}%
      \the#6% predefine
      \ifsecondargument
        \doifassignmentelse{##2}
          {\getparameters[#1#4][\s!parent=#3,##2]}
          {\getparameters[#1#4][\s!parent=#1##2,##3]}%
      \fi
      \the#7}}

Wolfgang

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace

[Hans Hagen]

On 19-11-2010 6:35, Wolfgang Schuster wrote:
>
> Am 19.11.2010 um 02:05 schrieb Aditya Mahajan:
>
>> I am not sure how this is supposed to work. Consider this example:
>>
>> [...]
>
> There is a bug in the code for the \define... commands, you need this definition for \doinstalldefinehandler:
>
> \unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
>    {\unexpanded\def#2{\dodoubleempty#5}%
>     \newtoks#6%
>     \newtoks#7%
>     \def#5[##1][##2]%
>       {\edef#4{##1}%
>        \the#6% predefine
>        \ifsecondargument
>          \doifassignmentelse{##2}
>            {\getparameters[#1#4][\s!parent=#3,##2]}
>            {\getparameters[#1#4][\s!parent=#1##2]}%
>        \fi
>        \the#7}}
>
> To have three arguments for the \define... commands like \defineenumeration change the above command to:
>
> \unprotected\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
>    {\unexpanded\def#2{\dotripleempty#5}%
>     \newtoks#6%
>     \newtoks#7%
>     \def#5[##1][##2][##3]%
>       {\edef#4{##1}%
>        \the#6% predefine
>        \ifsecondargument
>          \doifassignmentelse{##2}
>            {\getparameters[#1#4][\s!parent=#3,##2]}
>            {\getparameters[#1#4][\s!parent=#1##2,##3]}%
>        \fi
>        \the#7}}

or maybe:

\unprotected\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
   {\unexpanded\def#2{\dotripleempty#5}%
    \newtoks#6%
    \newtoks#7%
    \def#5[##1][##2][##3]%
      {\edef#4{##1}%
       \the#6% predefine
       \ifthirdargument
          \getparameters[#1#4][\s!parent=#1##2,##3]%
       \else\ifsecondargument
          \getparameters[#1#4][\s!parent=#3,##2]
       \fi\fi
       \the#7}}



-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace

[Aditya Mahajan]

On Fri, 19 Nov 2010, Hans Hagen wrote:

> On 19-11-2010 6:35, Wolfgang Schuster wrote:
>> 
>> Am 19.11.2010 um 02:05 schrieb Aditya Mahajan:
>> 
>>> I am not sure how this is supposed to work. Consider this example:
>>> 
>>> [...]
>> 
>> There is a bug in the code for the \define... commands, you need this 
>> definition for \doinstalldefinehandler:
>> 
>> \unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
>>    {\unexpanded\def#2{\dodoubleempty#5}%
>>     \newtoks#6%
>>     \newtoks#7%
>>     \def#5[##1][##2]%
>>       {\edef#4{##1}%
>>        \the#6% predefine
>>        \ifsecondargument
>>          \doifassignmentelse{##2}
>>            {\getparameters[#1#4][\s!parent=#3,##2]}
>>            {\getparameters[#1#4][\s!parent=#1##2]}%
>>        \fi
>>        \the#7}}
>> 
>> To have three arguments for the \define... commands like \defineenumeration 
>> change the above command to:
>> 
>> \unprotected\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
>>    {\unexpanded\def#2{\dotripleempty#5}%
>>     \newtoks#6%
>>     \newtoks#7%
>>     \def#5[##1][##2][##3]%
>>       {\edef#4{##1}%
>>        \the#6% predefine
>>        \ifsecondargument
>>          \doifassignmentelse{##2}
>>            {\getparameters[#1#4][\s!parent=#3,##2]}
>>            {\getparameters[#1#4][\s!parent=#1##2,##3]}%
>>        \fi
>>        \the#7}}
>
> or maybe:
>
> \unprotected\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
>  {\unexpanded\def#2{\dotripleempty#5}%
>   \newtoks#6%
>   \newtoks#7%
>   \def#5[##1][##2][##3]%
>     {\edef#4{##1}%
>      \the#6% predefine
>      \ifthirdargument
>         \getparameters[#1#4][\s!parent=#1##2,##3]%
>      \else\ifsecondargument
>         \getparameters[#1#4][\s!parent=#3,##2]
>      \fi\fi
>      \the#7}}

That one will be slightly faster, I think.

Aditya
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace

[Hans Hagen]

On 19-11-2010 7:05, Aditya Mahajan wrote:

>> \unprotected\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
>> {\unexpanded\def#2{\dotripleempty#5}%
>> \newtoks#6%
>> \newtoks#7%
>> \def#5[##1][##2][##3]%
>> {\edef#4{##1}%
>> \the#6% predefine
>> \ifthirdargument
>> \getparameters[#1#4][\s!parent=#1##2,##3]%
>> \else\ifsecondargument
>> \getparameters[#1#4][\s!parent=#3,##2]
>> \fi\fi
>> \the#7}}
>
> That one will be slightly faster, I think.

indeed, not that there is much defining going on but every millisecond 
counts as they add up

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace

[Wolfgang Schuster]

Am 19.11.2010 um 18:56 schrieb Hans Hagen:

> or maybe:
> 
> \unprotected\unexpanded\def\doinstalldefinehandler#1#2#3#4#5#6#7%
>  {\unexpanded\def#2{\dotripleempty#5}%
>   \newtoks#6%
>   \newtoks#7%
>   \def#5[##1][##2][##3]%
>     {\edef#4{##1}%
>      \the#6% predefine
>      \ifthirdargument
>         \getparameters[#1#4][\s!parent=#1##2,##3]%
>      \else\ifsecondargument
>         \getparameters[#1#4][\s!parent=#3,##2]
>      \fi\fi
>      \the#7}}

No, because you need \doifassignment. Your code allows only

   \define...[new][old][..=..]

and

   \define...[new][..=..]

but it’s not possible to write

   \define...[new][old]

because „new“ won’t use „old“ as parent with this defintion.

Wolfgang

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace

[Vianney le Clément]

Could there also be a bug in the \setup command definition:

\unexpanded\def\doinstallsetuphandler#1#2#3#4#5%
  {\unexpanded\def#2{\dodoubleempty#4}%
   \newtoks#5%
   \def#4[##1][##2]%
     {\ifsecondargument
        \def\docommand####1% we will have a simple one as well
          {\edef#3{##1}%
           \getparameters[#1#3][##2]%
           \the#5}%
        \processcommalist[##1]\docommand
      \else
        \let#3\empty
        \getparameters[#1][##1]%
        \the#5%
      \fi}}

I would expect (difference is on the seventh line):

\unexpanded\def\doinstallsetuphandler#1#2#3#4#5%
  {\unexpanded\def#2{\dodoubleempty#4}%
   \newtoks#5%
   \def#4[##1][##2]%
     {\ifsecondargument
        \def\docommand####1% we will have a simple one as well
          {\edef#3{####1}%                <-- argument of \docommand
instead of the comma-separated list
           \getparameters[#1#3][##2]%
           \the#5}%
        \processcommalist[##1]\docommand
      \else
        \let#3\empty
        \getparameters[#1][##1]%
        \the#5%
      \fi}}

Vianney

PS: just to learn some TeXnical details, could someone explain what
the \unexpanded is supposed to do here?
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \definenamespace

[Hans Hagen]

On 19-11-2010 9:12, Vianney le Clément wrote:

>            {\edef#3{####1}%<-- argument of \docommand

indeed


> PS: just to learn some TeXnical details, could someone explain what
> the \unexpanded is supposed to do here?

it is etex's \protected prefix and not to be confused with the etex 
primitive \unexpanded

it happens that before there was etex we already had \unexpanded but 
implemented differently

\unexpanded in context defined a macro as not expandable in some cases, 
like within an \edef

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________