Re: SIGSEGV crahsed
On Tue, Feb 14, 2017 at 10:09:14PM -0500, Scott Kostyshak wrote: > On Wed, Jan 11, 2017 at 09:25:39PM -0500, Scott Kostyshak wrote: > > On Thu, Dec 08, 2016 at 12:53:16AM +0100, Patrick Dupre wrote: > > > Hello Scott, > > > > > > Tonight, I could not reproduce the crash!! > > > > > > I could not find a lyx-dbg for fedora; > > > I guess that it should be lyx-debuginfo, but there is not > > > package available. I guess that I need to recompile the package to > > > get one! > > > > Hi Patrick, > > > > Can you reproduce the crash or did it mysteriously disappear on latest > > master? > > Hi Patrick, > > If you can still reproduce on recent master can you please open a bug > report on trac? Hi Patrick, I just want to make sure you received my emails pasted above (I think the list might have been down). Best, Scott signature.asc Description: PGP signature
Re: User template directory
Dear Helge, On 2017-02-28, Helge Hafting wrote: > Den 21. jan. 2017 09:35, skrev Jürgen Spitzmüller: >> It has been brought up repeatedly, and I've looked into it several >> times. The problem is that, astonishingly, there is no straightforward >> way to add custom items to Qt's "places" widget (the "directory panel >> on the left"). > Well, is it possible to add/change a pushbutton on the top instead? > There is already "Documents" which uselessly takes me to the home > folder, and "Templates" that gives me the folder with LyX templates. > The "Templates" button is useful, it gives me all the templates > distributed with LyX. > Could the "Document" button be changed so it brings up > "~/.lyx/templates/" instead of just "~/"? And perhaps with a caption > like "Private templates" instead of "Documents"? > The un-changeable directory panel on the left already has the home > folder ready, so no need to have a button for that. > Newbies don't notice, but as soon as you use LyX so much that you create > your own template documents, this becomes a problem. The proper place > for a private template is ~/.lyx/templates (at least on linux), but it > is only accessible by typing the path. You can change the expansion of the buttons in Tools>Preferences>Paths. I set the Document templates path to ~/.lyx/templates and in this directory I added a symlink to the standard templates path. This way, both standard and private templates are easily available. Also, I changed the "Documents" path to a subfolder with my lyx documents... > "Save As" is even worse. Clicking "Templates" make one think that this > is how you save a template for future use. But it brings up > /usr/share/lyx/templates/ where users don't have write access. (And they > should not have either.) It'd be much better if "Save As..."->Templates > gave us ~/.lyx/templates/ There is no need to bring up the LyX template > folder in the save dialog. Also solved after setting Tools>Preferences>Paths. Günter
Re: EmDash Problems (patch)
On 2017-02-28, Enrico Forestieri wrote: > On Mon, Feb 27, 2017 at 10:39:25PM +, Guenter Milde wrote: >> On 2017-02-27, Enrico Forestieri wrote: >> >> > At this point we have two simple alternatives. Either the above one or >> >> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg198615.html >> >> Both have serious drawbacks. See #10543. >> > TL;DR >> Sorry, but forcing a simple but insufficient patch to a complex problem >> because the description is too long is not the right thing. > You make it complex. We output latex and thus should follow latex rules. ... > Since ever LyX was outputting -- and --- and nobody was complaining > (I am not speaking about text or html output, which are different). >From the lyx-users list 2014: >https://marc.info/?l=lyx-users&m=140982011101908&w=2 In LaTeX, and therefore also in LyX, there are two types of en dash (and also two types of em dash). In LaTeX the first is entered by -- and the second is entered with \textendash. In LyX the first is entered with -- and the second is entered by putting the unicode en dash in (in my reply to Rich I listed three ways to do this, and Jerry's Mac technique is doing the same thing). It's not quite clear to me which is the "correct" way to do this. -- is older, and \textendash was introduced so that it can work with more fonts (or something like that). But as Jerry has noticed, they also have different line breaking properties. It sounds like the ability of -- to create a line break was just a side effect of its implementation rather than intended. Maybe it was suppressed from \textendash because it's so easy to turn back on when needed. Unfortunately, during the 2.1->2.2 change the differences between the two representations were not taken into consideration. As a result, there is now only one representation in the LyX source files. > Now LyX outputs \textendash and \textemdash and this is causing problems. > What is the conclusion? Outputting -- and --- would solve some problems and create new ones: A literal EM DASH allows hyphenation in the word before the dash Three alkali metals are the usual sub- stituents—sodium, potassium, and lithium. while the ligature prevents hyphenation in the word before the dash: Three alkali metals are the usual substituents— sodium, potassium, and lithium. See also https://www.lyx.org/trac/raw-attachment/ticket/10543/dash-problems.lyx https://www.lyx.org/trac/raw-attachment/ticket/10543/dash-problems-non-tex-fonts.lyx You get the same problem -- overfull lines -- with both approaches. So while curing some documents you break others. OtOH, with EM DASH + ZWSP, hyphenation in the preceding word is allowed as are line breaks after the dash. Günter
Re: Should LaTeX output from command line be equivalent to GUI?
On Wed, Mar 01, 2017 at 07:04:05PM +0100, Kornel Benko wrote: > > cd lib/doc/es > > lyx -E luatex UserGuide_CL.tex UserGuide.lyx > > lyx -x "command-sequence buffer-export luatex" UserGuide.lyx > > # exit LyX. > > diff UserGuide_CL.tex UserGuide.tex Kornel, since it seems this did discover a potential issue, what do you think about us making tests for this? Because these do not seem as useful as the export tests and because they require a GUI, perhaps the tests could be disabled by default and the release manager could just run them before releases or something like that. On the other hand, since it is just about exporting LaTeX (and not compiling), perhaps the tests are cheap to run. Scott signature.asc Description: PGP signature
Re: Should LaTeX output from command line be equivalent to GUI?
On Wed, Mar 01, 2017 at 07:05:36PM +0100, Jean-Marc Lasgouttes wrote:
> Le 01/03/2017 à 18:42, Scott Kostyshak a écrit :
> > > It gives me the following output:
> > >
> > > 8548c8548
> > > < \settowidth{\nomlabelwidth}{"@, "|, "!, ""}
> > > ---
> > > > \settowidth{\nomlabelwidth}{May�sculas}
> >
> > Can anyone reproduce?
>
> I did not try to, but the reason is obvious: this is InsetNomencl code,
> where \nomlabelwidth is set to the width of the larger entry. This width
> uses the width seen on screen if there is a GUI (which does not make sense!)
> and the string length otherwise.
>
> Looking at nomencl's documentation, I think that we should not set
> \nomlabelwidth, but instead add a width option to InsetNomencl and pass it
> to \printnomenclature (as optional argument).
>
> The other simpler solution would be to remove this hack. The only problem is
> that this will change the display of existing documents.
OK so if we do this it would be for master only, and we should put
something in the release notes.
Thanks for figuring out the issue,
Scott
signature.asc
Description: PGP signature
Re: local layout file + relative inputs?
On 03/01/2017 03:45 AM, Enrico Forestieri wrote: > On Tue, Feb 28, 2017 at 06:42:24PM -0500, Richard Heck wrote: >> Very nice, thank you! If you want to commit to master, I will cherry >> pick it for 2.2.3. > Done at 17ab47b3. Cherry picked at 2b9965ae, so this will be in 2.2.3. Richard
Re: Should LaTeX output from command line be equivalent to GUI?
Am Mittwoch, 1. März 2017 um 12:42:14, schrieb Scott Kostyshak
> On Tue, Feb 21, 2017 at 02:40:42AM -0500, Scott Kostyshak wrote:
> > On Tue, Feb 21, 2017 at 02:07:13AM -0500, Richard Heck wrote:
> > > On 02/20/2017 09:41 PM, Scott Kostyshak wrote:
> > > > Is it a bug if our LaTeX output is different when exporting from the
> > > > command line, versus exporting from the GUI? That is, are there some
> > > > cases where we expect them to be different, and if so, are these
> > > > documented?
> > >
> > > This is definitely a bug, I'd say.
> >
> > I get different output for the Spanish UserGuide.lyx.
> >
> > # I can only reproduce with the Spanish version
> > cd lib/doc/es
> > mylyx master -E luatex UserGuide_CL.tex UserGuide.lyx
> > mylyx master -x "command-sequence buffer-export luatex" UserGuide.lyx
> > # exit LyX.
> > diff UserGuide_CL.tex UserGuide.tex
>
> More portable ("mylyx master" -> "lyx") code to reproduce:
>
> cd lib/doc/es
> lyx -E luatex UserGuide_CL.tex UserGuide.lyx
> lyx -x "command-sequence buffer-export luatex" UserGuide.lyx
> # exit LyX.
> diff UserGuide_CL.tex UserGuide.tex
>
>
> > It gives me the following output:
> >
> > 8548c8548
> > < \settowidth{\nomlabelwidth}{"@, "|, "!, ""}
> > ---
> > > \settowidth{\nomlabelwidth}{May�sculas}
>
> Can anyone reproduce?
Yes but the difference line is 8547c8547.
> Scott
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: iconv error with listing + Spanish
On Wed, Mar 01, 2017 at 05:35:45PM +, Guenter Milde wrote: > This confirms it as an instance of #9871 (or related to it). Good, I added the information to the ticket. Scott signature.asc Description: PGP signature
Re: export tests: superfluous regexes in *Tests
Am Mittwoch, 1. März 2017 um 17:32:20, schrieb Guenter Milde > On 2017-03-01, Kornel Benko wrote: > > > We have some dead corpses in out *Tests files. > > I am reluctant to remove them because of the nice comments. > > > Particularly the following regexes do not mach any possible test > > invertedTests: > > "export/examples/(|de/|es/)tufte-(book|handout)_(dvi.*|pdf|pdf3|pdf4.*)" > > It seems the problem with > # tufte (partially) incompatible with latex and xelatex: > # \MakeTextUppercase requires microtype. > # > http://tex.stackexchange.com/questions/202142/problems-compiling-tufte-title-page-in-xelatex > > is solved. So, if all "tufte" tests pass without inversion, remove comment > and pattern. > > > unreliableTests: > > "export/export/latex/cp858_pdf2" > > "export/export/utf8-plain-with-tex-fonts_(dvi|pdf.?)" > > Here, the first matches: > > lyxtest#> ctest -N -R cp858_pdf2 > Test project /usr/local/src/lyxtest > Test #294: UNRELIABLE.VARYING_VERSIONS_export/export/latex/cp858_pdf2 > In that case please commit cp858.lyx. No such file in repository. > while the second needs correction: > > -export/export/utf8-plain-with-tex-fonts_(dvi|pdf.?) > +export/export/latex/utf8-plain-with-tex-fonts_(dvi|pdf.?) > > I'll update this together with some other corrections. > ... Done. OK > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: Should LaTeX output from command line be equivalent to GUI?
On Tue, Feb 21, 2017 at 02:40:42AM -0500, Scott Kostyshak wrote:
> On Tue, Feb 21, 2017 at 02:07:13AM -0500, Richard Heck wrote:
> > On 02/20/2017 09:41 PM, Scott Kostyshak wrote:
> > > Is it a bug if our LaTeX output is different when exporting from the
> > > command line, versus exporting from the GUI? That is, are there some
> > > cases where we expect them to be different, and if so, are these
> > > documented?
> >
> > This is definitely a bug, I'd say.
>
> I get different output for the Spanish UserGuide.lyx.
>
> # I can only reproduce with the Spanish version
> cd lib/doc/es
> mylyx master -E luatex UserGuide_CL.tex UserGuide.lyx
> mylyx master -x "command-sequence buffer-export luatex" UserGuide.lyx
> # exit LyX.
> diff UserGuide_CL.tex UserGuide.tex
More portable ("mylyx master" -> "lyx") code to reproduce:
cd lib/doc/es
lyx -E luatex UserGuide_CL.tex UserGuide.lyx
lyx -x "command-sequence buffer-export luatex" UserGuide.lyx
# exit LyX.
diff UserGuide_CL.tex UserGuide.tex
> It gives me the following output:
>
> 8548c8548
> < \settowidth{\nomlabelwidth}{"@, "|, "!, ""}
> ---
> > \settowidth{\nomlabelwidth}{May�sculas}
Can anyone reproduce?
Scott
signature.asc
Description: PGP signature
Re: iconv error with listing + Spanish
On 2017-03-01, Kornel Benko wrote: > Am Mittwoch, 1. März 2017 um 11:35:45, schrieb Guenter Milde > >> On 2017-03-01, Scott Kostyshak wrote: >> >> > Note that this affects lib/examples/es/linguistics.lyx >> >> > >> >> > Can anyone else reproduce? Is the problem obvious? >> >> > >> >> > I can reproduce the issue on 2.2.0 and on master. I cannot reproduce on >> >> > 2.1.0. I can do a git bisect if someone thinks the time would be worth >> >> > it. >> >> Perhaps this is http://www.lyx.org/trac/ticket/9871 ? >> >> I inverted the affected test. >> Could you try whether export works with pdftex if the input encoding is set >> to ASCII? > Does not work here. Even lualatex cannot compile if encoding is set to ascii. This confirms it as an instance of #9871 (or related to it). > Setting to utf8 works with pdflatex and lualatex but not with xelatex. Yes, because xelatex ignores the inputenc setting and forces ascii. Thanks, Günter
Re: export tests: superfluous regexes in *Tests
On 2017-03-01, Kornel Benko wrote: > We have some dead corpses in out *Tests files. > I am reluctant to remove them because of the nice comments. > Particularly the following regexes do not mach any possible test > invertedTests: > "export/examples/(|de/|es/)tufte-(book|handout)_(dvi.*|pdf|pdf3|pdf4.*)" It seems the problem with # tufte (partially) incompatible with latex and xelatex: # \MakeTextUppercase requires microtype. # http://tex.stackexchange.com/questions/202142/problems-compiling-tufte-title-page-in-xelatex is solved. So, if all "tufte" tests pass without inversion, remove comment and pattern. > unreliableTests: > "export/export/latex/cp858_pdf2" > "export/export/utf8-plain-with-tex-fonts_(dvi|pdf.?)" Here, the first matches: lyxtest#> ctest -N -R cp858_pdf2 Test project /usr/local/src/lyxtest Test #294: UNRELIABLE.VARYING_VERSIONS_export/export/latex/cp858_pdf2 while the second needs correction: -export/export/utf8-plain-with-tex-fonts_(dvi|pdf.?) +export/export/latex/utf8-plain-with-tex-fonts_(dvi|pdf.?) I'll update this together with some other corrections. ... Done. Günter
Re: [LyX/master] Ignore missing glyphs in a test after TL update
On Wed, Mar 01, 2017 at 10:06:43AM +0100, Kornel Benko wrote: > Am Dienstag, 28. Februar 2017 um 23:12:35, schrieb Scott Kostyshak > > > On Wed, Mar 01, 2017 at 12:32:35AM +0100, Scott Kostyshak wrote: > > > commit 34d2f3cf06db9e5988d26ef45ac6b02cb23379e3 > > > Author: Scott Kostyshak > > > Date: Tue Feb 28 18:31:02 2017 -0500 > > > > > > Ignore missing glyphs in a test after TL update > > > > > > After a TL 2016 update, a test started to fail due to missing > > > glyphs. For more information, see the ML thread here: > > > > > > > > > https://www.mail-archive.com/search?l=mid&q=20170225203955.nas2qopy4l4ukyqq%40steph > > > > The test still fails for me. I tested manually and the missing glyphs > > are the only errors I get. What else should I do? > > > > Scott > > Regexes in *Tests have to be specified for the whole test-names. Thanks for fixing it. Tested and works well. Scott signature.asc Description: PGP signature
Re: export tests: superfluous regexes in *Tests
On Wed, Mar 01, 2017 at 05:22:30PM +0100, Kornel Benko wrote: > We have some dead corpses in out *Tests files. > I am reluctant to remove them because of the nice comments. > > Particularly the following regexes do not mach any possible test > invertedTests: > "export/examples/(|de/|es/)tufte-(book|handout)_(dvi.*|pdf|pdf3|pdf4.*)" > unreliableTests: > "export/export/latex/cp858_pdf2" > "export/export/utf8-plain-with-tex-fonts_(dvi|pdf.?)" > > Günter, Scott, should we > 1.) comment them (e.g. add '#') > or > 2.) Remove together with the associated comment > ? I don't have an opinion. Let's see what Günter thinks. Scott signature.asc Description: PGP signature
Re: iconv error with listing + Spanish
On Wed, Mar 01, 2017 at 11:35:45AM +, Guenter Milde wrote: > 36b9645b is part of the fix to #9740 (XeTeX with TeX fonts). > (BTW: how do you get the content/description of a change-set given this > strange number only?) git show 36b9645b Does that do what you want? The number is referred to as the "short hash" of the git commit. Scott signature.asc Description: PGP signature
Re: iconv error with listing + Spanish
On Wed, Mar 01, 2017 at 11:41:50AM +, Guenter Milde wrote: > On 2017-02-28, Scott Kostyshak wrote: > > On Tue, Feb 28, 2017 at 02:07:38PM -0500, Scott Kostyshak wrote: > > >> Note that this affects lib/examples/es/linguistics.lyx > > >> Can anyone else reproduce? Is the problem obvious? > > >> I can reproduce the issue on 2.2.0 and on master. I cannot reproduce on > >> 2.1.0. I can do a git bisect if someone thinks the time would be worth > >> it. > > > Perhaps this is http://www.lyx.org/trac/ticket/9871 ? > > I inverted the affected test. > > > But that issue is not labeled as a regression. Why does the MWE work > > with 2.1.0? > > This is not a regression, as it always was a problem if the input encoding > is ASCII. > > The "regression" is due to the fact, that XeTeX with TeX fonts requires > ASCII input encoding and LyX enforces it since 2.2. > Try the file with 2.1 and inputenc manually set to ASCII. Thanks for this explanation, Scott signature.asc Description: PGP signature
export tests: superfluous regexes in *Tests
We have some dead corpses in out *Tests files. I am reluctant to remove them because of the nice comments. Particularly the following regexes do not mach any possible test invertedTests: "export/examples/(|de/|es/)tufte-(book|handout)_(dvi.*|pdf|pdf3|pdf4.*)" unreliableTests: "export/export/latex/cp858_pdf2" "export/export/utf8-plain-with-tex-fonts_(dvi|pdf.?)" Günter, Scott, should we 1.) comment them (e.g. add '#') or 2.) Remove together with the associated comment ? Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Fix coverity false positive
Le 01/03/2017 à 16:43, Jean-Marc Lasgouttes a écrit : commit dc385a8b97cfc0fcb1d7119655ea23688a567944 Author: Jean-Marc Lasgouttes Date: Wed Mar 1 16:41:37 2017 +0100 Fix coverity false positive The fall through was intended at db889bc6. Jürgen, could you confirm please? JMarc --- src/insets/InsetCitation.cpp |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/insets/InsetCitation.cpp b/src/insets/InsetCitation.cpp index b16077f..12044f5 100644 --- a/src/insets/InsetCitation.cpp +++ b/src/insets/InsetCitation.cpp @@ -149,6 +149,7 @@ void InsetCitation::doDispatch(Cursor & cur, FuncRequest & cmd) cmd = FuncRequest(LFUN_INSET_MODIFY, "changetype " + newcmdname); } } + // fall through default: InsetCommand::doDispatch(cur, cmd); }
Re: iconv error with listing + Spanish
Am Mittwoch, 1. März 2017 um 11:35:45, schrieb Guenter Milde > On 2017-03-01, Scott Kostyshak wrote: > > On Tue, Feb 28, 2017 at 06:24:51PM -0500, Scott Kostyshak wrote: > >> On Tue, Feb 28, 2017 at 02:07:38PM -0500, Scott Kostyshak wrote: > > >> > Note that this affects lib/examples/es/linguistics.lyx > >> > > >> > Can anyone else reproduce? Is the problem obvious? > >> > > >> > I can reproduce the issue on 2.2.0 and on master. I cannot reproduce on > >> > 2.1.0. I can do a git bisect if someone thinks the time would be worth > >> > it. > > >> Perhaps this is http://www.lyx.org/trac/ticket/9871 ? > >> I inverted the affected test. > > >> But that issue is not labeled as a regression. Why does the MWE work > >> with 2.1.0? > > > The commit that changed the behavior was 36b9645b. > > > Günter, can you confirm that the export just worked by chance (perhaps > > even bad output?) before, so that 36b9645b did not really break the > > export? I have a vague memory that this is the case, but I want to > > double-check. > > 36b9645b is part of the fix to #9740 (XeTeX with TeX fonts). > (BTW: how do you get the content/description of a change-set given this > strange number only?) # git show 36b9645b > Possible regressions due to the restrictions of XeTeX with TeX-fonts are > expected (and should be eventually handled) but don't outweigh the > benefits of the change. No reason to restore 2.1 behaviour. > > See also the similar discussion in https://www.lyx.org/trac/ticket/10199 > > Could you try whether export works with pdftex if the input encoding is set > to ASCII? Does not work here. Even lualatex cannot compile if encoding is set to ascii. Setting to utf8 works with pdflatex and lualatex but not with xelatex. > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: iconv error with listing + Spanish
On 2017-02-28, Scott Kostyshak wrote: > On Tue, Feb 28, 2017 at 02:07:38PM -0500, Scott Kostyshak wrote: >> Note that this affects lib/examples/es/linguistics.lyx >> Can anyone else reproduce? Is the problem obvious? >> I can reproduce the issue on 2.2.0 and on master. I cannot reproduce on >> 2.1.0. I can do a git bisect if someone thinks the time would be worth >> it. > Perhaps this is http://www.lyx.org/trac/ticket/9871 ? > I inverted the affected test. > But that issue is not labeled as a regression. Why does the MWE work > with 2.1.0? This is not a regression, as it always was a problem if the input encoding is ASCII. The "regression" is due to the fact, that XeTeX with TeX fonts requires ASCII input encoding and LyX enforces it since 2.2. Try the file with 2.1 and inputenc manually set to ASCII. Günter
Re: iconv error with listing + Spanish
On 2017-03-01, Scott Kostyshak wrote: > On Tue, Feb 28, 2017 at 06:24:51PM -0500, Scott Kostyshak wrote: >> On Tue, Feb 28, 2017 at 02:07:38PM -0500, Scott Kostyshak wrote: >> > Note that this affects lib/examples/es/linguistics.lyx >> > >> > Can anyone else reproduce? Is the problem obvious? >> > >> > I can reproduce the issue on 2.2.0 and on master. I cannot reproduce on >> > 2.1.0. I can do a git bisect if someone thinks the time would be worth >> > it. >> Perhaps this is http://www.lyx.org/trac/ticket/9871 ? >> I inverted the affected test. >> But that issue is not labeled as a regression. Why does the MWE work >> with 2.1.0? > The commit that changed the behavior was 36b9645b. > Günter, can you confirm that the export just worked by chance (perhaps > even bad output?) before, so that 36b9645b did not really break the > export? I have a vague memory that this is the case, but I want to > double-check. 36b9645b is part of the fix to #9740 (XeTeX with TeX fonts). (BTW: how do you get the content/description of a change-set given this strange number only?) Possible regressions due to the restrictions of XeTeX with TeX-fonts are expected (and should be eventually handled) but don't outweigh the benefits of the change. No reason to restore 2.1 behaviour. See also the similar discussion in https://www.lyx.org/trac/ticket/10199 Could you try whether export works with pdftex if the input encoding is set to ASCII? Günter
Re: [LyX/master] Ignore missing glyphs in a test after TL update
Am Dienstag, 28. Februar 2017 um 23:12:35, schrieb Scott Kostyshak > On Wed, Mar 01, 2017 at 12:32:35AM +0100, Scott Kostyshak wrote: > > commit 34d2f3cf06db9e5988d26ef45ac6b02cb23379e3 > > Author: Scott Kostyshak > > Date: Tue Feb 28 18:31:02 2017 -0500 > > > > Ignore missing glyphs in a test after TL update > > > > After a TL 2016 update, a test started to fail due to missing > > glyphs. For more information, see the ML thread here: > > > > > > https://www.mail-archive.com/search?l=mid&q=20170225203955.nas2qopy4l4ukyqq%40steph > > The test still fails for me. I tested manually and the missing glyphs > are the only errors I get. What else should I do? > > Scott Regexes in *Tests have to be specified for the whole test-names. Kornel signature.asc Description: This is a digitally signed message part.
Re: local layout file + relative inputs?
On Tue, Feb 28, 2017 at 06:42:24PM -0500, Richard Heck wrote: > > Very nice, thank you! If you want to commit to master, I will cherry > pick it for 2.2.3. Done at 17ab47b3. -- Enrico
Re: local layout file + relative inputs?
On Wed, Mar 01, 2017 at 08:16:47AM +0100, Ulrich Thomas Gabor wrote: > > Thanks for patching this! > By "relative to the document directory" do you mean the directory the lyx > file is in or the layout file is in? Because I think it should be relative > from the layout file. Yes, sorry, I meant relative to the layout file position. -- Enrico
