Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Dear Kornel, dear LyXers,
sorry, there were typos in my last post
(On 2015-11-09, Guenter Milde wrote ...).
Trying again.
On 2015-11-09, Kornel Benko wrote:
> > Am Montag, 9. November 2015 um 15:50:09, schrieb Guenter Milde
> >> On 2015-11-09, Kornel Benko wrote:
> Thanks, I searched for attachment ...
> Applied.
> Running export tests ...
> Still 165 failed. Not really better.
The patch should disable XeTeX & TeX-fonts unless inputenc is explicitly
set to "ascii". Unfortunately, the patch does not work.
Even if it worked, most XeTeX tests would still fail, but it would be
better.
Intended behaviour:
* With the current default settings (use TeX-fonts, inputenc="auto"), the
XeTeX view/export is disabled.
+1 the fragile corner case with no advantage over pdflatex export is no
longer easier to reach than the "proper" use of XeTeX (with non-TeX
fonts).
* If the user sets Document>Settings>Language>Encoding to ASCII,
or Document>Settings>Fonts>use non-TeX fonts to True,
XeTeX export becomes accessible.
+1 the safe way to use XeTeX with TeX fonts works. So users who rely on
this exotic combination can still use it.
* Testing for XeTeX export with default document settings
(use TeX-fonts, inputenc="auto") will always fail ("no export route
found"), because we explicitly close this "fragile" export route.
+1 no false positives, no surprises.
We expect this combination to fail (similar to pdflatex + non-TeX fonts)
+1 default XeTeX+TeXF tests can safely be inverted.
Non-inverted XeTeX export tests would require documents with either
"inputenc" == "ascii" or "useNonTeXFonts" == "true".
Günter
No patch file for the major release, right?
I just want to confirm that we only publish patch files for minor releases and not for major releases. Is that correct? Scott
We now include both png and svgz?
When experimenting with building the tar balls, I noticed a significant difference in size between 2.2.0dev and 2.1.4. lyx-2.1.4.tar.gz is 20.8 MB lyx-2.2.0dev.tar.gz is 24.8 MB A quick check seems to show that most of the change comes from now including .svgz (in addition to .png). Why do we include both? I just wanted to check that this is expected. Scott
Re: [LyX/master] Copy caveats from RELEASE-NOTES to UPGRADING
On Mon, Nov 09, 2015 at 07:37:47AM +0100, Georg Baum wrote: > Scott Kostyshak wrote: > > > diff --git a/UPGRADING b/UPGRADING > > index 122f92d..1f410ac 100644 > > --- a/UPGRADING > > +++ b/UPGRADING > > @@ -1,6 +1,44 @@ > > -How do I upgrade my existing LyX system to version 2.1.x? > > +How do I upgrade my existing LyX system to version 2.2.x? > > - > > > > +* Upgrading from LyX 2.1.x: > > + > > +With LuaTeX, LyX now uses polyglossia instead of babel if the language > > +package option "Automatic" is selected. In order to use babel, select > > +"Always babel" instead. > > This is now duplicated: > > > + > > +With LuaTeX, LyX now uses polyglossia instead of babel if the language > > +package option "Automatic" is selected. In order to use babel, select > > +"Always babel" instead. This may be needed if a document uses code that > > +is specific to babel. Thanks for catching this. It is fixed at 7a507c37. Scott
Re: [patch] Finding the generated latex file
On Mon, Nov 09, 2015 at 08:04:29AM +, Guillaume Munch wrote: > Le 06/11/2015 10:35, Jean-Marc Lasgouttes a écrit : > >Le 06/11/2015 04:16, Scott Kostyshak a écrit : > >>>I also agree that it's better to replace the alert with a message on > >>>stderr. I noticed that there are already similar messages on the > >>>terminal when files cannot be removed. > >>> > >>>Attached is a patch. Shall I commit it? > >> > >>Although I personally like this (as I noted above), I think we should > >>get opinions from a couple of other LyX developers. From a quick search, > >>we have been giving a dialog for more than 10 years so there might be a > >>good reason for it. > > > >I think that a stderr message is good enough. I do not remember a > >discussion about having this dialog. If you want to know, find when it > >was introduced, and look at lyx-devel archives from this time. > > > >JMarc > > > > > > I suggest that people who requested this patch decide whether they want to > do this extra check, or ask me to commit already. :) I think this idea has simmered for long enough. Thanks for your patience, Guillaume. And thanks for the patch. Please commit. Scott
Re: [patch] proof of concept for bug 9744: allow parallel configuration of TeX and non-TeX fonts
On Mon, Nov 09, 2015 at 07:40:09AM +0100, Georg Baum wrote: > Kornel Benko wrote: > > > Am Sonntag, 8. November 2015 um 14:57:53, schrieb Scott Kostyshak > > > >> > >> I have just a few more items on my checklist (thanks to Vincent for the > >> help) before releasing alpha. I am also waiting for access to the FTP > >> (my IP needs to be whitelisted). If it takes too long to get access, > >> then I will just ask Richard (or someone else) for the favor of > >> uploading the tar ball. > > > > As the save would imply format change, and we want it in 2.2 cycle, > > I'd prefer to add it before 2.2 alpha is out. > > I did that, hope it is not too late. Thanks. It's fine. Scott
Re: 'make check' failing
On Mon, Nov 09, 2015 at 07:41:46AM +0100, Georg Baum wrote: > Scott Kostyshak wrote: > > > Ah yes indeed. I remember seeing that but did not make the connection. > > > > Would it help if I did a git bisect? > > Don't think so. This test is very old, and probably was never executed with > C++11 std::regex in gcc before. Someone would have to find out whether the > regex is standard conforming or uses some boost speciality. OK I guess I will ignore it for alpha then unless I hear otherwise. Scott
Re: Plan for the current testing situation
Note: quoting is not correct (probably because of replying on phone). On Mon, Nov 09, 2015 at 11:19:16AM +0100, Vincent van Ravesteijn wrote: > >> Ideally, I would like for commits that break tests to be on a separate > git > >> branch. Once the bugs exposed by a commit are fixed or the tests are > fixed, or > >> the .lyx files are fixed, then the branch could be merged to master. This > >> allows us to presere a "0 failing tests" situation on the master branch > so it > >> is extremely easy to catch regressions. So my preferred policy would be: > if a > >> commit is found to have broken a test, either the situation is resolved > within > >> a day (i.e. the bug is fixed or the test is fixed) or the commit is > reverted > >> (and perhaps pushed to a separate remote branch). > > > > > > A small remark: imposing a 1-day rule seems ad hoc to me. Do we even have > such rules for compilation warnings? For compilation failures? For the > latter, I imagine that people want it solved ASAP, but this arises more out > of social pressure, not an ad hoc rule. Social pressure does not work with everyone. Also, some people do not understand why certain things are so frustrating to others. > However I like the idea of having a > "candidate" remote branch, which would open up possibilities. If that's > really needed. > > > > Yes, the 1-day rule might lead to frustrated developers and increases the > noise in master branch even more. OK. How about a 1 week rule then? Or you would prefer no rule and just deal with it case-by-case and implicit rule as you mention below and as Guillaume refers to? > And yes of course there is an implicit rule that when your commit breaks > something or has problems whatsoever you are expected to fix it within a > reasonable timeframe. > > I already proposed to have a "staging" branch where commits are pushed to > first. If there are no breaking tests and no other comments they would be > merged to master after n days. The problems with such a construction are: > - devs are not eager to have to learn/understand/use an even more complex > git-o-cratic workflow, Yes this is indeed a real issue. Maybe in the future once everyone is more comfortable with git we can consider this. > - there will be merge conflicts, people have to make sure to indicate which > commit depends on which (or use feature branches which takes us back to the > first point), > - you unavoidably need some sort of maintainer to decide what gets merged > when and who resolves merge conflicts and is reasonably always present (or > to try to use some autocomplex scripting). Seems like we cannot do this at this point then. Scott
Re: Plan for the current testing situation
On Mon, Nov 09, 2015 at 09:13:37AM +, Guillaume Munch wrote: > Le 02/11/2015 03:41, Scott Kostyshak a écrit : > >Thanks to all of those participating in the discussions about tests. I have > >learned a lot the last couple of weeks. Thank you also to those who have > >tried > >to run the tests. This to me is a great step forward. I know that the export > >tests are sloppy cheap tests, but I appreciate that some of you agree that > >they > >do have use, at least until we have unit testing. The question now is, how > >can > >we get the most use out of them and how can we maximize their signal to noise > >ratio? > > Thank you for taking time to make a summary message. The messages about > tests were too many, so I could not follow the discussions. If you could > write another summary once the situation with tests is resolved it would be > very useful. Yes, I will try to remember to do this. Hopefully we can put everything in Development.lyx. It might take a bit for the test situation to stabilize though. Please feel free to ask for an update of the situation if I forget to give one.
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
On 2015-11-09, Kornel Benko wrote: > [-- Type: text/plain, Encoding: quoted-printable --] >> > Am Montag, 9. November 2015 um 15:50:09, schrieb Guenter Milde >> > >> >> On 2015-11-09, Kornel Benko wrote: > Thanks, I searched for attachment ... > Applied. > Running export tests ... > Still 165 failed. Not really better. The patch *should* disable XeTeX+TeX-fonts unless inputenc is explicitely set to "ascii". Unfortunately, the patch does not work. This is why I said: >> >> I hope someone familiar with the export routines can fix the >> >> "exclusion" patch I sent. However even if it worked, most XeTeX tests would still fail. But it would be better. Intended behaviour: * With the current default settings (TeX-fonts, inputenc="auto", the XeTeX view/export is disabled. +1 the fragile corner case with no advantage over "regular" pdflatex export is no longer easier to reach than the "proper" use of XeTeX (with non-TeX fonts). * If the user sets Document>Settings>Language>Encoding to ASCII, XeTeX with non-TeX is still accessible. +1 the safe way to use XeTeX with non-TeX fonts works. * Testing for XeTeX export without current default document settings will fail - "no export route found", because we explicitely close this "fragile" export route. +1 no false positives, no surprises. We expect this combination to fail (similar to pdflatex + non-TeX fonts) +1 default XeTeX-TeXF tests can safely be inverted. XeTeX export test would require documents with either "inputenc" == "ascii" or "useNonTeXFonts" == "true" to get a "positive" result. Günter
Re: [LyX/master] Store both sets of font selections
Am Montag, 9. November 2015 um 20:45:33, schrieb Kornel Benko > Am Montag, 9. November 2015 um 20:09:17, schrieb Georg Baum > > > Kornel Benko wrote: > > > > > The coding for \font_math looks suspicoius with the new format. > > > \font_math auto"" "default" > > > It appears in lyx-file after saving. > > > > > > Is this intended? > > > > No. I somehow overlooked the missing quote. This is fixed now. Thanks also > > for adjusting the tests! > > > > > > Georg > > I rerun the failed export tests (265), and all of sudden now only 16 of them > did not pass. > To be sure I started the test again with all exports but xhtml and lyx16. > #ctest -j12 -L export -E 'xhtml|lyx16' > Displaying 2972 tests to execute ... this may take some time. > > Will report. > It would have been so nice. But I was mocked (probably by myself). We have now 260 failed export tests. *.pdf4_texF:139 *.pdf5_texF:28 *.dvi3_texF:27 *.pdf5_systemF: 25 *.dvi3_systemF: 14 *.pdf4_systemF: 12 *_pdf3: 4 *_pdf2: 4 *_pdf: 2 *_dvi: 3 The last 4 rows stem from 1.) templates/IUCr-article.lyx export/templates/IUCr-article_dvi export/templates/IUCr-article_dvi3_texF export/templates/IUCr-article_dvi3_systemF export/templates/IUCr-article_pdf export/templates/IUCr-article_pdf2 export/templates/IUCr-article_pdf3 export/templates/IUCr-article_pdf4_texF export/templates/IUCr-article_pdf5_texF export/templates/IUCr-article_pdf5_systemF 2.) examples/fr/seminar.lyx export/examples/fr/seminar_dvi export/examples/fr/seminar_pdf export/examples/fr/seminar_pdf2 export/examples/fr/seminar_pdf3 export/examples/fr/seminar_pdf4_texF export/examples/fr/seminar_pdf5_systemF 3.) examples/fa/splash.lyx export/examples/fa/splash_dvi export/examples/fa/splash_pdf export/examples/fa/splash_pdf2 export/examples/fa/splash_pdf3 export/examples/fa/splash_pdf4_texF export/examples/fa/splash_pdf4_systemF Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Store both sets of font selections
Am Montag, 9. November 2015 um 20:09:17, schrieb Georg Baum > Kornel Benko wrote: > > > The coding for \font_math looks suspicoius with the new format. > > \font_math auto"" "default" > > It appears in lyx-file after saving. > > > > Is this intended? > > No. I somehow overlooked the missing quote. This is fixed now. Thanks also > for adjusting the tests! > > > Georg I rerun the failed export tests (265), and all of sudden now only 16 of them did not pass. To be sure I started the test again with all exports but xhtml and lyx16. #ctest -j12 -L export -E 'xhtml|lyx16' Displaying 2972 tests to execute ... this may take some time. Will report. Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Store both sets of font selections
Kornel Benko wrote: > The coding for \font_math looks suspicoius with the new format. > \font_math auto"" "default" > It appears in lyx-file after saving. > > Is this intended? No. I somehow overlooked the missing quote. This is fixed now. Thanks also for adjusting the tests! Georg
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Am Montag, 9. November 2015 um 16:35:28, schrieb Guenter Milde > On 2015-11-09, Kornel Benko wrote: > > Am Montag, 9. November 2015 um 15:50:09, schrieb Guenter Milde > > > >> On 2015-11-09, Kornel Benko wrote: > > ... > > >> I hope someone familiar with the export routines can fix the > >> "exclusion" patch I sent. > > It was here: > > From: Guenter Milde > Subject: Re: new patch for Xe/LuaTeX with TeX-fonts > Date: Mon, 9 Nov 2015 12:10:12 + (UTC) > > Günter Thanks, I searched for attachment ... Applied. Running export tests ... Still 165 failed. Not really better. Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
On 2015-11-09, Kornel Benko wrote: > Am Montag, 9. November 2015 um 15:50:09, schrieb Guenter Milde > >> On 2015-11-09, Kornel Benko wrote: ... >> I hope someone familiar with the export routines can fix the >> "exclusion" patch I sent. It was here: From: Guenter Milde Subject: Re: new patch for Xe/LuaTeX with TeX-fonts Date: Mon, 9 Nov 2015 12:10:12 + (UTC) Günter
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Am Montag, 9. November 2015 um 15:50:09, schrieb Guenter Milde > On 2015-11-09, Kornel Benko wrote: > > Am Montag, 9. November 2015 um 12:59:10, schrieb Günter Milde > > > >> commit 480937a103708a6510ae24c2ee91cd1459d67104 > >> Author: Günter Milde > >> Date: Mon Nov 9 11:45:01 2015 +0100 > > >> Reset encoding after insets and environments also for LuaTeX with TeX > >> fonts. > > > After this or some previous commit, there are 116 new testcases failing. > > All of the new failing tests are of type _pdf4_texF (xelatex with tex font). > > This is what I expected - the patch is incomplete with respect to XeTeX. > (And this is why I asked 2 times whether there are regressions with this > patch.) > > OTOH, I am pretty sure to have done the right thing and while there is no > real use case for XeTeX with TeX fonts, there is a use case for LuaTeX with > TeX fonts (and it is better supported -- via luatinputenc). > > OTOH even LuaTeX with TeX fonts is still "fragile": if there is more than > one encoding in a document, luainputenc fails if used with luatex! > > > Should we disable these tests? > > I vote for reversion or ignoring: XeTeX with TeX fonts only works > reliably, if "inputencoding" is set ASCII. For now, +1 > I hope someone familiar with the export routines can fix the > "exclusion" patch I sent. ?? Could not find in latest posts. > > OTOH, some which previously failed, now successfully compile. (23) > > > Now successful: > > export/doc/el/Intro_dvi3_texF > > export/doc/el/Intro_pdf5_texF > > export/doc/ja/Additional_pdf > > export/doc/ja/Customization_pdf > > export/doc/ja/DummyDocument1_pdf > > export/doc/ja/DummyDocument2_pdf > > export/doc/ja/EmbeddedObjects_pdf > > export/doc/ja/Formula-numbering_pdf > > export/doc/ja/Intro_pdf > > export/doc/ja/LaTeXConfig_pdf > > export/doc/ja/Math_pdf > > export/doc/ja/Shortcuts_pdf > > export/doc/ja/Tutorial_pdf > > export/doc/ja/UserGuide_pdf > > export/examples/ja/Braille_pdf > > export/examples/ja/FeynmanDiagrams_pdf > > export/examples/ja/MultilingualCaptions_pdf > > export/examples/ja/R-S-statements_pdf > > export/examples/ja/beamer_pdf > > export/examples/ja/linguistics_pdf > > export/examples/ja/splash_pdf > > export/examples/ja/xypic_pdf > > export/templates/ja_beamer-conference-ornate-20min_pdf > > This should basically be most LuaTeX with TeX fonts tests, Only 2 of them are luatex + tex font. (export/doc/el/Intro_dvi3_texF, export/doc/el/Intro_pdf5_texF) All other are created with pdflatex or 'platex + dvipdfm' > I can't tell why the Japanese works and if this has to do with my patches. > > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
On 2015-11-09, Kornel Benko wrote: > Am Montag, 9. November 2015 um 12:59:10, schrieb Günter Milde >> commit 480937a103708a6510ae24c2ee91cd1459d67104 >> Author: Günter Milde >> Date: Mon Nov 9 11:45:01 2015 +0100 >> Reset encoding after insets and environments also for LuaTeX with TeX >> fonts. > After this or some previous commit, there are 116 new testcases failing. > All of the new failing tests are of type _pdf4_texF (xelatex with tex font). This is what I expected - the patch is incomplete with respect to XeTeX. (And this is why I asked 2 times whether there are regressions with this patch.) OTOH, I am pretty sure to have done the right thing and while there is no real use case for XeTeX with TeX fonts, there is a use case for LuaTeX with TeX fonts (and it is better supported -- via luatinputenc). OTOH even LuaTeX with TeX fonts is still "fragile": if there is more than one encoding in a document, luainputenc fails if used with luatex! > Should we disable these tests? I vote for reversion or ignoring: XeTeX with TeX fonts only works reliably, if "inputencoding" is set ASCII. I hope someone familiar with the export routines can fix the "exclusion" patch I sent. > OTOH, some which previously failed, now successfully compile. (23) > Now successful: > export/doc/el/Intro_dvi3_texF > export/doc/el/Intro_pdf5_texF > export/doc/ja/Additional_pdf > export/doc/ja/Customization_pdf > export/doc/ja/DummyDocument1_pdf > export/doc/ja/DummyDocument2_pdf > export/doc/ja/EmbeddedObjects_pdf > export/doc/ja/Formula-numbering_pdf > export/doc/ja/Intro_pdf > export/doc/ja/LaTeXConfig_pdf > export/doc/ja/Math_pdf > export/doc/ja/Shortcuts_pdf > export/doc/ja/Tutorial_pdf > export/doc/ja/UserGuide_pdf > export/examples/ja/Braille_pdf > export/examples/ja/FeynmanDiagrams_pdf > export/examples/ja/MultilingualCaptions_pdf > export/examples/ja/R-S-statements_pdf > export/examples/ja/beamer_pdf > export/examples/ja/linguistics_pdf > export/examples/ja/splash_pdf > export/examples/ja/xypic_pdf > export/templates/ja_beamer-conference-ornate-20min_pdf This should basically be most LuaTeX with TeX fonts tests, I can't tell why the Japanese works and if this has to do with my patches. Günter
Re: [LyX/master] Store both sets of font selections
Am Montag, 9. November 2015 um 07:37:01, schrieb Georg Baum > commit 2fc430d5aede9287da57d9d5273af060e9f52f08 > Author: Georg Baum > Date: Mon Nov 9 07:33:57 2015 +0100 > > Store both sets of font selections > > This is one part of bug 9744: If you toggle between TeX fonts and non-TeX > fonts, the settings of the other choice are no longer thrown away, but > stored > and re-activated if you switch back. Most parts of the patch are purely > mechanical (duplicating some BufferParams members), the only > non-mechanical > change is in the GUI logic. The coding for \font_math looks suspicoius with the new format. \font_math auto"" "default" It appears in lyx-file after saving. Is this intended? Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Am Montag, 9. November 2015 um 12:59:10, schrieb Günter Milde > commit 480937a103708a6510ae24c2ee91cd1459d67104 > Author: Günter Milde > Date: Mon Nov 9 11:45:01 2015 +0100 > > Reset encoding after insets and environments also for LuaTeX with TeX > fonts. > After this or some previous commit, there are 116 new testcases failing. All of the new failing tests are of type _pdf4_texF (xelatex with tex font). Should we disable these tests? OTOH, some which previously failed, now successfully compile. (23) Now successful: export/doc/el/Intro_dvi3_texF export/doc/el/Intro_pdf5_texF export/doc/ja/Additional_pdf export/doc/ja/Customization_pdf export/doc/ja/DummyDocument1_pdf export/doc/ja/DummyDocument2_pdf export/doc/ja/EmbeddedObjects_pdf export/doc/ja/Formula-numbering_pdf export/doc/ja/Intro_pdf export/doc/ja/LaTeXConfig_pdf export/doc/ja/Math_pdf export/doc/ja/Shortcuts_pdf export/doc/ja/Tutorial_pdf export/doc/ja/UserGuide_pdf export/examples/ja/Braille_pdf export/examples/ja/FeynmanDiagrams_pdf export/examples/ja/MultilingualCaptions_pdf export/examples/ja/R-S-statements_pdf export/examples/ja/beamer_pdf export/examples/ja/linguistics_pdf export/examples/ja/splash_pdf export/examples/ja/xypic_pdf export/templates/ja_beamer-conference-ornate-20min_pdf Kornel signature.asc Description: This is a digitally signed message part.
Re: new patch for Xe/LuaTeX with TeX-fonts
On 2015-11-06, Guenter Milde wrote:
> On 2015-11-06, Guenter Milde wrote:
>> On 2015-11-06, Kornel Benko wrote:
>>> Am Donnerstag, 5. November 2015 um 20:12:53, schrieb Guenter Milde
>>>
>>> ...
pass "LaTeXFeatures & features" as argument
and test for "features.runparams().flavor == OutputParams::XETEX"
(cf. BufferParams::writeEncodingPreamble().
...
>>> I'd say this is the right way. But I wonder why BufferParams class does
>>> not have access to features.
I tried this way, but:
after changing
Encoding const & BufferParams::encoding() const
to expect the "flavor" as argument, I started changing the 18+ calls to
params.encoding() realizing that in most cases the "flavor" is not (yet)
known:
>> The export target and "flavour" is only known after a user request to export
>> the document.
and runparams is an instance of OutputParams and instantiating
OutputParams requires passing the encoding - so we have a "hen and egg"
problem!
> Another way out would be to disable XeTeX export unless either the
> inputencoding is set to ASCII or the font-set to non-TeX-fonts.
I tried to implement this, but the export buttons are not greyed out:
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index a73194d..c6efac8 100644
@@ -2348,6 +2348,8 @@ vector
BufferParams::exportableFormats(bool only_viewable) const
excludes.insert("latex");
excludes.insert("pdflatex");
}
+ else if (encoding().latexName() != "ascii")
+ excludes.insert("xetex"); // XeTeX with TeX fonts requires
ASCII encoding
vector result =
theConverters().getReachable(backs[0], only_viewable, true,
excludes);
for (vector::const_iterator it = backs.begin() + 1;
@@ -2388,10 +2390,12 @@ vector BufferParams::backends() const
}
v.push_back("luatex");
v.push_back("dviluatex");
- v.push_back("xetex");
+ if (!useNonTeXFonts && encoding().latexName() != "ascii")
+ v.push_back("xetex");
} else if (buffmt == "xetex") {
v.push_back("xetex");
// FIXME: need to test all languages (bug 8205)
+ // FIXME: polyglossia now also works with luatex
if (!language || !language->isPolyglossiaExclusive()) {
v.push_back("luatex");
v.push_back("dviluatex");
What is missing?
Also, luainputenc fails with more than one encoding in a document (see
http://www.lyx.org/trac/ticket/9740), so we should disable
LuaTeX with TeX-fonts and inputenc="auto".
Günter
Re: Plan for the current testing situation
>> Ideally, I would like for commits that break tests to be on a separate git >> branch. Once the bugs exposed by a commit are fixed or the tests are fixed, or >> the .lyx files are fixed, then the branch could be merged to master. This >> allows us to presere a "0 failing tests" situation on the master branch so it >> is extremely easy to catch regressions. So my preferred policy would be: if a >> commit is found to have broken a test, either the situation is resolved within >> a day (i.e. the bug is fixed or the test is fixed) or the commit is reverted >> (and perhaps pushed to a separate remote branch). > > > A small remark: imposing a 1-day rule seems ad hoc to me. Do we even have such rules for compilation warnings? For compilation failures? For the latter, I imagine that people want it solved ASAP, but this arises more out of social pressure, not an ad hoc rule. However I like the idea of having a "candidate" remote branch, which would open up possibilities. If that's really needed. > Yes, the 1-day rule might lead to frustrated developers and increases the noise in master branch even more. And yes of course there is an implicit rule that when your commit breaks something or has problems whatsoever you are expected to fix it within a reasonable timeframe. I already proposed to have a "staging" branch where commits are pushed to first. If there are no breaking tests and no other comments they would be merged to master after n days. The problems with such a construction are: - devs are not eager to have to learn/understand/use an even more complex git-o-cratic workflow, - there will be merge conflicts, people have to make sure to indicate which commit depends on which (or use feature branches which takes us back to the first point), - you unavoidably need some sort of maintainer to decide what gets merged when and who resolves merge conflicts and is reasonably always present (or to try to use some autocomplex scripting). Vincent
Re: Plan for the current testing situation
Le 02/11/2015 03:41, Scott Kostyshak a écrit : Thanks to all of those participating in the discussions about tests. I have learned a lot the last couple of weeks. Thank you also to those who have tried to run the tests. This to me is a great step forward. I know that the export tests are sloppy cheap tests, but I appreciate that some of you agree that they do have use, at least until we have unit testing. The question now is, how can we get the most use out of them and how can we maximize their signal to noise ratio? Thank you for taking time to make a summary message. The messages about tests were too many, so I could not follow the discussions. If you could write another summary once the situation with tests is resolved it would be very useful. Ideally, I would like for commits that break tests to be on a separate git branch. Once the bugs exposed by a commit are fixed or the tests are fixed, or the .lyx files are fixed, then the branch could be merged to master. This allows us to presere a "0 failing tests" situation on the master branch so it is extremely easy to catch regressions. So my preferred policy would be: if a commit is found to have broken a test, either the situation is resolved within a day (i.e. the bug is fixed or the test is fixed) or the commit is reverted (and perhaps pushed to a separate remote branch). A small remark: imposing a 1-day rule seems ad hoc to me. Do we even have such rules for compilation warnings? For compilation failures? For the latter, I imagine that people want it solved ASAP, but this arises more out of social pressure, not an ad hoc rule. However I like the idea of having a "candidate" remote branch, which would open up possibilities. If that's really needed. Guillaume
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 08/11/2015 16:16, Georg Baum a écrit : Richard Heck wrote: On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote: Is it really a file format change? If we do not change the physical appearance of the file format, and if we do not change the document output of a certain file, is it then still forbidden to change in a minor release? Yes, it is a file format change. It means (say) that 2.2.2 files throw errors when they are read with 2.2.1. If I understood Vincent correctly then it would not be a file format change IMHO: As I understood it, he referred to the suggestion that the "track changes" button would be decoupled from \track_changes in the file: \track_changes would set the state of the button on opening a document, but changing the change tracking status would not write back anything to the file. What I understood as well, up to minor points (if \track_changes is set to false, then we can fall back to the per-user, per-document setting, because I haven't heard people on the list make a use case out of forcing CT to be disabled on opening...). There would be a separate lfun for setting the default in the file. A minor technical question: there are no LFUN for document settings usually right? You are suggesting a new LFUN for convenience? In this case, the file syntax would be kept, but the meaning of \track_changes would change a bit. I made it a file format change because I imagined that we would have to reset the state of the setting while converting, but good to know that you are ready to obviate this step. After thinking a bit about this suggestion I believe it could be a good compromise for everybody, and I would not treat this as a file format change. Either that, or add a git mode, in which case it would be good to add the setting before 2.2, even if it does not encompass everything right from the start. Either suit me; it's a matter of LyX's philosophy as per my other message. Ping me if you finally find a consensus on whether there is a consensus :) Guillaume
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 07/11/2015 21:18, Pavel Sanda a écrit : Guillaume Munch wrote: Have a new checkbox in document settings labelled "Open with change tracking enabled". Then the current state of change tracking is made independent from this checkbox; only, if the box is checked then it will do as advertised by the label. Otherwise, the per-user, per-session setting is restored. This seems to fit better than the current situation what I understand of Pavel and other people's use case for change tracking. Indeed, even in My summary is quite different. The current situation seems to be more in tune with what most people expect and what other offices are doing. Hi Pavel, Thank you for making these suggestions. I see that you suggest small variations on adding a new setting, so I am happy to see some convergence. That said I understand your pain and agree that it sucks for version control usecase. My take on that would be one of those directions: 1. User preference for ignoring CT toggling changes during the session. The CT on/off status would be saved in the same way as it was opened no matter whether the user changed it during editing. So a "Save change tracking within document" per-user checkbox. The difference with a suggestion à la Vincent are that the current status of change tracking is saved, and it is per-user instead of per-document. I had thought about it, and it makes more sense to me as a per-document setting than as a per-user setting to me. Then, if it's per-document, I do not see the need to add an additional indirection via the current CT state, so we can let the checkbox directly determine the state on opening. This is why I was convinced by the "Open with change tracking enabled" checkbox. 2. Some form of turn on/off permanently vs intermittently, both in menu or it could be tristate. (Code-wise it might be similar to 1. I am thinking more how it appears in GUI to the user.) Well the idea of a tri-state button was what I elaborated with the "CT lock" suggestion (up to minor differences). I imagined a "lock" button next to the current button and activating the lock activates the usual button at the same time, so in practice it was really a tri-state setting. But then I needed a way to make the interface worthwhile and intuitive so I suggested that deactivating the lock shows a confirmation prompt to the user, but then it was too much "bells and whistles" according to replies. Logic and file-wise, yes it's very similar to the previous one and it would reuse \tracking_changes as well (as I had suggested it, we would also have needed to record who activated the lock but this was inessential). 3. General preference (not sure if document or user) for ignoring non essential changes, which disturbs version control flow. Similar to 1. but it would encompass e.g. CT on/off, output_changes, GUI justification. I have another candidate here as well - not storing opening/closing insets. So essentially a single setting for all user-like document settings. You had convinced me with your "open/closed inset" point that actually LyX records more than I previously thought the current state of user preferences inside files, while my point was that it seems to me that this less LyX's philosophy than e.g. LibreOffice's. I also like the idea that storing the open/closed state of insets may not always be what we want. But I thought about it more. If the state of insets is lost, then we have to revert to a default state where all the insets are either open or closed. While for some insets I would no mind to lose the state, losing it for all insets looks like a dataloss to me. So we cannot afford to store as user settings things that could cause dataloss. Also it looks technically challenging to me to store the state of insets as user settings. So I am no longer convinced that not storing open/closed state of insets is feasible and realistic. Still, a single "git compatibility mode" per-document setting would satisfy me equally. But, would it really encompass more than the two change-tracking settings? (\justification seems a different case to me as I am still convinced that it should be purely per-user.) It comes down to whatever is LyX's philosophy: do we want to store user settings in files? Then let's add a "git mode" per-document setting. Or do we want user settings never to be stored within files? Then make CT per-user-per-document, and add a "Open with CT enabled" per-document setting. Guillaume
Re: [patch] Finding the generated latex file
Le 06/11/2015 10:35, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 04:16, Scott Kostyshak a écrit : I also agree that it's better to replace the alert with a message on stderr. I noticed that there are already similar messages on the terminal when files cannot be removed. Attached is a patch. Shall I commit it? Although I personally like this (as I noted above), I think we should get opinions from a couple of other LyX developers. From a quick search, we have been giving a dialog for more than 10 years so there might be a good reason for it. I think that a stderr message is good enough. I do not remember a discussion about having this dialog. If you want to know, find when it was introduced, and look at lyx-devel archives from this time. JMarc I suggest that people who requested this patch decide whether they want to do this extra check, or ask me to commit already. :) Guillaume
