I thought that the general design rule was that insets should not know
about the buffer that 'owns' them? So, things like:
string InsetInclude::Params::masterFilename_;
are just plain wrong by design? Moreover, the implementation is
currently broken. Witness not just the comment in clone(), but the
fact that I am triggering as assert playing with preview generation
of these include-d insets... Ok, I've traced that bug; now squashed.
So, question: should masterFilename_ be regarded as an inset property,
as it is now, or should it be a cached variable that is updated?
It is set currently in InsetInclude::localDispatch() as:
params_.masterFilename_ = cmd.view()->buffer()->fileName();
this seems redundant to me, given the fact that we already have the
ability to cache the BufferView.
So, my feeling is that the extra parameters in InsetInclude::Params
are not needed at all. Ie, both
Flags flag;
string masterFilename_;
can be determined on the fly, as and when necessary.
Just ramblings,
--
Angus
