rgheck wrote: > In general, this would be very nice. You really have to hack things at > present to make the bibliography, for example, work. What's not clear to > me is how this works with, say, math macros present in the master. Does > the master automatically get opened when the child does? If not, then > the macros won't work until it does get opened.
No, it does not get opened, it gets loaded in the background. Since math macros use the master buffer mechanisms as well, they should work straight away. > > The approach is limited in that it assumes one fixed master, whereas a > > document might be included in different master files. > > > > > > Well, here's a possibility. As I understand it, the code works by > setting the parent when the document is opened. Now suppose If the child > is opened from a master. Can't we override the setting by calling > setParent() when the child has been opened? In fact, we probably DO > override that setting this way, already, because it's only after the > child has been opened that the parent can be set. That said, if the > master is being opened automatically when the child is opened, we may > end up opening a document you don't want or need; but if the parent got > set early enough, this would not be an issue. Maybe it just works? As said, the master does not get opened. It is just loaded in the background and set as parentBuffer. And if you load a child with a specific assigned master buffer from _another_ master via the include dialog, that one gets set as parentBuffer automatically (which is what you want AFAIU). > Anyway, if something like that did work, then you'd not so much have a > "fixed master" as a "default master", and that doesn't seem like a > problem at all. Good. Jürgen
