Richard Heck wrote: > Here's why I don't want to assume that insets have fixed parameter > lists. Two use cases:
I believe there is a misunderstanding here. With "fixed parameter list" I do not mean a hardcoded list in the source. I do mean a list that gets read from some configuration file and is fixed only from the POV of an individual inset, not from the user's POV. The user could edit the configuration file (as a long term goal with some GUI) and define commands as needed. All what you want to do should be possible with such a fixed list. IMHO the text classes are pretty much the same thing: A buffer does store an index into the global text class list, but it does not have a copy that can be changed. Similaryly a paragraph does store a pointer to the style, but the properties of the style cannot be changed. The command params analogon of the text class would be the inset (e.g. citation inset), and the analogon of the paragraph style would be the actual command (e.g. \citet). > (i) Bibliography support. We need to move away from hard-coding > CiteEngines toward a more flexible sort of system. That's the next > project, and the one that matters on the user's end, and all of this is > cleanup to get ready for that. The point is that there's no telling in > advance what parameters a CiteEngine might want insets to take. Compare > jurabib and natbib, for example---let alone biblatex---and there's no > reason they all have to agree. They do not need to agree, but they have a fixed set of defined citation commands. They are currently hardcoded (which is bad as we all agree), but could be easily stored in a text file. I did not use biblatex yet, but as I understand it you can easily define your own citation commands. You somehow have to tell LyX how these commands are defined anyway (how should LyX know what alternatives to offer in the citation dialog otherwise?), so you can define these commands exactly like the jurabib and natbib commands, with the only exception that they have some additional preamble stuff. > (ii) Inset customization. We now allow for user-defined text insets, > thanks to Martin. I can see several cases where it would be nice to be > able to define my own InsetCommand, taking parameters I specify. These > would be read from layout files or, better, modules. That is exactly what I had in mind when I wrote "On startup, read the inset parameter definitions from a file and store them in a global table.". > So if you assume we're going that way, then the problem I mentioned > arises. True, we'll need to make sure that we don't get bad mixtures of > InsetCommand's and InsetCommandParam's. I'm hopeful that elements of > what I'm doing will help prevent that. In fact, I basically got started > on this because of a similar problem: that you could alter Param's an > inset expects from the minibuffer---not even from inside the code---and > thereby cause a crash. An invalid command-parameter combination from the minibuffer should of course be blocked with getStatus(). Then you don't get a crash. This is independant from the actual parameter implementation. > The solution towards which I'm working is to get > each inset to tell us what parameters it wants for each command with > which it might be associated. That is: > virtual ParamList InsetCommand::getParamList(std::string cmd); > replacing InsetCommandParams::findInfo(). Actually, findInfo will still > be needed, but it will just call InsetFoo::getParamList(), after > switch'ing on the InsetCode. And since each InsetCommandParam's now > stores the type of inset with which it's associated, as an InsetCode, > there's no possibility of mixing up which inset it goes with. > > Anyway, that's the plan. Looks good, but I suggest one small change: Make InsetCommand::getParamList static. IMHO it should be clear from the code that the parameter list of a given command is a global property that may not be changed for an individual inset, because this makes the code easier to understand. Such an implementation would also allow more easily to reread the command definitions without restart. This will be needed when there is a GUI for editing the parameter definitions. Georg
