Re: Math macros inside child documents
On 05/09/2011 10:22 AM, Diego Queiroz wrote: > I'm not sure if this is a bug report or a feature request. Probably the > second one. > > In LyX it's ok to define a Math Macro in a Master document and use it in a > child one. It's also ok to use math macros that are defined in a child and > use it in other child document. > > In both cases, I am able to view the Master document and it handles > everything perfectly. > > But if I do so, I am unable to compile the child document alone. > AFAIK the reason is simple: the child document doesn't have the math macros > defined on its scope. And it doesn't really matter if the default master > document is set or not. It simple doesn't work (at least, I don't know how > to do without insert the math macros "again", which in painful). > > My suggestion is to allow the generation of the childs alone. > While working in the document, it's normal to compile only parts of the > document instead of compile the whole set, so this feature would be very > handy. > If you ask to compile just the child, then you are asking to compile it as a standalone document, so it is no surprise that this does not work. If you want to compile just one chapter as part of a larger document, then you need to use the \includeonly support, accessible from Document>Settings. rh
Re: Math macros inside child documents
> > If you ask to compile just the child, then you are asking to compile it > as a standalone document, so it is no surprise that this does not work. > Exactly. :-) > If you want to compile just one chapter as part of a larger document, > then you need to use the \includeonly support, accessible from > Document>Settings. I was not aware of this feature. Thanks for the hint. But it is also painful to select the document I want to compile everytime. :/ When I am working in a document, I work on it as a standalone document, I don't handle with the Master document before I want to compile the whole set. Of course there are several workarounds, i.e you can create a document with all your macros and insert it on the beggining of all documents. This is a not so elegant solution, but it does the job. Probably one can suggest a better solution as well. But I really think LyX can do this automatically. Since LyX already stores all defined macros in somewhere for the editor, it is not so hard to dinamically include them in a document when needed. Cheers, Diego
Re: Math macros inside child documents
On 05/09/2011 11:05 AM, Diego Queiroz wrote: > >> If you want to compile just one chapter as part of a larger document, >> then you need to use the \includeonly support, accessible from >> Document>Settings. > I was not aware of this feature. Thanks for the hint. > It's new in 2.0.0. > But it is also painful to select the document I want to compile everytime. > :/ > When I am working in a document, I work on it as a standalone document, I > don't handle with the Master document before I want to compile the whole > set. > > Of course there are several workarounds, i.e you can create a document with > all your macros and insert it on the beggining of all documents. This is a > not so elegant solution, but it does the job. Probably one can suggest a > better solution as well. > > But I really think LyX can do this automatically. > Since LyX already stores all defined macros in somewhere for the editor, it > is not so hard to dinamically include them in a document when needed. > But what if you really want to compile it as a standalone document? People do this. Richard
Re: Math macros inside child documents
> > But what if you really want to compile it as a standalone document? > People do this. > > Richard > But if it was really a standalone document, I would have to unset master document property, right? Anyway, in my case, the problem is that my child document with the macros also define Nomenclatures. When I include it on all files and decide to generate the Master document, the list of Nomenclatures repeats its entries several times (obviously because the entry was indeed included several times). I am just looking for a more "user oriented behavior". I mean, "if I can see everything right on the screen, what's the problem?" This is how I feel about the current behavior. LyX is handling everything on the editor, since all math macros are interpreted correctly when I open any document, but I can't generate the file because of its internal structure. We should try to avoid consistency errors in LyX. If people decide to use ERT, we should expect unwanted behavior, but in a document using only LyX resources, it must never generate errors (or they should be rare, at least), doesn't matter what the user decides to do. Cheers, Diego
Re: Math macros inside child documents
On 09/05/2011 10:22 AM, Diego Queiroz wrote: I'm not sure if this is a bug report or a feature request. Probably the second one. In LyX it's ok to define a Math Macro in a Master document and use it in a child one. It's also ok to use math macros that are defined in a child and use it in other child document. In both cases, I am able to view the Master document and it handles everything perfectly. But if I do so, I am unable to compile the child document alone. AFAIK the reason is simple: the child document doesn't have the math macros defined on its scope. And it doesn't really matter if the default master document is set or not. It simple doesn't work (at least, I don't know how to do without insert the math macros "again", which in painful). My suggestion is to allow the generation of the childs alone. While working in the document, it's normal to compile only parts of the document instead of compile the whole set, so this feature would be very handy. Regards, --- Diego Queiroz This works like a charm for me on 1.6.9 right now. My setup is Thesis.lyx: Frontmatter stuff Include: LyX-macros.lyx Table of Contents List of Tables List of Figures Include: Chapter-1.lyx Include: Chapter-2.lyx ... Start Appendix here Include: Appendix-1.lyx BibTeX Generated Bibliography Each child doc has the default master document set to Thesis.lyx and I use a branch named "child only", which is activated in child docs but deactivated in the master, to include BibTeX bib in the childs. Math macros are defined in LyX-macros.lyx and are available when compiling each child individually without hassle. So, I do not experience your problem. However document settings and stuff that gets defined in the preamble need to be set in both master and child docs. -- Julien
Re: Math macros inside child documents
> > So, I do not experience your problem. However document settings and stuff > that gets defined in the preamble need to be set in both master and child > docs. > -- > Julien > Actually, the answer is: yes, you do experience the very same problem. Otherwise you won't need to go after a workaround, right? :-) As I said before, I'm sure there are several ways to workaround this limitation (I am not searching for one). I just think we should focus on make LyX avoid these errors by itself. Cheers, --- Diego
Re: Math macros inside child documents
On 09/05/2011 1:44 PM, Diego Queiroz wrote: So, I do not experience your problem. However document settings and stuff that gets defined in the preamble need to be set in both master and child docs. -- Julien Actually, the answer is: yes, you do experience the very same problem. Otherwise you won't need to go after a workaround, right? :-) As I said before, I'm sure there are several ways to workaround this limitation (I am not searching for one). I just think we should focus on make LyX avoid these errors by itself. Cheers, --- Diego Which workaround? You said math macros don't work within child docs, I say they work for me. No workaround necessary. There must be something in your setup that we're missing at the moment and prevents math macros for working. Maybe you mean that the math macros in your preamble don't work? Regards, Julien
Re: Math macros inside child documents
On 09/05/2011 1:44 PM, Diego Queiroz wrote: So, I do not experience your problem. However document settings and stuff that gets defined in the preamble need to be set in both master and child docs. -- Julien Actually, the answer is: yes, you do experience the very same problem. Otherwise you won't need to go after a workaround, right? :-) As I said before, I'm sure there are several ways to workaround this limitation (I am not searching for one). I just think we should focus on make LyX avoid these errors by itself. Cheers, --- Diego Hi Diego, Thinking about this again, I'm guessing that one of the "use x math package automatically" option doesn't get triggered and is the cause of your child doc compilation failures. If that is the case then yes, LyX should detect that automatically, and yes, at the moment a workaround is needed: check "use x math package" in document settings. Regards, Julien
Re: Math macros inside child documents
> > Which workaround? You said math macros don't work within child docs, I say > they work for me. No workaround necessary. > Maybe I misunderstood you. I was citing your workaround to include bibtex in the childs. >> "I use a branch named "child only", which is activated in child docs but deactivated in the master" Anyway, never mind. Sorry. Thinking about this again, I'm guessing that one of the "use x math package > automatically" option doesn't get triggered and is the cause of your child > doc compilation failures. If that is the case then yes, LyX should detect > that automatically, and yes, at the moment a workaround is needed: check > "use x math package" in document settings. > I just tested and this is not enough. I am not able to generate child files in LyX 2.0 at all. If I include a simple macro in a document (the master), create another file (the child), link them and use the macro in the child. The standalone child don't compile, only the master document. Are you able to do this in LyX 1.6? If so, this is a bug report and not a feature request. Can someone confirm this / create ticket? I've attached two files: the child and the master document. I can't compile the child document. Can you try? Cheers, --- Diego child.lyx Description: Binary data master.lyx Description: Binary data
Re: Math macros inside child documents
On 09/05/2011 2:23 PM, Diego Queiroz wrote: Which workaround? You said math macros don't work within child docs, I say they work for me. No workaround necessary. Maybe I misunderstood you. I was citing your workaround to include bibtex in the childs. "I use a branch named "child only", which is activated in child docs but deactivated in the master" Anyway, never mind. Sorry. Thinking about this again, I'm guessing that one of the "use x math package automatically" option doesn't get triggered and is the cause of your child doc compilation failures. If that is the case then yes, LyX should detect that automatically, and yes, at the moment a workaround is needed: check "use x math package" in document settings. I just tested and this is not enough. I am not able to generate child files in LyX 2.0 at all. If I include a simple macro in a document (the master), create another file (the child), link them and use the macro in the child. The standalone child don't compile, only the master document. Are you able to do this in LyX 1.6? If so, this is a bug report and not a feature request. Can someone confirm this / create ticket? I've attached two files: the child and the master document. I can't compile the child document. Can you try? Cheers, --- Diego Hi Diego, Yes I am able to do what you describe in 1.6. In your example child doc, you did not set the master setting, did you? But anyway, I corrected it and still in 2.1.0svn the compilation of the child is broken: Undefined control sequence \anymacro A bug. Regards, Julien
Re: Math macros inside child documents
On 05/09/2011 02:38 PM, Julien Rioux wrote: > > Yes I am able to do what you describe in 1.6. In your example child > doc, you did not set the master setting, did you? But anyway, I > corrected it and still in 2.1.0svn the compilation of the child is > broken: > > Undefined control sequence \anymacro > > A bug. > It's due to the fact that the clone of the child buffer has no parent. Enrico wins again. ;-) It would seem we must always clone the entire set of documents. I.e., start with: buf.masterBuffer()->clone(); or something to that effect. But then we need back a pointer to buf's clone, so clone() probably needs to return something like a map from Buffers to their clones. Note that, if we pass this around, we can perhaps avoid multiple clones of a single Buffer included multiple times, which I suspect we now have. Richard
Re: Math macros inside child documents
> > Yes I am able to do what you describe in 1.6. In your example child doc, > you did not set the master setting, did you? > Indeed. I was in a hurry and I forgot it. ;/ --- Diego Queiroz
Re: Math macros inside child documents
On 2011-05-09, Diego Queiroz wrote: >> But what if you really want to compile it as a standalone document? >> People do this. >> Richard > But if it was really a standalone document, I would have to unset master > document property, right? ... > I am just looking for a more "user oriented behavior". I mean, "if I can see > everything right on the screen, what's the problem?" > This is how I feel about the current behavior. LyX is handling everything on > the editor, since all math macros are interpreted correctly when I open any > document, but I can't generate the file because of its internal structure. > We should try to avoid consistency errors in LyX. If people decide to use > ERT, we should expect unwanted behavior, but in a document using only LyX > resources, it must never generate errors (or they should be rare, at least), > doesn't matter what the user decides to do. For truly consistent behaviour, we would have to disable stand-alone compilation of documents setting a master (except for "included" (vs. "input") documents). Günter
Re: Math macros inside child documents
Guenter Milde wrote: > For truly consistent behaviour, we would have to disable stand-alone > compilation of documents setting a master (except for "included" (vs. > "input") documents). Why this? I have many documents with a master set that get compiled stand- alone from time to time and should _not_ inherit anything from the master then. Jürgen
Re: Math macros inside child documents
On 2011-05-10, Jürgen Spitzmüller wrote: > Guenter Milde wrote: >> For truly consistent behaviour, we would have to disable stand-alone >> compilation of documents setting a master (except for "included" (vs. >> "input") documents). > Why this? I have many documents with a master set that get compiled stand- > alone from time to time and should _not_ inherit anything from the master > then. Because the OP complained that it is incosistent to show math-macro expansions in the child doc but not make them available in stand-alone compilation. The same argument would hold for references to sections, equations, tables and figures in other parts of the document. Actually, I regularly compile stand-alone child docs (to save time on checking the appearance in the output). I have set up a "stand-alone" branch for math-macros and bibliography and I can live with the question marks in the references. The above was just stating the "pure" solution to the OPs report. However, I vote to keep things as-is, because: "practicality beats purity". Just make it very clear in the documentation that parent-document features are non-available in the child if compiled stand-alone (without include feature) even if rendered in the LyX window - this is a feature. (After switching to LyX 2 I will try with the include feature.) Günter
Re: Math macros inside child documents
On 05/10/2011 09:09 AM, Guenter Milde wrote: > On 2011-05-10, Jürgen Spitzmüller wrote: >> Guenter Milde wrote: >>> For truly consistent behaviour, we would have to disable stand-alone >>> compilation of documents setting a master (except for "included" (vs. >>> "input") documents). >> Why this? I have many documents with a master set that get compiled stand- >> alone from time to time and should _not_ inherit anything from the master >> then. > Because the OP complained that it is incosistent to show math-macro > expansions in the child doc but not make them available in stand-alone > compilation. > > The same argument would hold for references to sections, equations, > tables and figures in other parts of the document. > > Actually, I regularly compile stand-alone child docs (to save time on > checking the appearance in the output). I have set up a "stand-alone" > branch for math-macros and bibliography and I can live with the > question marks in the references. > > The above was just stating the "pure" solution to the OPs report. > However, I vote to keep things as-is, because: "practicality beats > purity". > > Just make it very clear in the documentation that parent-document > features are non-available in the child if compiled stand-alone (without > include feature) even if rendered in the LyX window - this is a feature. > We did establish that this is a change from 1.6.x, where parent macros are written to the child. That was not intentional, and the behavior depends upon the setting of EXPORT_IN_THREAD. We can keep it as it is, but then we should make it consistent (and could remove useless code). Richard
Re: Math macros inside child documents
> > >>> For truly consistent behaviour, we would have to disable stand-alone > >>> compilation of documents setting a master (except for "included" (vs. > >>> "input") documents). > This is a strong restriction. With this, in a document with thousand of pages I will obligated to generate all pages? I do not agree. > > Actually, I regularly compile stand-alone child docs (to save time on > > checking the appearance in the output). I have set up a "stand-alone" > > branch for math-macros and bibliography and I can live with the > > question marks in the references. > This is another subject, but let's understand the question marks are a problem to be solved too. I think it would be good if LyX doesn't generate so much errors, but I vote against the generation of documents with "wrong" content (i.e. the question marks). Otherwise, LyX could not stop on the first error, as it already do today. That is, currently, if a error is found, LyX just stops and warns the user. Even if the document can still be generated by LaTeX. We didn't define LyX to "just continue and see what you get" because we don't want this, right? In the worst case, I'm in favor of a warning to the user about these "wrong" things. One reason is because I already submited a work with those "??". My fault indeed, but LyX could warn me anyway. ;-) > > Just make it very clear in the documentation that parent-document > > features are non-available in the child if compiled stand-alone (without > > include feature) even if rendered in the LyX window - this is a feature. > > > We did establish that this is a change from 1.6.x, where parent macros > are written to the child. That was not intentional, and the behavior > depends upon the setting of EXPORT_IN_THREAD. We can keep it as it is, > but then we should make it consistent (and could remove useless code). There are two things to note here: 1st: LyX interprets macros very well. It doesn't matter where they are (child/master/etc). If the documents are linked, LyX handles it in the screen. Fact. IMO, if it handles the content to the screen it should handle to the output. 2nd: AFAIK this feature was supported in later versions (I did not tested by myself, but people in this thread said it work). I won't be surprised if someone decide to stay with LyX 1.6 just because this "feature" was removed. Or just because "I am not able to compile my old doc anymore" or any other complaints. Cheers, --- Diego Queiroz
Re: Math macros inside child documents
On 2011-05-10, Diego Queiroz wrote: >> >>> For truly consistent behaviour, we would have to disable stand-alone >> >>> compilation of documents setting a master (except for "included" (vs. >> >>> "input") documents). > This is a strong restriction. But the only one for truly consistent behaviour. If you want to export stand-alone, uncheck the master setting. > With this, in a document with thousand of pages I will obligated to > generate all pages? I do not agree. No, you can *include* the sub-documents and use the includeonly feature to compile a subset of sub-documents where LaTeX will ensure (almost) correct page numbers and references and LyX will use the parent doc settings instead of the child-doc ones. >> > Actually, I regularly compile stand-alone child docs (to save time on >> > checking the appearance in the output). I have set up a "stand-alone" >> > branch for math-macros and bibliography and I can live with the >> > question marks in the references. > This is another subject, but let's understand the question marks are a > problem to be solved too. This is solved by using "include" and "includeonly" instead of stand-alone compilation. I do not think that LyX must re-implement this feature. > I think it would be good if LyX doesn't generate so much errors, Actually, *you* generate the error -- a reference to a label that does not exist in the document. Setting a master (currently) is just an "editing hint" but does not change the way a document is compiled stand-alone. Maybe there could be better visual feedback in LyX, but this requires that the buffer is aware of the intended use: a) compile the master b) compile the master but "includeonly" the child c) compile the child stand-alone Maybe a configurable default-action for the compile buttons (and View>... menu items) could trigger the matching feedback in the buffer. (With the default-default action for documents that set the master and are input-> a) are included -> b) ) > but I vote against the generation of documents with "wrong" content > (i.e. the question marks). Otherwise, LyX could not stop on the first > error, as it already do today. That is, currently, if a error is found, > LyX just stops and warns the user. Even if the document can still be > generated by LaTeX. We didn't define LyX to "just continue and see what > you get" because we don't want this, right? I am not sure about this. If I remember right, the LaTeX run is done in nonstopmode but the output not opened in a viewer -> I'd like a "show output anyway" button in the error message dialogue. Having a look at the output is sometimes far more helpful than TeX error messages. > In the worst case, I'm in favor of a warning to the user about these "wrong" > things. I prefer this "continue but warn", so that e.g. unresolved references [??] do not go unnoticed but do not prevent me from checking page breaks or the position of floats. ... Günter
Re: Math macros inside child documents
> > But the only one for truly consistent behaviour. If you want to export > stand-alone, uncheck the master setting. > Even if the master setting is not set in the child, LyX still display all macros perfectly if the master document is open. My complaint is this: if LyX is able to interpret things and display them in the editor, it should be able to generate the output. That's all. Specially if this problem is not present in older versions. No, you can *include* the sub-documents and use the includeonly feature > to compile a subset of sub-documents where LaTeX will ensure > (almost) correct page numbers and references and LyX will use the > parent doc settings instead of the child-doc ones. > What happens when you set the include only option? The whole document is generated and the pages are ommited or it handle the pages in a more fashioned way? I am asking this because, if LyX handles it in a good way, we can change the action of the view button of child docs to automatically generate the master document including only the active document. This appears suitable for me and is better than blocking. > Actually, *you* generate the error -- a reference to a label that does > not exist in the document. Setting a master (currently) is just an > "editing hint" but does not change the way a document is compiled > stand-alone. > If LyX options were consistent, it won't let me generate such errors. It doesn't really matter if I am responsible for them or not: computers are here to handle problems we don't want to deal with, right? They are not here to introduce another class of problems (although I agree this is not always true :-) . > I am not sure about this. If I remember right, the LaTeX run is done in > nonstopmode but the output not opened in a viewer -> I'd like a > "show output anyway" button in the error message dialogue. Having > a look at the output is sometimes far more helpful than TeX error > messages. > A "show output anyway" button would be great. However, if LyX consistency were assured, there's no need for it (expect when using ERT). --- Diego Queiroz
Re: Math macros inside child documents
On 2011-05-11, Diego Queiroz wrote: > [-- Type: text/plain, Encoding: --] >> But the only one for truly consistent behaviour. If you want to export >> stand-alone, uncheck the master setting. > Even if the master setting is not set in the child, LyX still display all > macros perfectly if the master document is open. This is a bug. (Around LyX 1.4, math-macros were resolved in any open buffer - related or not.) > My complaint is this: if LyX is able to interpret things and display them in > the editor, it should be able to generate the output. That's all. > Specially if this problem is not present in older versions. Oh no. If LyX is able to interpret a label defined in some other document but not in the current one, I would not expect this to work in LaTeX. Why should math-macros be different? >> No, you can *include* the sub-documents and use the includeonly feature >> to compile a subset of sub-documents where LaTeX will ensure >> (almost) correct page numbers and references and LyX will use the >> parent doc settings instead of the child-doc ones. > What happens when you set the include only option? > The whole document is generated and the pages are ommited or it handle the > pages in a more fashioned way? TeX \include is specially designed for the master/child concept. Read about it in the (La)TeX docs. http://www.tex.ac.uk/cgi-bin/texfaq2html?label=include > I am asking this because, if LyX handles it in a good way, we can > change the action of the view button of child docs to automatically > generate the master document including only the active document. This > appears suitable for me and is better than blocking. This was my suggestion for included documents setting a master, while input document setting a master would defaut to "compile/view/export master". However, I also suggested to use this as *defaults* - allowing the user to override the "consistent" behaviour in favour of flexibility. >> Actually, *you* generate the error -- a reference to a label that does >> not exist in the document. Setting a master (currently) is just an >> "editing hint" but does not change the way a document is compiled >> stand-alone. > If LyX options were consistent, it won't let me generate such errors. This is why I wrote what needed to be done for true/strong consistency: you cannot compile a *.tex document designed for inclusion as a stand-alone document. I prefer to live with some amount of inconsistency because otherwise I would have to use ERT for references to labels I know exist but LyX doesn't. > A "show output anyway" button would be great. > However, if LyX consistency were assured, there's no need for it (expect > when using ERT). ... or the LaTeX preamble or an outdated TeX distribution or a package combination with conflicts or ... Günter
Re: Math macros inside child documents
> > > A "show output anyway" button would be great. > > However, if LyX consistency were assured, there's no need for it (expect > > when using ERT). > > ... or the LaTeX preamble (1) or an outdated TeX distribution (2) or a > package > combination with conflicts (3) or ... (?) > > Günter > I repeat: if, and only if, LyX consistency were assured, there's no need for such option (except when using ERT). What means: 1) In LyX, the LaTeX preamble is an alternative to ERT but it has the same purpose. So any LaTeX code in LyX will always be a problem to consistency. If this is your point, I agree with you. 2) In an ideal scenario, LyX could check the LaTeX distribution to see what resources are available. So an outdated LaTeX should not be a problem. 3) Currently LyX already handles many known packages conflicts. Since all LyX resources are packages mapped to menu commands, every new package to be supported should be checked for possible conflicts with all the existent ones. When this is not possible, LyX should handle the problem in some way (like preventing the user of using them together). ?) Since these problems are solved, I cannot imagine another problem that is not related to ERT, file corruption and hardware problems. Otherwise, LyX can handle it. Actually, ERTs does exist only to keep LyX flexible, but the ERT goes against its proposal. Anyway, let's give up this discussion. It is leading to nowhere. We're flaming the mailing list. Sorry for this. --- Diego Queiroz
