On Thu, Jun 12, 2003 at 07:52:52PM +0000, Angus Leeming wrote:
> Hmmm. The nice thing about MathNestInset of course is that the data is
> stored so:
> typedef std::vector<MathArray> cells_type;
> cells_type cells_;
> so you can take advantage of generic components like the math parser.
>
> The nasty thing about insets/insetcommand.[Ch] is that it is hard-coded as
> string cmdname;
> string contents;
> string options;
> which means that it isn't very flexible. No one has had the energy to
> enhance the citation inset to handle natbib's second optional arg, for this
> very reason.
>
> It seems to me that there are two alternative strategies.
> i. Create new mathed insets citation_inset, bibtex_inset etc that take
> advantage of your clean, flexible code.
> ii. Change InsetCommand to store a std::vector<MathArray> and modify the
> derived insets appropriately.
>
> Which strategy would you recommend?
Well, there is no reason not to use a MathArray to store "plain" strings in
a MathArray if that makes I/O simpler. At least in "small insets", like
InsetCommand and derived things.
[For large chunks of text it is currently a real waste of RAM -- ~20
bytes per char IIRC. I have a patch reducing that to 4 bytes per char which
should be acceptable in the light of a transition to Unicode, but that's
not finished...]
When I think about it, (ii) seems to be the better option but its more
work. But most of it has to be done anyway:
- IU of Inset::clone() [Is simple now that the extra args are gone]
- Create a wrapper with value semantics for a 'Inset *' (much like
MathAtom is for 'MathInset *' nowadays
- [Drop MathAtom, use the unified wrapper in math]
- Create a container of these wrappers (like MathArray is of MathAtom)
- [Drop MathArray, use the unified container in math]
- Use this container everywhere.
It's all straight-forward stuff, but it will take more than five minutes...
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
