Am Montag, den 14.05.2018, 13:51 -0400 schrieb Richard Kimberly Heck: > So probably 2d6173d8103 was a mistake: We should just have said that > you > can't do that. But that was before the includeonly support, I > believe, > so maybe it made sense then? I'm not sure.
Note that it does not work anyway. Since we do what we can do dis- couple such a non-output parent in the latex output routine (via ignore_parent), the math macros are in fact _not_ inherited in standalone situations! Since nobody complained about that during the last years, I wonder whether this is really such a widespread usage. Anyway, currently our code contradicts itself: clone tries to include non-relevant parents, and the latex routine does everything it possibly can to revert that -- with a mixed result. This is a betwixt-and-between situation that does not help anybody, and leads to bugs that are hard to identify (such as this one). So can we please, please, cleanly separate those buffer from the start? > I wonder if it would help people here to have some LFUN that would > allow > one to "view only the child" in the way people want. What it would > do, > basically, is includeonly the current Buffer and its descendants, > then > view that. I.e., you wouldn't have to go to the master, fiddle with > those settings, and then view. So it would work kind of like > master-buffer-view, but take care of the includeonly stuff for you. > Then > again, that might not work in a lot of cases. E.g., you might need to > include the bibliography always---which is why Joel has that complex > ERT. (But then maybe there could be a setting for that? But maybe > that > gets too complicated....) Sure, we can try and improve the includeonly UI. As for the math macros, though, I think the problem is a fundamental design flaw of math macros UI: they need to be defined in the main workarea currently, rather than in a sort of preamble that could be inherited by children _at wish_. I think implementing that would not be that hard now that we have the embedded workarea widget. A workaround for the moment is to define math macros in a separate file and input that at each buffer that needs them. I think people should do that. UI wise, I think something to ponder would be a kind of "common settings" (math macros, branches, and other things) that could be shared by a family of documents, notwithstanding whether they have a parent-child relationship or not. Something like Pavel's graphics group on a more abstract level. Jürgen > > Riki >
signature.asc
Description: This is a digitally signed message part