On Fri, Aug 14, 2009 at 03:39:11AM +0200, Uwe Stöhr wrote: > > 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?
I still maintain that there is no valid reason ATM to indiscriminately switch to \providecommand. -- Enrico
