Re: Bookmark Marker Weirdness
Am Montag, dem 05.04.2021 um 11:18 -0400 schrieb Richard Kimberly Heck: > > Anoother solution for 2.4.0: keep both codes hidden behind a pref > > \experimental_bookmarks_visibility with possible values NONE > > (default), INLINE and MARGIN. This pref would not have any GUI > > associated with it. > > I like that idea. I second that. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Concurrent processing of child documents?
I don't think this can be done, since LaTeX needs to run several times to first generated the "labels", run the bibliography, index and whatever, and then once or more again to get the references and page numbers right. I don't think different (child) knitR documents can "talk" to one single R instance, but need to fire up their own ones. That however can be easily tested. You can, in any case, compile individual child documents from LyX to PDF. For my handbook project (817 pages, 20 child documents) I "include" in the preamble a largish TeX file which does a lot of work so that individual child PDFs look presentable :-)-< but for for the referencing. el On 2021-04-05 18:01 , Scott Kostyshak wrote: > On Mon, Apr 05, 2021 at 05:18:40PM +0200, Jean-Marc Lasgouttes wrote: >> Le 05/04/2021 à 16:59, Scott Kostyshak a écrit : [...] > From what I understand, the parent .lyx file needs to get a .tex file > from each of its child .lyx files. In order to get a .tex file, the > knitr script needs to be run. > > It might be an interesting feature to basically "in-line" the LyX > child documents. I could imagine this being useful in some cases. In > my particular case, I actually like the modularity and keeping the > child documents independent. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Concurrent processing of child documents?
On Mon, Apr 05, 2021 at 11:20:22AM -0400, Richard Kimberly Heck wrote: > On 4/5/21 11:18 AM, Jean-Marc Lasgouttes wrote: > > Le 05/04/2021 à 16:59, Scott Kostyshak a écrit : > >> This is currently more of a theoretical question since I don't have > >> time to work on it. > >> > >> I'm working for the first time on a document with lots of child > >> documents. Export of the child documents is sequential. Is there a > >> reason they can't be processed concurrently? > >> > >> I'm guessing this isn't relevant for most users since export from LyX > >> to TeX seems pretty fast to me in most cases. What makes it slow in > >> my case is that the child documents use knitr, so to get the exported > >> TeX to be able to compile the parent an R script is run for each of > >> them. > > > > I do not understand: if you use knitr, each child potentially depends > > on the output of the previous ones. I am surprised actually that R is > > ran separately. I never thought about that, to be frank. > > That's an issue even with pure LaTeX, isn't it? Page and section numbers > at least will depend upon earlier documents, and there might be macros > in the earlier documents that are needed in later ones. Indeed, it might be interesting to consider a feature that would "in-line" child documents. This would allow a child document to use a macro that's defined in a previous child document. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Concurrent processing of child documents?
On Mon, Apr 05, 2021 at 05:18:40PM +0200, Jean-Marc Lasgouttes wrote: > Le 05/04/2021 à 16:59, Scott Kostyshak a écrit : > > This is currently more of a theoretical question since I don't have time to > > work on it. > > > > I'm working for the first time on a document with lots of child documents. > > Export of the child documents is sequential. Is there a reason they can't > > be processed concurrently? > > > > I'm guessing this isn't relevant for most users since export from LyX to > > TeX seems pretty fast to me in most cases. What makes it slow in my case is > > that the child documents use knitr, so to get the exported TeX to be able > > to compile the parent an R script is run for each of them. > > I do not understand: if you use knitr, each child potentially depends on the > output of the previous ones. Each chunk depends on the previous, but as you mention below, there is a separate R process for each child .lyx file. I believe this is intended. > I am surprised actually that R is ran > separately. I never thought about that, to be frank. From what I understand, the parent .lyx file needs to get a .tex file from each of its child .lyx files. In order to get a .tex file, the knitr script needs to be run. It might be an interesting feature to basically "in-line" the LyX child documents. I could imagine this being useful in some cases. In my particular case, I actually like the modularity and keeping the child documents independent. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Concurrent processing of child documents?
On 4/5/21 11:18 AM, Jean-Marc Lasgouttes wrote: > Le 05/04/2021 à 16:59, Scott Kostyshak a écrit : >> This is currently more of a theoretical question since I don't have >> time to work on it. >> >> I'm working for the first time on a document with lots of child >> documents. Export of the child documents is sequential. Is there a >> reason they can't be processed concurrently? >> >> I'm guessing this isn't relevant for most users since export from LyX >> to TeX seems pretty fast to me in most cases. What makes it slow in >> my case is that the child documents use knitr, so to get the exported >> TeX to be able to compile the parent an R script is run for each of >> them. > > I do not understand: if you use knitr, each child potentially depends > on the output of the previous ones. I am surprised actually that R is > ran separately. I never thought about that, to be frank. That's an issue even with pure LaTeX, isn't it? Page and section numbers at least will depend upon earlier documents, and there might be macros in the earlier documents that are needed in later ones. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Concurrent processing of child documents?
Le 05/04/2021 à 16:59, Scott Kostyshak a écrit : This is currently more of a theoretical question since I don't have time to work on it. I'm working for the first time on a document with lots of child documents. Export of the child documents is sequential. Is there a reason they can't be processed concurrently? I'm guessing this isn't relevant for most users since export from LyX to TeX seems pretty fast to me in most cases. What makes it slow in my case is that the child documents use knitr, so to get the exported TeX to be able to compile the parent an R script is run for each of them. I do not understand: if you use knitr, each child potentially depends on the output of the previous ones. I am surprised actually that R is ran separately. I never thought about that, to be frank. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bookmark Marker Weirdness
On 4/5/21 10:56 AM, Jean-Marc Lasgouttes wrote: > Le 05/04/2021 à 09:50, Jürgen Spitzmüller a écrit : >> Am Samstag, dem 03.04.2021 um 10:29 -0400 schrieb Richard Kimberly >> Heck: >>> I don't have a strong opinion. For what it's worth, I prefer the >>> bookmarks in the margins, rather than inline. They are not text >>> themselves, or related to text, so I find them distracting when >>> inline. >>> It would certainly help if they did not jump around, but I don't know >>> that it would help enough. >> >> I'm not a heavy bookmarks users either. I think I would prefer them >> inline, but maybe with a less salient appearance (smaller and with a >> pale color). >> >> If bookmark bugs are revealed by this feature, I think this is a good >> thing. >> >> As to show/hide: We have some long-standing requests for hiding non- >> printable items such as labels, index entries in the workarea. >> Bookmarks would probably just another one to be added to this list. > > Anoother solution for 2.4.0: keep both codes hidden behind a pref > \experimental_bookmarks_visibility with possible values NONE > (default), INLINE and MARGIN. This pref would not have any GUI > associated with it. I like that idea. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Concurrent processing of child documents?
This is currently more of a theoretical question since I don't have time to work on it. I'm working for the first time on a document with lots of child documents. Export of the child documents is sequential. Is there a reason they can't be processed concurrently? I'm guessing this isn't relevant for most users since export from LyX to TeX seems pretty fast to me in most cases. What makes it slow in my case is that the child documents use knitr, so to get the exported TeX to be able to compile the parent an R script is run for each of them. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bookmark Marker Weirdness
Le 05/04/2021 à 09:50, Jürgen Spitzmüller a écrit : Am Samstag, dem 03.04.2021 um 10:29 -0400 schrieb Richard Kimberly Heck: I don't have a strong opinion. For what it's worth, I prefer the bookmarks in the margins, rather than inline. They are not text themselves, or related to text, so I find them distracting when inline. It would certainly help if they did not jump around, but I don't know that it would help enough. I'm not a heavy bookmarks users either. I think I would prefer them inline, but maybe with a less salient appearance (smaller and with a pale color). If bookmark bugs are revealed by this feature, I think this is a good thing. As to show/hide: We have some long-standing requests for hiding non- printable items such as labels, index entries in the workarea. Bookmarks would probably just another one to be added to this list. Anoother solution for 2.4.0: keep both codes hidden behind a pref \experimental_bookmarks_visibility with possible values NONE (default), INLINE and MARGIN. This pref would not have any GUI associated with it. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Check for the -Wno-deprecacted-copy compiler option in cmake build
Am Sun, 4 Apr 2021 20:18:27 +0200 schrieb pdv : > On 03/04/2021 19:50, Kornel Benko wrote: > > Am Sat, 3 Apr 2021 18:13:17 +0200 > > schrieb pdv : > > > >> The Apple Clang compiler does not recognize the -Wno-deprecated-copy > >> compiler option. See thread "Re: warning: unknown warning option > >> '-Wno-deprecated-copy'" (8/10/2020) in this list. > >> > >> This was solved for the autotools build with commit 4aee447af1 > >> (13/10/2020). > >> > >> I've implemented a similar check for the cmake build. > >> > >> As is stands the patch unsets the test-variable from the cache and the > >> test is performed for each cmake-run. > >> I don't know what's the preferred policy and one should remove that line > >> to use the cached result instead. > >> > >> P. De Visschere > > > > Why was > > + unset(CHECK_WNODEPRECATEDCOPY_FLAG CACHE) > > necessary? > > > > Kornel > > > > > I inserted it just to be able to check that it worked; the test is logged: > > Performing Test CHECK_WNODEPRECATEDCOPY_FLAG > Performing Test CHECK_WNODEPRECATEDCOPY_FLAG - Failed > > Otherwise after running cmake once the check is never run again, until > one throws away the cmakecache.txt, which I try to avoid. > > I suppose that after time this check will be forgotten and if the issue > is solved (by an upgrade of the Apple clang compiler) this will pass > unnoticed. > > Probably the check takes little time and I thought it might be safer to > do it each time again. > > > P. De Visschere > OK, Patrick. Committed at fa704d50. Kornel pgpd88KDk01Ie.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bookmark Marker Weirdness
Am Samstag, dem 03.04.2021 um 10:29 -0400 schrieb Richard Kimberly Heck: > I don't have a strong opinion. For what it's worth, I prefer the > bookmarks in the margins, rather than inline. They are not text > themselves, or related to text, so I find them distracting when > inline. > It would certainly help if they did not jump around, but I don't know > that it would help enough. I'm not a heavy bookmarks users either. I think I would prefer them inline, but maybe with a less salient appearance (smaller and with a pale color). If bookmark bugs are revealed by this feature, I think this is a good thing. As to show/hide: We have some long-standing requests for hiding non- printable items such as labels, index entries in the workarea. Bookmarks would probably just another one to be added to this list. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
