I want to do something with & in tables (making it an active column separator). Now I have a macro with two arguments for parameters in Context style: \def\starttablex{\dodoubleargument\dostarttablex} \def\dostarttablex[#1][#2]{% Now for input: \starttable[][] & ... all is well, but for input: \starttable[] & ... the ampersand appears to be eaten up by the double argument expansion. How can I prevent that, letting & end the parameter scanning and using it as the first input? Hans van der Meer
Hans van der Meer wrote:
I want to do something with & in tables (making it an active column separator). Now I have a macro with two arguments for parameters in Context style:
\def\starttablex{\dodoubleargument\dostarttablex} \def\dostarttablex[#1][#2]{%
Now for input:�\starttable[][] & ... all is well, but for input: \starttable[]� �& ... the ampersand appears to be eaten up by the double argument expansion. starttable or starttablex
btw, messing around with & is dangerous in tex Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Jul 13, 2006, at 22:27, Hans Hagen wrote:
Hans van der Meer wrote:
I want to do something with & in tables (making it an active column separator). Now I have a macro with two arguments for parameters in Context style:
\def\starttablex{\dodoubleargument\dostarttablex} \def\dostarttablex[#1][#2]{%
Now for input:�\starttable[][] & ... all is well, but for input: \starttable[]� �& ... the ampersand appears to be eaten up by the double argument expansion.
starttable or starttablex
Sorry, but I am missing your point here. Does your answer imply that I cannot work with a [][]-parameterlist? That would be problematic because I am using your getparameters-thing extensively. Or do you mean something else that will stop the parameter gathering at the & ?
btw, messing around with & is dangerous in tex
I know, I know, ... Hans van der Meer
Hans van der Meer wrote:
On Jul 13, 2006, at 22:27, Hans Hagen wrote:
Hans van der Meer wrote:
I want to do something with & in tables (making it an active column separator). Now I have a macro with two arguments for parameters in Context style:
\def\starttablex{\dodoubleargument\dostarttablex} \def\dostarttablex[#1][#2]{%
Now for input:�\starttable[][] & ... all is well, but for input: \starttable[]� �& ... the ampersand appears to be eaten up by the double argument expansion.
starttable or starttablex
Sorry, but I am missing your point here. Does your answer imply that I cannot work with a [][]-parameterlist? That would be problematic because I am using your getparameters-thing extensively. Or do you mean something else that will stop the parameter gathering at the & ?
no, it's just that your definition defines *x and that you use * ; it' shard to see what goes wrong with an uncomplete example; in normal cases arg grabbing should work ok Hans
Hans van der Meer wrote:
I want to do something with & in (my homemade) tables (making it an active column separator). Now I have a macro with two arguments for parameters in Context style:
\def\starttablex{\dodoubleargument\dostarttablex} \def\dostarttablex[#1][#2]{%
Now for input:�\starttablex[][] & ... all is well, but for input: \starttablex[]� �& ... the ampersand appears to be eaten up by the double argument expansion.
After some experimenting with argument retrieval I guess I figured out what happens here. Reducing to one optional argument and crippling \dosingleempty to \def\dosingleempty#1% {\noshowargumenterror % \relax % prevents lookahead, brr dosinglefakeempty#1} There is no problem in processing the active &. Therefore I conclude to the following: on inspecting the next character with "\doifnextcharelse[%" the character which is compared is the &. Being not equal to [ it is given back but -- if I remember well -- there can be a catcode problem. I guess & still functions as separator in the \halign template but no longer functions as a macro, as it should in my code. There might be no solution for this within TeX's limitations. But maybe you can confirm cq. deny that from your knowledge of TeX (which certainly is greater than mine). Hans van der Meer
Hans van der Meer wrote:
Therefore I conclude to the following: on inspecting the next character with "\doifnextcharelse[%" the character which is compared is the &.
It is more technically correct to say that the \doifnextcharelse compares the first token of the expansion of '&' with the second token of the expansion of '&'. Down this road awaits madness. In general, you can not intermix optional arguments and active characters, you need to have at least one non-active non-space token to break off the search in a reliable manner. Simply adding a \relax statement sounds like the simplest solution.
Being not equal to [ it is given back but -- if I remember well -- there can be a catcode problem. I guess & still functions as separator in the \halign template but no longer functions as a macro, as it should in my code.
There might be no solution for this within TeX's limitations. But maybe you can confirm cq. deny that from your knowledge of TeX (which certainly is greater than mine).
There is a chance that there is a hackish way around this limitiation for some very specific cases, but i cannot tell without the actual code you use. Taco
On Jul 14, 2006, at 15:57, Taco Hoekwater wrote:
Hans van der Meer wrote:
Therefore I conclude to the following: on inspecting the next character with "\doifnextcharelse[%" the character which is compared is the &.
It is more technically correct to say that the \doifnextcharelse compares the first token of the expansion of '&' with the second token of the expansion of '&'. Down this road awaits madness.
Indeed, that is certainly more correct.
In general, you can not intermix optional arguments and active characters, you need to have at least one non-active non-space token to break off the search in a reliable manner.
Simply adding a \relax statement sounds like the simplest solution.
Yes, I found that out already, even something like {} does the trick. But stubborn as I sometimes may be, I first tried to find a solution within the macro definition, that does not depend on the data processed.
Being not equal to [ it is given back but -- if I remember well -- there can be a catcode problem. I guess & still functions as separator in the \halign template but no longer functions as a macro, as it should in my code.
There might be no solution for this within TeX's limitations. But maybe you can confirm cq. deny that from your knowledge of TeX (which certainly is greater than mine).
There is a chance that there is a hackish way around this limitiation for some very specific cases, but i cannot tell without the actual code you use.
I will privately mail a copy of my file. It is fairly extensively commented. But not yet a finished product though. However, very hackish doesn't foretells much good. I certainly am able to acknowdledge defeat if it faces me so strongly as is the case here.
Taco _______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Hans van der Meer
Hans van der Meer wrote:
There might be no solution for this within TeX's limitations. But maybe you can confirm cq. deny that from your knowledge of TeX (which certainly is greater than mine).
there is undoubtely a solution but it quickly becomes messy as soon as preambles and such are involved (lookahead problems); Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans van der Meer wrote:
I want to do something with & in tables (making it an active column separator). Now I have a macro with two arguments for parameters in Context style:
\def\starttablex{\dodoubleargument\dostarttablex} ^^^^^^^^ Shouldn't this be \dodoubleempty for optional arguments?
Peter
\def\dostarttablex[#1][#2]{%
Now for input: \starttable[][] & ... all is well, but for input: \starttable[] & ... the ampersand appears to be eaten up by the double argument expansion.
How can I prevent that, letting & end the parameter scanning and using it as the first input?
Hans van der Meer
------------------------------------------------------------------------
_______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
On 7/13/06, Hans van der Meer wrote:
I want to do something with & in tables (making it an active column separator).
I didn't follow this discussion closely (I have to catch up with the mails from this week), so I might have missed the point, but does something like this satisfy your needs? \usemodule [database] % you can change the commands to \starttabulate or \starttable, % according to the pattern % but I don't know them by heart \defineseparatedlist [MyList] [left=\bTD,right=\eTD, first=\bTR,last=\eTR, before=\bTABLE,after=\eTABLE, separator=&] \starttext \startseparatedlist[MyList] a & b & c \stopseparatedlist \stoptext Temporary documentation for "separatedlist" can be found on http://pub.mojca.org/tex/csv/, but I have to wait until two important bugs are fixed, namely UTF-8 (twice) and multiple separators one after another (and I have some little problems with showing the settings of two commands, which is most probably my fault). Mojca
On Jul 14, 2006, at 16:18, Mojca Miklavec wrote:
On 7/13/06, Hans van der Meer wrote:
I want to do something with & in tables (making it an active column separator).
I didn't follow this discussion closely (I have to catch up with the mails from this week), so I might have missed the point, but does something like this satisfy your needs?
\usemodule [database] % you can change the commands to \starttabulate or \starttable,
Thanks for trying to help, but I don't think this is the solution. The problem arises from the construction of a private table-modules, not from using current Context stuff other than lowlevel macro's. Hans van der Meer
participants (5)
-
Hans Hagen -
Hans van der Meer -
Mojca Miklavec -
Peter Rolf -
Taco Hoekwater