Am Freitag, den 11.05.2018, 21:44 -0600 schrieb Joel Kulesza: > LyX Developers, > > As I'm writing my dissertation, I've been using LyX 2.2.3 but today > decided to try migrating it to 2.3.0. Upon doing so, I encountered > what appears to be a regression (or else I've been doing something > invalid all along that 2.2.3 accepts without complaint).
I get the same problem with 2.2.3. It is a mystery to me why this works for you. > I cannot make the document available but I have a not-quite-MWE > available that I hope you could work with to see if you can reproduce > what I'm seeing with LyX 2.2.3/2.3.0 on two separate computers (macOS > 10.13.4 and OS X 10.11.6). If this can be reproduced and someone can > help me characterize this, I'm happy to file an item in the tracker. > > Steps to reproduce: > Clone https://github.com/jkulesza/UMich_Dissertation_LyX and checkout > the "lyx_mwe" branch. > Open dissertation.lyx in LyX 2.2.3. Render. This should succeed. > Right-click chapter_01.lyx -> Edit. Render. This should succeed. > Exit. > Open dissertation.lyx in LyX 2.3.0. Render. This should succeed. > Right-click chapter_01.lyx -> Edit. Render. This should fail with > the attached regarding being unable to find my .bst file. > At this point, I'm unsure where the problem lies (if it is indeed a > problem) so anything I'd file in the tracker is no more help that > what I'm filing here. > > As always, your help and time is appreciated! The story is long and complex. If you are not interested in the background but only in what I think the bug here is, jump to the last paragraph. The problem is as follows: bibliography.lyx is included both in dissertation.lyx and chapter_01.lyx (which is also a child of dissertation.lyx). This leads to bibliography.lyx claiming two "parent buffers", one of which at the same time is its grandparent, a setting which LyX is not (yet) prepared for (you also get a warning on the console because of that). Since only one parent is currently allowed, the last allocated one is the effective parent (in your case, it happens to be chapter_01.lyx, but read on...). This "effective" parent is used for inheriting specific settings and data to the children (e.g. for instant preview, source preview, labels for cross-referencing, bibliography data for citing, etc.). I call this type of parent "workarea parent" in what follows. The situation that chapter_01.lyx is the "workarea parent" is most probably not what you want, since I suppose you want to inherit settings and data from dissertation.lyx. We could (try to) always use the uppermost buffer in the hierarchy as "workarea parent" (if this can be determined), but ideally, we should allow for multiple parents and provide a way to select the "main" one that is used for workarea purposes (sometimes uppermost parents are just portmanteaus for specific purposes; think beamer handouts). However, this is a different bug ... But next to the "workarea parent", the is another (and sometimes different) kind of parent, namely the master document (henceforth called "output parent"). If you compile your MWE from dissertation.lyx, this file is the master document (output parent) and chapter_01.lyx and bibliography.lyx are its children. If you compile from chapter_01.lyx, however, this one is the master, with bibliography.lyx as child. In order to account for that, we try to completely cut the links from chapter_01.lyx to dissertation.lyx in that latter scenario (via the ignore_parent bool that is set on latex export). This makes chapter_01.lyx "output parent" of bibliography, or at least it is supposed to be so. Over the weekend, I tried to understand why this is not fully the case, i.e., why the BibTeX inset in bibliography.lyx, when compiled from chapter_01.lyx, has dissertation.lyx as its "output parent" (effecting in the wrong tmp dir location determined via masterBuffer()- >temppath()), even though we have explicitly cut the link from chapter_01.lyx upwards. I first thought that the "workarea parent" chimes in here, but that's not true, since as we saw above, "workarea parent" is (erroneously) set to chapter_01.lyx as well! And here is what I think to be the problem: a bug in the the buffer cloning logic. Buffer cloning is done for exporting buffers; all involved buffers are copied and then used for the export (this allows for editing the real buffers during export). When we do that cloning, the parents are newly assigned to the clones. And here's the problem: this is always done from the effective "workarea parent" of the buffer that is about to be processed (asyncBufferProcessing() calls cloneFromMaster(), which starts processing at masterBuffer()). So while exporting, which starts from the real "output parent", chapter_01.lyx, the parents are newly assigned to the whole family, and since dissertation.lyx is the workarea parent of chapter_01.lyx, dissertation.lyx is (wrongly) declared as (output!) parent of chapter_01.lyx _and_ bibliography.lyx, its second include. I say it's a logical flaw since, as I understand it, the buffer we start processing from (used_buffer in asyncBufferProcessing()) is actually always the real "output parent" (master document), no matter if it has another "workarea parent" or not. In fact, the attached patch fixes the issue with Joel's test files for me. It strikes me more logical than what we have now, but since I know very less about the cloning procedure, I am sure I miss something fundamental that is the reason of how cloning is done now. Riki, you are more familiar with this part of the code, so I am looking forward to your comments. Jürgen > > Thank you, > Joel
diff --git a/src/Buffer.cpp b/src/Buffer.cpp index 47db5f0552..ce75a1f84b 100644 --- a/src/Buffer.cpp +++ b/src/Buffer.cpp @@ -568,7 +568,7 @@ Buffer * Buffer::cloneFromMaster() const cloned_buffers.push_back(new CloneList); CloneList * clones = cloned_buffers.back(); - masterBuffer()->cloneWithChildren(bufmap, clones); + cloneWithChildren(bufmap, clones); // make sure we got cloned BufferMap::const_iterator bit = bufmap.find(this);
signature.asc
Description: This is a digitally signed message part
