Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 May 2004 09:11:03 +0200 Received: by mail.proteosys.com (8.12.10/8.12.2) with ESMTP id i4H7Amlo010465 for ; Mon, 17 May 2004 09:10:55 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.119.176]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i4H71m1K027469; Mon, 17 May 2004 09:01:48 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43BDE.1D165D80" Received: from listserv (listserv.uni-heidelberg.de [129.206.119.176]) by listserv.uni-heidelberg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i4H42tVj005625; Mon, 17 May 2004 09:00:01 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8e) with spool id 210694 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 17 May 2004 09:00:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i4H6nxUZ009377 for ; Mon, 17 May 2004 08:49:59 +0200 Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i4H6p51K024784 for ; Mon, 17 May 2004 08:51:08 +0200 (MET DST) Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BPbxd-0004aw-6o for LATEX-L@listserv.uni-heidelberg.de; Mon, 17 May 2004 02:51:05 -0400 In-Reply-To: Lines: 80 References: <16549.4057.399610.750080@istrati.mittelbach-online.de> <16550.4621.526207.509473@istrati.mittelbach-online.de> <16551.33482.606374.833460@istrati.mittelbach-online.de> <16551.47476.13708.161193@istrati.mittelbach-online.de> Return-Path: X-OriginalArrivalTime: 17 May 2004 07:11:03.0355 (UTC) FILETIME=[1D4C88B0:01C43BDE] User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-ProteoSys-SPAM-Score: 0 () Content-class: urn:content-classes:message Subject: Re: Why don't we do just the following: Date: Mon, 17 May 2004 07:50:17 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why don't we do just the following: Thread-Index: AcQ73h1oymZ+TI7IT2eJbP0HNKnZ9w== From: "David Kastrup" Sender: "Mailing list for the LaTeX3 project" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4791 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43BDE.1D165D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Donald Arseneau writes: > Frank Mittelbach writes: > > > > It was supposed to hit at \label time. But since putting a label > > > > i still don't see how that would work > > You did analyze it already: it is a confusing undefined control > sequence error, where the "real" error message is the csname. The > \csname must be constructed in a way that does not equate it to = \relax. > > Url.sty contains: > > \def\Url@movingtest{\begingroup > \ifx\let\HyPsd@LetCommand % we are already in a pdf string! > \expandafter\Url@unmove \fi % give the argument and hope for the = best > \let\Url@moving\relax\relax\relax > \ifx\Url@moving\relax\else \expandafter\Url@unmove \fi > \endgroup} > \long\def\Url@unmove#1\Url@y{\endgroup = \ifx\protect\relax\else\protect\Url\fi} > \edef\Url@moving{\csname Url Error\endcsname} > \expandafter\edef\Url@moving > {\csname url used in a moving argument.\endcsname} > \expandafter\expandafter\expandafter \let \Url@moving\@undefined > > Note the last line! This gives error messages like: > > ! Undefined control sequence. > \Url Error ->\url used in a moving argument. > > l.104 \section{\url{moving}} > > > Anyway, We should still allow \label for purposes of \pageref, so the > error should indeed be encoded to occur at \ref. It would be nice if > \label would put the current \inputlineno into the error message, but > that requires altering the definition of \label. No, it doesn't. I seem to be talking against the wall here. Here are the relevant definitions: \def\label#1{\@bsphack \protected@write\@auxout{}% {\string\newlabel{#1}{{\@currentlabel}{\thepage}}}% \@esphack} \long\def \protected@write#1#2#3{% \begingroup \let\thepage\relax #2% \let\protect\@unexpandable@protect \edef\reserved@a{\write#1{#3}}% \reserved@a \endgroup \if@nobreak\ifvmode\nobreak\fi\fi } As you can see, putting \the\inputlineno into \currentlabel will expand to the input line number at the time where \label is called. I have to admit to Frank that without changing the definition of \label, we won't get the label name itself for reference in the message. Unless we wanted to play _very_ dirty tricks and use something like \def\@currentlabel{\noexpand\pickapart\noexpand\reserved@a} And the \pickapart breaks up \reserved@a into its constituents. However, if we are going to change \@float, there is little harm in changing \label to include a \def\@labelname{#1}% \@onelevelsanitize\@labelname into the definition of \label. I can't see \label working in a context where the above would have problems. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ------_=_NextPart_001_01C43BDE.1D165D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Why don't we do just the following:

Donald Arseneau <asnd@TRIUMF.CA> writes:

> Frank Mittelbach = <frank.mittelbach@LATEX-PROJECT.ORG> writes:
>
> >  > It was supposed to hit at \label = time.  But since putting a label
> >
> > i still don't see how that would = work
>
> You did analyze it already: it is a confusing = undefined control
> sequence  error, where the "real" = error message is the csname.  The
> \csname must be constructed in a way that does = not equate it to \relax.
>
> Url.sty contains:
>
> \def\Url@movingtest{\begingroup
>  \ifx\let\HyPsd@LetCommand % we are already = in a pdf string!
>   \expandafter\Url@unmove \fi % give = the argument and hope for the best
>  \let\Url@moving\relax\relax\relax
>  \ifx\Url@moving\relax\else = \expandafter\Url@unmove \fi
>  \endgroup}
> \long\def\Url@unmove#1\Url@y{\endgroup = \ifx\protect\relax\else\protect\Url\fi}
> \edef\Url@moving{\csname Url = Error\endcsname}
> \expandafter\edef\Url@moving
>  {\csname url used in a moving = argument.\endcsname}
> \expandafter\expandafter\expandafter \let = \Url@moving\@undefined
>
> Note the last line!  This gives error = messages like:
>
> ! Undefined control sequence.
> \Url Error ->\url used in a moving = argument.
>
> l.104 \section{\url{moving}}
>
>
> Anyway, We should still allow \label for = purposes of \pageref, so the
> error should indeed be encoded to occur at = \ref.  It would be nice if
> \label would put the current \inputlineno into = the error message, but
> that requires altering the definition of = \label.

No, it doesn't.  I seem to be talking against the = wall here.  Here
are the relevant definitions:

\def\label#1{\@bsphack
  \protected@write\@auxout{}%
         = {\string\newlabel{#1}{{\@currentlabel}{\thepage}}}%
  \@esphack}

\long\def \protected@write#1#2#3{%
      \begingroup
       = \let\thepage\relax
       #2%
       = \let\protect\@unexpandable@protect
       = \edef\reserved@a{\write#1{#3}}%
       = \reserved@a
      \endgroup
      = \if@nobreak\ifvmode\nobreak\fi\fi
}

As you can see, putting \the\inputlineno into = \currentlabel will
expand to the input line number at the time where = \label is called.

I have to admit to Frank that without changing the = definition of
\label, we won't get the label name itself for = reference in the
message.  Unless we wanted to play _very_ dirty = tricks and
use something like
\def\@currentlabel{\noexpand\pickapart\noexpand\reserved@a}

And the \pickapart breaks up \reserved@a into its = constituents.

However, if we are going to change \@float, there is = little harm in
changing \label to include a
\def\@labelname{#1}%
\@onelevelsanitize\@labelname
into the definition of \label.

I can't see \label working in a context where the = above would have
problems.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

------_=_NextPart_001_01C43BDE.1D165D80--