Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Message-ID:  <199910271007.MAA22952@relay.urz.uni-heidelberg.de>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@URZ.UNI-HEIDELBERG.DE>
Date:         Wed, 27 Oct 1999 12:07:32 +0100
From: Javier Bezos <jbezos@ARRAKIS.ES>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@URZ.UNI-HEIDELBERG.DE>
Subject:      Re: Robustness (more)
Status: R

Frank,

 > Example:
 >
 > \documentclass{minimal}
 >
 > \edef\agrave{\`a}  % Doesn't work
 > \setbox0\hbox{\`a} % We use an accent
 > \edef\agrave{\`a}  % Now it does work (but \agrave looks horrible! :-)
)

My apologies -- there is a missing line. It should read:

\documentclass{minimal}

\normalsize

\edef\agrave{\`a}  % Doesn't work
\setbox0\hbox{\`a} % We use an accent
\edef\agrave{\`a}  % Now it does work (but \agrave looks horrible! :-) )

since minimal, unlike other classes, doesn't use \normalsize (it just
defines it). Of course, without \normalsize \cf@encoding remains empty
and \OT1-cmd calls \?\`. Anyway, I didn't intend to make a point
against \protect, but just to note that there was a bug in the LaTeX
kernel.

As far as \protect is concerned, I wonder if bad designed packages
should be fixed from the LaTeX core.

My main trouble with \protect is of a different nature. I think that
the expansion of a protected command should be the command itself
without the preceding \protect. Sometimes it is necessary to fetch
the next token (that's not the LaTeX way, but sometimes is the only
solution) and the \protect can be obtrusive. Of course, we may say
something like:

get next token
if it is \protect
  go to beginning
else
  do something
fi

but that's a bit annoying, and sometimes doesn't work because the
fragile variant--that preceded by \protect--has a different name.
In other words, if we make robust a command, we might make fail
another command.

This problem led me sometime ago to investigate an alternative to
\protect, with no success. But a small (perhaps not so small)
change perhaps could increase the robustness at this respect. Instead
of protecting the fragile command, we could protect the command itself.
I mean something similar to:

\def\protected{%
  \ifcase\protect@status   % a label depending on the context
    \expandafter\noexpand  % case protected
  \or
    \expandafter\string    % case output
  \or
    \expandafter\doitnow   % case typeset
  \fi}

\def\doitnow#1{\csname fragile\string#1\endcsname}

\def\foo{\protected\foo}
\@namedef{fragile\string\foo}{... the actual definition of foo ...}

This is the basic idea, which must be improved. This is conceptually
the current procedure implemented in a different way, which means,
of course, that it doesn't make \protected@edef unnecessary. (That's
just a digression on the main topic.)

Regards
Javier bezos