Received: by nummer-3.proteosys id <01C19442.D4F9807C@nummer-3.proteosys>; Thu, 3 Jan 2002 11:38:50 +0100 MIME-Version: 1.0 x-vm-v5-data: ([nil nil nil nil nil nil nil t nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19442.D4F9807C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: RE: VERB IN HEADINGS FULL Date: Tue, 23 Oct 1990 09:50:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "LaTeX-L Mailing list" Sender: "MITTELBACH FRANK" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 244 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19442.D4F9807C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Victor pointed out a problem with using meaning but I still think this can be handled: > > The idea of using \meaning was too good to be true. > > In the next TUGboat there will be an article by Ron Whitney > that uses this trick. When I read a draft of that article > I thought 'Cute. Let's try using it'. Here's what's wrong with > using it for verbatim text: > > \def\verb#1{\def\text{#1}\meaning\text} > \verb{1&2} > \verb{1#3} > > which gives > > \verb #1->\def \text {#1}\meaning \text > #1<-1##3 > ! Illegal parameter number in definition of \text. > > 3 > \verb #1->\def \text {#1 > }\meaning \text If I don't miss anything the only critical character is the hash mark. But I don't think we need to make the hash mark a special character in the new LaTeX. It can be a simple character of catode 12. Only during the definition time, i.e. \newcommand, etc. we need it as a macro parameter character. The only restriction of the use of \verb would then be that \verb inside \newcommand can only contain a # mark if it is doubled. Explaining #1 etc for \newcommand could make it clear to the user that it is sensible to prevent LaTeX from interpreting # in a \newcommand by doubling it. This would also allow to define things like \newcommand{\abc}[1 ]{ \verb+#1+ } which would then put the argument into the \verb command. Of course, there is one problem: \def etc outside of style files would not be possible any longer. But that's something some people would like anyway. At least everybody who ever had to track done errors coming from user definitions like \def\or{\lor} or something similar nasty. An interesting side effect is that if somebody uses \verb=3D#=3D inside \newcommand this would be interpreted after the error message correctly as \verb=3D##=3D so the output would be okay! > > Ron also suggested scooping up the text as a token list, writing > that out and reading it in (his context was a bit different, > but that's irrelevant for now). Here's what's wrong with that: > > \def\verb#1{\toks0=3D{#1}\showthe\toks0 } > \verb{1#3} > > gives > > \verb #1->\toks 0=3D{#1}\showthe \toks 0 > #1<-1##3 > > That is, the parameter character gets duplicated. > It seems like implementing verbatim will have to be done > the hard way. Or at least *some* hard way. Writing out and reading in is not possible because of brace problems and because it is much too slow. In principle all this problems including double # marks could be solved by assigning suitable catcodes to all critical characters (# could be active removing the second # since this is always present). But as I said this would be much too complicated. Frank Mittelbach ------_=_NextPart_001_01C19442.D4F9807C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE: VERB IN HEADINGS FULL

Victor pointed out a problem with using meaning = but
I still think this can be handled:
>
> The idea of using \meaning was too good to be = true.
>
> In the next TUGboat there will be an article by = Ron Whitney
> that uses this trick. When I read a draft of = that article
> I thought 'Cute. Let's try using it'. Here's = what's wrong with
> using it for verbatim text:
>
> \def\verb#1{\def\text{#1}\meaning\text}
> \verb{1&2}
> \verb{1#3}
>
> which gives
>
> \verb #1->\def \text {#1}\meaning = \text
> #1<-1##3
> ! Illegal parameter number in definition of = \text.
> <to be read again>
>          =           3
> \verb #1->\def \text {#1
>          =             &= nbsp;  }\meaning \text

If I don't miss anything the only critical character = is the hash mark.
But I don't think we need to make the hash mark a = special character in
the new LaTeX. It can be a simple character of catode = 12. Only during
the definition time, i.e. \newcommand, etc. we need = it as a macro
parameter character. The only restriction of the use = of \verb would
then be that \verb inside \newcommand can only = contain a # mark if it
is doubled. Explaining #1 etc for \newcommand could = make it clear to
the user that it is sensible to prevent LaTeX from = interpreting
# in a \newcommand by doubling it. This would also = allow to define
things like

\newcommand{\abc}[1 ]{<somecode> \verb+#1+ = <some more code>}

which would then put the argument into the \verb = command.

Of course, there is one problem: \def etc outside of = style files
would not be possible any longer. But that's = something some people
would like anyway. At least everybody who ever had to = track done
errors coming from user definitions like

\def\or{\lor}

or something similar nasty.

An interesting side effect is that if somebody uses = \verb=3D#=3D inside
\newcommand this would be interpreted after the error = message
correctly as \verb=3D##=3D so the output would be = okay!

>
> Ron also suggested scooping up the text as a = token list, writing
> that out and reading it in (his context was a = bit different,
> but that's irrelevant for now). Here's what's = wrong with that:
>
> \def\verb#1{\toks0=3D{#1}\showthe\toks0 }
> \verb{1#3}
>
> gives
>
> \verb #1->\toks 0=3D{#1}\showthe \toks = 0
> #1<-1##3
>
> That is, the parameter character gets = duplicated.
> It seems like implementing verbatim will have to = be done
> the hard way. Or at least *some* hard = way.

Writing out and reading in is not possible because of = brace problems
and because it is much too slow. In principle all = this problems
including double # marks could be solved by assigning = suitable catcodes
to all critical characters (# could be active = removing the second
# since this is always present). But as I said this = would be much  too
complicated.

Frank Mittelbach


------_=_NextPart_001_01C19442.D4F9807C--