On 11/03/2010 4:12 PM, Jean-Marc Lasgouttes wrote:
Le 09/03/2010 14:00, rgheck a écrit :
I took a look at it and there are things like \...@expandtwoargs that I do
not understand. But Julien, if you are sure you know what you are doing
here, it is OK.
I can explain that particular line:
\...@expandtwoargs\in@{.}{\file}
I want to check if the macro \file contains the file extension or not,
so I check for a dot "." in it (this is the \in@ part; \...@expandtwoargs
is to expand the \file macro). If the extension is missing, it should be
appended to the filename.
This is because LyX's textclass declaration is flexible such as
\DeclareLaTeXClass[aguplus,agums.sty]{...}
The check for extension could be done with a latex package like xstring,
but LyX's configuration script should not rely on the users having this
package in their installation, hence the obfuscated TeX construct.
In the previous instance of the code, the check was to look for the
existence of \file. When this fails, look for \file + ".cls". When this
fails again, mark the textclass unavailable.
But now the aim is to record the missing dependency to textclass.lst,
and I ended up with lots of package.sty.cls and such, which is wrong. I
welcome a different suggestion.
By the way, I learned about \...@for from this code! Now somebody else can
learn about \...@expandtwoargs, maybe :)
Actually what should be done if you feel like it is to unify the
handling of layouts and modules. The availability of features is not
checked at the same place, which is a bit ridiculous.
Do you mean in configure.py, in chkconfig.ltx, or in LyX's code ?
JMarc
Cheers,
Julien
