Abdelrazak Younes wrote:
> No, multiple nested include won't be allowed in my described scheme so
> by default a document would be opened using a MasterBuffer and any child
> document in a normal Buffer. Or we can inverse the naming if you want:
> by default use a Buffer class and child documents would use a ChildBuffer.
> But, as I said, I am not sure the multiple level of nested document is a
> bad feature. I just think it is bad practice in my particular usage.
> There might be some people that think otherwise.
I think this usage is useful in a number of cases. I don't think that we
need to change anything here, the master-child mechanism works well except
for one case: You can get problems if you open a child without the master,
because in this case we don't know that it is a child document: Missing
preamble parts, broken bibliography, unresolved labels for example.
This is however unrelated to a possible MasterBuffer class, and for now we
simply say that master-child features are only available if a child doc is
opened from the master doc.
>> One rather radical approach I've been things about is to redefine
>> Buffer::params() like:
>>
>> BufferParams & Buffer::params()
>> {
>> return getMasterBuffer()->pimpl_->params;
>> }
>>
>> This would mean that only the master's params are visible, but it may
>> have a lot of strange side effects...
>
> I think now is as good time as ever to do this. It makes a lot of sense
> to me.
I am not sure. For example, it should not be possible to modify the master
buffer parameters through the child doc. People who want to change the
paramers of a child doc would suddenly change the parameters of the master
without knowing. And yes, changing the parameters of a child doc makes
sense, ask Helge.
Therefore we should only modify the const version, but it will also lead to
problems if it is different from the non-const version.
Georg
