> 1. Macro name clashes can be detected if lyx uses \newcommand.
> If a package uses the same macro name as one of the lyx macros, and
> macros are defined through \providecommand, lyx takes for granted
> that the macro exists and that it does the right thing. This maybe so
> in some cases (the cases where \providecommand is indeed to be used),
> but if the macro is wrong, bugs (maybe obscure bugs) arise.
Looking at my patch you see that we define LyX-specific commands that therefore have "lyx" in their
names (\lyxadded and the like). At the moment we use \newcommand, when there would be a package that
uses the same macro name as in our definitions, the document would be uncompilable. However this was
never reported at our bug tracker and I cannot remember a case on the mailing list.
> 2. The macros defined by lyx come before the user defined ones, so the
> user has anyway to use \renewcommand for changing the definition and
> thus \providecommand does not help here.
The future plan is to split the user preamble so that the user can decide what will be output before
and what after the LyX preamble. Georg proposed
http://www.lyx.org/trac/ticket/5031
For this feature we would have to switch to \providecommand to avoid to introduce a feature where
the user can also disable certain LyX command definitions.
I cannot see a drawback using \providecommand.
> 3. It is not clear to me how and why \providecommand helps with tex2lyx.
You are right, I was still thinking with my tex2lyx preamble handling that I
reverted some days ago.
There's another point: uniformity. For some definitions we already use \providecommand, for some
\newcommand. We should be more consistent if possible.
Jürgen, JMarc?
regards Uwe
