On Tue, Oct 23, 2007 at 09:49:56PM -0400, Richard Heck wrote: > > In reworking the InsetCommand stuff, I've run into the following > problem. Each InsetCommand needs to have an InsetCommandParams to > represent its parameters. At present, it is assumed that the parameters > an InsetCommand accepts are determined statically, by the C++ type of > the inset. For various reasons, this is not a good assumption. (See > below.) So we need to allow InsetCommand's to say what parameters they > want dynamically. Now, to some extent, this is relatively easy, and > there is code in my personal branch, which I'll commit shortly, that > moves in this direction. But there is a problem here, and I'd welcome ideas. > > Even with the changes I'm making, it is essentially assumed that the > parameters an InsetCommand accepts are determined by (a) its type and > (b) the command it represents. So what we have is (more or less) a routine: > static ParamInfo InsetFoo::findInfo(std::string cmdName); > which returns info about the acceptable params, depending upon the > command name. But what parameters are acceptable may not be wholly > determined by the command name. The two crucial cases are InsetCitation, > where the acceptable parameters can also depend upon the CiteEngine in > use (which itself will shortly become user definable, I hope), and a > hypothesized InsetCommandCustom, which would be the InsetCommand > equivalent of InsetFlex, i.e., something that would allow user-definable > command insets (see bug 4066). Indeed, there is another problem, in both > cases, namely, that the code assumes that the commands an inset can > represent depend only upon its C++ type, but let me not discuss that, as > it's essentially the same problem. > > Now, so far as I can see, the un-handled variable here is the current > Buffer. The Buffer will determine the CiteEngine; and if we have > user-defined InsetCommand's, those too will be fixed by the Buffer > (i.e., by the text class and modules). So what we really need is to be > able to determine the current buffer inside InsetFoo:findInfo. Since > this is static, I take it we aren't likely to do that, so perhaps what > is needed is the option of passing the Buffer as argument to findInfo. > But this is also problematic, as findInfo is called from > InsetCommandParams, and so far as I can see there is no way to determine > the current Buffer from inside InsetCommandPararms. We can get at that > when InsetCommandParams is constructed, perhaps, so maybe that is the > solution: Either to pass it or to determine it at construction-time, > somehow. But maybe there are other possibilities I'm not considering. > > Anyway, maybe that's enough to give a sense of the problem. Ideas, and > questions, more then welcome.
Would it help if all insets knew the buffer they belong to? Andre'
