> From: "Simons, Don" <[EMAIL PROTECTED]>
> Date: Fri, 5 May 2000 10:27:13 -0700
[... MTX usage of \atnextline ..]
> There is a potential difficulty with this approach. PMX generates an
> \atnextline command in some limited circumstances related to centered
> headers. My own coding is also at fault because I have not allowed for the
> possibility that there was an in-line \atnextline that had been entered
> prior to the PMX-generated one. As it now stands, if M-Tx or the PMX user
> inlines an \atnextline in the PMX file, I believe it will either supersede
> the PMX-generated one or be ignored, depending on the relative locations in
> the TeX file. Is there a general approach for both M-Tx and PMX that would
> keep everyone happy?
Some time ago, I had a similar problem with my edition of Bach's Sonatas and
Partitas for Violin Solo. I had some macros which used \atnextline e.g.
(shortened): \def\Taktc#1{\def\atnextline{\testbar}\bar}
Lateron I wanted to use \atnextline in open code, too, e.g.
\def\atnextline{\vskip -2\Interligne}
So I invented the following two definitions
\def\nxtsav{\ifx\atnextlinesav\undefined\let\atnextlinesav\atnextline
\else\message{Error ...}...\fi}
\def\nxtexe{\atnextlinesav\let\atnextlinesav\undefined}
and changed the definition of \Taktc etc. to
\def\Takt#1{\nxtsav\def\atnextline{\tstbar\nxtexe}\bar}
PMX could use this procedure in the same way if Type-1 (\gdef\atnextline...\}
and Type-3 {\\\def\atnexline...\} inline-TeX is execute before PMX uses
\nxtsav\def\atnextline{..PMX's code..\nxtexe}
I'm sure there are more elegant solutions and solution which allow a deeper stacking.
At least the names should be \n@xtsav and \n@xtexe or similar.
If I made too many typos in this mail one can access the partial source of the
above mentioned edition. The solution is defined in spec1001.tex.
> BTW there are similar issues with \atnextbar, which PMX uses much more often
> than \atnextline.
"Same procedure as every year"
-- Werner
