On Mon, May 14, 2018 at 11:51 AM, Richard Kimberly Heck <rikih...@lyx.org> wrote:
> On 05/14/2018 01:28 PM, Jürgen Spitzmüller wrote: > > Am Montag, den 14.05.2018, 13:18 -0400 schrieb Richard Kimberly Heck: > >> I've been thinking about this, too, and had come to a somewhat > >> similar > >> conclusion, though not with nearly as much detail. I.e., it seemed to > >> me > >> that there was something wrong with how the parents were being > >> assigned > >> when we clone. Unfortunately, there is a reason that we clone from > >> the > >> master: There may be macros defined there that are needed in the > >> child. > >> (See 2d6173d8103.) It may be that we should have said that wasn't a > >> bug: > >> If you view only the child, then you shouldn't expect macros defined > >> outside it to work. Maybe the include_only support allows people to > >> do > >> what they were trying to do here by viewing only the child? > > That's definitely wrong. A child compiled standalone should not inherit > > anything from a parent. This opens up for all sorts of bugs. > > > >> It seems to me that, in some ways, this is tied up with different > >> understandings people have of the master-child relationship, and what > >> it means to view "only the child". > > Maybe. But "Viewing the child" is actually not what is the case here. > > It's not a child in that case (we have includeonly support for that > > case). > > Yes, I agree, but I think that's how people often think of it. They're > not really treating the child as a standalone document. They just want > to see the PDF of that chapter (say), and not the whole thing. I think > that must be what Joel is doing. Certainly Chapter 1 is not going to be > a standalone document. (Joel, tell me if I'm wrong.) As you say, the > right way to do that is to use the includeonly stuff. But I'm guessing > Joel isn't the only person who would try to 'view only one chapter' this > way. > > 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. > > 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....) > > Riki > > I appreciate the time invested and technical back-and-forth discussion on my behalf. What's below doesn't add much (if anything) to the discussion, but some thoughts regarding how I got myself to where I am vs. what others might encounter: - Riki is correct; the dissertation will be a single multi-chapter document in the end. However, there is an overriding concern that compels me to render individual chapters. Several chapters are very equation heavy (with each equation quite long), so only by rendering can I confirm that the equations lay out in a sane way. Limiting the scope of rendering allows for faster rendering (some chapters are image and/or TikZ heavy and are slow to render regularly). - Because of the equation layout concern and the need to conform to university formatting requirements, I want to be sure all preamble customizations are universally available to the whole document or its individual parts (without me having to keep settings across multiple files in sync). This is why I have a preamble.tex called in to each file rather than having some form of down-propagation from the parent to the child(ren). - As I render each chapter (while I'm working on it) I want to have a bibliography and nomenclature listing in each chapter. This keeps things in context. This is also helpful as I provide chapters to others for review. However, for the full document, I only want one nomenclature (near the beginning) and one bibliography (near the end). - My thought was that branches with includes could accomplish these goals while minimizing or eliminating the amount of things I'd need to change if I update something as I'm working in a child. For those changes, I want to have the change "trickle up" to the parent without having to attend to the parent at that very moment. Example: I need to define a new color name for a TikZ image I'm preparing in a child. I'd rather just open an external "include" file in an editor to define it and know that change will then be applied to the parent and all children. I'm not sure where this desire/approach puts me on the "typical user" spectrum. I also suspect there are better ways to have accomplished this. Bottom line: the rendering of faithfully reproduced, globally shared, document customizations (at either the parent or child-chapter level) is the driving factor behind the document's "features." I hope the above helps you understand my use case and underlying considerations. Thanks, Joel
