[l2h] Problem with \renewcommand

[Ross Moore]

> This illustrates the necessity for following latex2html Rule No 1
> 
>   \emph{Always} put command definitions in the document preamble
> 
> and Rule No 2
> 
>    Avoid the defining the same command twice wherever possible
> 
> These rules are actually quite easy to follow and eliminate a lot of
> latex2html problems. latex2html is not a full LaTeX engine and
> definitions need to be handled with care
> 

This is absolutely true for LaTeX2HTML, and may even become true for
LaTeX-3, or other programs which can be based upon LaTeX-3,
when it is released. (Some goodies are planned for next year.)

Note that  Ian's  \renewcommand  definition of \xyz  depends crucially
on the order of expansion used by TeX. Namely:

  \renewcommand{\xyz}{\textbf}  *requires* any instance of \xyz
to be followed by something that is a suitable argument for \textbf

e.g. 
  \xyz{Session}   (in the example).

Whereas with  \newcommand{\xyz}{abc def} it doesn't matter what
comes afterwards.


It so happens that both create legal TeX code, due to the dual nature
of {....} as interpreted by TeX:
 1. as an environment grouping
 2. as a single argument to a macro command

I can envisage future interpreters of LaTeX-like syntax that might well 
handle things quite differently; indeed LaTeX2HTML is close to this.
The new ideas proposed, and being implemented for the LaTeX-2e* 
(preparatory to LaTeX-3) will allow for a complete separation between
parsing of the user source, and the underlying typesetting engine.
So the possibility for such alternative interpreters is very real.

This makes it imperative to be very clear about the way any macro
that you define is intended to be used.



Having said that...

 ... LaTeX2HTML does *try* to reproduce the results that would
be expected from processing by LaTeX.
Indeed there was an error in the code that handled the substitution
generated by the \renewcommand  definition being used by Ian.
(It has taken several hours to track it down completely.)

The error only affected commands with arguments that have had their
definitions altered --- a circumstance rather rare, so not previously
encountered.

So...
 ... thanks Ian, your slap-dash coding has helped to uncover a real bug.
	;-) ;-)

However, I do indeed agree with Graham's points.

> Graham

	Thanks for the feedback guys,

		Ross Moore