eating up &

eating up &

[Hans van der Meer]

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

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




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

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

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: eating up &

[Hans Hagen]

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
-----------------------------------------------------------------

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: eating up &

[Hans van der Meer]

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



_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: eating up &

[Hans Hagen]

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
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: eating up &

[Hans van der Meer]

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



_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: eating up &

[Taco Hoekwater]

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

Re: eating up &

[Hans van der Meer]

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

Re: eating up &

[Hans Hagen]

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
-----------------------------------------------------------------

Re: eating up &

[Peter Rolf]

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

Re: eating up &

[Mojca Miklavec]

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

Re: eating up &

[Hans van der Meer]

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