The visual counter module
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
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 -----------------------------------------------------------------
Awesome! I'm sure this will come in handy one day.
-- Mathieu
On Mon, Nov 15, 2010 at 12:16 AM, 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 ___________________________________________________________________________________
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
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
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
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
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
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
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
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
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
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 -----------------------------------------------------------------
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
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 -----------------------------------------------------------------
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
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?
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 -----------------------------------------------------------------
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 ___________________________________________________________________________________
participants (7)
-
Aditya Mahajan -
Hans Hagen -
Mathieu Boespflug -
Philipp Gesang -
Vianney le Clément -
Willi Egger -
Wolfgang Schuster