On Thursday 04 March 2010 08:41:08 am rgheck wrote:
> On 03/03/2010 06:07 PM, Manoj Rajagopalan wrote:
> > My bad: actually, lyx does in fact successfully parse the documentclass.
> > Only, during latex export, it doesn't allow any \listof<float>s except
> > for table and figure - at this point in InsetFloatList::latex(), these
> > are the only two builtin floats.
> >
> > But the Customization manual describes the LaTeXBuiltin parameter for
> > custom floats to be true if the documentclass defines the float - if not,
> > LyX will emit latex code to define the new float.
> >
> > Therefore, all floats defined by the documentclass should be allowed to
> > emit \listof<float>s as built-ins if this command is defined. Currently,
> > LyX even performs this check. I am attaching a patch that fixes this
> > problem. Requires only one additional line.
> >
> > Patch created from within src/insets
> >
> >> Index: InsetFloatList.cpp
> >> ===================================================================
> >> --- InsetFloatList.cpp (revision 33612)
> >> +++ InsetFloatList.cpp (working copy)
> >> @@ -128,6 +128,7 @@
> >> os<< "\\listoffigures\n";
> >> } else {
> >> os<< "%% unknown builtin float\n";
> >> + os<< "\\listof"<< type.c_str()<< "s\n";
> >> }
> >> } else {
> >> os<< "\\listof{"<< getParam("type")<< "}{"
>
> I'd like to hear from someone else who actually understands this float
> stuff: I never use it, so I'm not sure if this is the right way to do
> this. But let me ask this: Are we sure, in general, that the float type
> can always be used this way? Or might it be better to have something
> like this:
> ListCommand listofvideos
> in the float definition? Then you could also have:
> ListCommand listoftables
> and
> ListCommand listoffigures
> in the appropriate places, and skip these special checks altogether.
>
> If that seems a good idea, I can create this command. Or, if you'd like
> to learn a bit about layout stuff, you can do it. The place to look is
> TextClass::readFloat(), and then an appropriate member would need to be
> added to Floating.
>
> One other thing: We need to check the other uses of builtin() to make
> sure that the code can handle things other than table and figure. If
> this routine expects only those two things, then maybe other routines
> do, as well. There is such a check in
> LaTeXFeatures::getFloatDefinitions(), for example, and I have no idea if
> other builtins need similar treatment. Another place is in
> InsetFloatList::xhtml(), which was based on the latex output. Whatever
> we do for the latex, we can also do here, I suspect.
>
> rh
I agree with you in that a new ListCommand (maybe LaTeXListOfCommand?) is a
better idea - it is not necessary that documentclass creators adhere to this
ad-hoc nomenclature. For example, \listofpotatos could be \listofpotatoes
(notice the penultimate 'e'). Providing such a command will scale in future.
The "LaTeX" prefix in the optionname disambiguates the intent (command could
very well mean lyx command esp. since the value of this option won't have
a '\' prefix to indicates its latex-ness).
I can work on the patch - I am having fun learning lyx and the pointers you
have given will certainly help.
About builtin() - the code and documentation must agree. The documentation
(UserGuide appendix on menu items) says "built-in" is something defined by
the document class but the code doesn't seem to honor this 100%. Since table
and figure are latex fundamentals, maybe it would make sense to
distinguish "isLatexPrimitive()" from "builtin()" ? latex-primitive =>
built-in but not the other way.
-- Manoj
