[NTG-pdftex] [pdftex-Patches][469] \currentexpansionmode + \ifalignscanning - \ifinedef

pdftex-patches at sarovar.org pdftex-patches at sarovar.org
Mon Apr 6 00:01:07 CEST 2009

Patches item #469, was opened at 2006-01-12 01:39
>Status: Closed
Priority: 3
Submitted By: Morten Høgholm (morten)
Assigned to: The Thanh Han (hanthethanh)
Summary: \currentexpansionmode + \ifalignscanning - \ifinedef 
Category: Primitives
Group: v1.40.0
>Resolution: Rejected

Initial Comment:
Here's a patch made against pdftex-1.40.0-alpha-20060111.  It 
removes the \ifinedef primitive for a different primitive, namely 
\currentexpansionmode. This read-only register is 0 when doing 
regular typesetting, 1 when inside \edef or \xdef and 2 in other 
cases of full expansion with scan_toks. It could possibly be 
extended to distinguish between \marks and \write etc. Comments 
more than welcome on this one!

I have also added an \ifalignscanning test. It is true whenever TeX 
is looking for \noalign etc. so is most useful for a 
\stopalignscanning function defined as 


Comment By: Frank Mittelbach (mittelbach)
Date: 2006-02-15 17:38

Logged In: YES 

concerning register versus individual \if... primitves: I  
agree that numeric values are less easy to read but if the  
numeric codes are well chosen then they have the advantage  
of not cluttering the code, eg if you have to test for a  
number of different cases then a set of nested \if's is  
also not really helpful. Suppose for example you have to  
do different actions depending on the type of expansion.  
Then the register allows you to do this in a since \ifcase  
or in some \ifnum ...> . But of course this only works is  
the order is adjusted to typical usages.  
And non-numerical ones could still be implemented  
efficently at the macro level, eg  
 \def\ifinedef{\ifnum 1=\currentexpansionmode} 
as to \stopalignscanning: this is not identical to 
\protected as protection prevents expansion in all cases 
which is not necessarily what you need 
my 2 cents 


Comment By: Hans Hagen (hagen)
Date: 2006-01-17 22:22

Logged In: YES 

concerning alignments: 

- how about adding \everyaligncell (in addition to \everycr) 

- how about the other iftests? 

- (and \nospan -) 


Comment By: Morten Høgholm (morten)
Date: 2006-01-16 20:23

Logged In: YES 

@None: An \ifalignscanning primitive can also help macros like LaTeX's 
\multicolumn and other code that relies on seeing \noalign or \omit to 
recover gracefully with a comprehensible error message.


Comment By: Morten Høgholm (morten)
Date: 2006-01-13 04:50

Logged In: YES 

Yes, just ideas here, which is why I asked for comments. We can discuss 
this on the list (once my subscription is accepted).


Comment By: Taco Hoekwater (taco)
Date: 2006-01-12 10:22

Logged In: YES 

Like Hans, I also prefer separate if primitives, mainly
because I do not want to have to remember the meanings 
of the possible integer values (for that reason, I'm not 
too happy about \currentgrouptype either). 



Comment By: Nobody (None)
Date: 2006-01-12 09:14

Logged In: NO 

i wonder why we need \ifalignscanning or \stopalignscanner
at all when
eTeX already has this feature - any \protected macro stops the


Comment By: Hans Hagen (hagen)
Date: 2006-01-12 08:08

Logged In: YES 

somehow i think that if's are a better idea than a register
because in your case the register only registers one case at
the same time

(when i saw this patch the first time, i wondered why not a
complete set was implemented) 

- ifincsname
- ifinedef
- ifinwrite
- ifinspecial
- ifinpdfliteral 
- ifinannotbody
- ifinmessage (special case of write)
- ifinalign
- ifinmark 

probably some more (ok, normally all those conditions can
comfortably be catched in a macro package but if we add
them, we should be complete 

in addition to this there can be a register which keeps
track of the innermost one (we can have ifcsname inside an
edef inside an align 

concerning the \stopalignscanner i think it's better to have
something primitive like \crcr, say \endalign because using
if's can have its own problem 

(we should not worry to much about a name clash, since one
can always let it to another one); so, we should wait with
adding this patches till (1) we agree and (2) it is complete 

remark: also, it's dangerous to add patched before a decent
decission/interface is dediced upon; once it's in, we cannot
change it any more 



You can respond by visiting: 

More information about the ntg-pdftex mailing list