I'm looking now at re-working some of the code surrounding InsetCommand
and its derivatives. The motivation here is, ultimately, BibLaTeX
support and the possibility of user-definable---or, at least,
configurable---command insets, like InsetFlex provides for text insets.
In order for that to be possible, the hard-coding of the relationship
between LaTeX commands and insets needs to be broken. Each inset, on
this scheme, would know what kinds of commands it supports, and that
could change programmatically.
Here's an early question. InsetCommand insets are stored in LyX files
like this:
\begin_inset LatexCommand citet
key etcetc
\end_inset
more or less. So, in effect, the kind of inset this is is represented by
the command: LyX knows that it's an InsetCitation because citet goes
with InsetCitation. This is not unreasonable, but it does seem messy,
and it gets messier if you're depending upon the insets to tell you what
commands they accept. Suppose, for example, that we had user-definable
command insets, stored in a layout file or module, and suppose someone
wants to open the file, but doesn't have the layout bit. Then we can't
tell what kind of inset this is. More generally, note that if you have
user-definable command insets, then there's no guarantee that commands
map uniquely to insets.
You get the same problem with BibLaTeX. Proper support for BibLaTeX will
involve making bibliography "engines" definable by text files (that's
another project), much as layout now is---the point being that BibLaTeX
gives a great deal of control to the user, so that citation styles, etc,
can be defined using ordinary LaTeX rather than BibTeX's stack-based
language. So say you have a BibLaTeX citation style that defines the
command \mycite, and a corresponding LyX file that defines an "engine"
that understands it. If someone tries to open the file who doesn't have
that LyX file, then again we can't tell what kind of inset it is.
Other sorts of insets identify themselves explicitly:
\begin_inset ERT
...
\end_inset
What I'm suggesting is that command insets should behave the same way.
So we'd have:
\begin_inset Citation
command citet
key etctec
\end_inset
More or less.
The change should be fairly simple, both in the code and in lyx2lyx:
It's mostly a matter of file format, not so much of internal
representation. Internal code concerned with writing and reading will be
all that changes. This will significantly simplify factory.cpp's
readInset() routine. In particular, things like this:
// This strange command allows LyX to recognize "natbib" style
// citations: citet, citep, Citet etc.
// FIXME: We already have partial support for \\fullcite and
// the various \\footcite commands. We should increase the
// file format number and read these commands here, too.
// Then we should use is_possible_cite_command() in
// InsetCitation to test for valid cite commands.
if (compare_ascii_no_case(cmdName.substr(0,4), "cite") == 0) {
inset.reset(new InsetCitation(inscmd));
} else...
go away. Note that the issue with is_possible_cite_command() is
essentially the one I've been discussing: Right now, it's hardcoded; and
if it isn't, you might find yourself reading a LyX file that contains a
cite command you didn't know about, so you misread the inset.
Comments?
Richard
--
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
