Re: status update on the export tests

[Guenter Milde]

On 2015-11-04, Kornel Benko wrote:
> Am Mittwoch, 4. November 2015 um 19:27:06, schrieb Guenter Milde 
> 
>> On 2015-11-04, Kornel Benko wrote:
>> > Am Mittwoch, 4. November 2015 um 15:36:45, schrieb Guenter Milde 
>> > 

>> ...

>> >> Not only, with "suspending" I also mean "The outcome is of no value
>> >> for finding new bugs or regressions until someone solves the known
>> >> bug ...".

>> >> However, we usually know what the outcome should be if the bug is
>> >> solved: if the expected outcome is "pass", this test should not be
>> >> inverted.

>> > Here we disagree. Matter of taste I suppose. For me the test fails
>> > _now_. We don't care now (because we know what's going on etc.).
>> > Therefore the test is to be inverted as to not catch unwanted
>> > attention.

>> I still do not understand the reasoning. It will not catch attention if
>> it is suspended, that is why it should be suspended.

> It is suspended _only_ if you select testcases with the '-L' parameter.

OK. My idea was that suspended testcases are skipped by default.

...

> Sure, but look into suspendedTests, there is only 1 regex (for now, I
> know) selecting from the inverted tests.

Maybe it is indeed a matter of taste. The advantage of your approach is,
that it is a small change to the exisisting/previous setup. As you are doing
the work, you shall have the final say. Just two thoughts:

* In your implementeation, the 1 regex (for now) rather points to 
  "fragile" tests, some of which are "suspended" (i.e. temporarily
  ignored).
  
  Could you name the file "fragileTests" reduce confusion?

* How can we distinguish a "good" inversion (the test should fail) from a
  "bad" inversion (the test should pass but currently does not).


Günter

Re: [LyX/master] Document the export tests and other tests

[Vincent van Ravesteijn]

On Thu, Nov 5, 2015 at 8:27 AM, Guenter Milde  wrote:
> On 2015-11-04, Georg Baum wrote:
>> Guenter Milde wrote:
>
>>> On 2015-10-30, Georg Baum wrote:
 Kornel Benko wrote:
>
 These directories are clearly not suitable for pure test files, so I'll
 need to add a new one. Would lib/tests be OK?
>
>>> If you use such a generic name, it should have sub-directories for
>
>>> * unittests
>
>> unit tests are sources which need to be compiled (except for the lyx2lyx
>> ones which do already have an own directory). I think these do not belong
>> under lib, but somewhere under src/.
>
> Agreed. OTOH, I would prefer to have tests separated from src/, so maybe
>
> lib/
> src/
> tests/
>   unittests/
>   export-tests/
>   functional/
>  tests-scripts
>  input/
>  expected/ # expected output
>  output/   # just a dir for the output, no content in the repo
>

+1

>> For now I'll simply put all files in lib/test/export (I only plan to add
>> export test for now), once we have 20 or 30 files in there we can create
>> sub-directories, and then it might also be clear how to name these.

"lib" sounds like the things we distribute as the Resource folder.

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

On Thu, Nov 5, 2015 at 7:12 AM, Pavel Sanda  wrote:
> Vincent van Ravesteijn wrote:
>> > I consider it also document, not user, setting. It would cause confusions
>> > if this setting is not transfered to my collaborators within the document.
>>
>> I disagree. There is no confusion possible.
>
> It is. When the document circles I want the CT be part of document
> setting not dependent whether this or another collaborator forgot
> to switch CT.
>

Maybe that could be a new feature: "Editing this document is only
allowed with track changes on. Track changes can only be turned off by
the one that "locked" the file".

Vincent

Re: [LyX/master] Document the export tests and other tests

[Guenter Milde]

On 2015-11-04, Georg Baum wrote:
> Guenter Milde wrote:

>> On 2015-10-30, Georg Baum wrote:
>>> Kornel Benko wrote:

>>> These directories are clearly not suitable for pure test files, so I'll
>>> need to add a new one. Would lib/tests be OK?

>> If you use such a generic name, it should have sub-directories for

>> * unittests

> unit tests are sources which need to be compiled (except for the lyx2lyx 
> ones which do already have an own directory). I think these do not belong 
> under lib, but somewhere under src/.

Agreed. OTOH, I would prefer to have tests separated from src/, so maybe

lib/
src/
tests/
  unittests/
  export-tests/
  functional/
 tests-scripts
 input/
 expected/ # expected output
 output/   # just a dir for the output, no content in the repo

> For now I'll simply put all files in lib/test/export (I only plan to add 
> export test for now), once we have 20 or 30 files in there we can create 
> sub-directories, and then it might also be clear how to name these.

Maybe sub-dirs for the different export routes would be good. Many special
tests are for just one export format, others could by symlinked. This could
reduce noise and need for inversions.

Günter

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Guenter Milde]

On 2015-11-05, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
>> > I consider it also document, not user, setting. It would cause confusions
>> > if this setting is not transfered to my collaborators within the document.

>> I disagree. There is no confusion possible.

> It is. When the document circles I want the CT be part of document
> setting not dependent whether this or another collaborator forgot
> to switch CT.

+1

Günter

Re: Two Shortcut Changes

[Pavel Sanda]

Richard Heck wrote:
> The second patch addresses a related but different issue. In cua.bind, 
> C-S-T is bound to "buffer-update ps" and C-S-D to "buffer-update dvi". It 
> seems to me that it would be good to have one of these bound to 
> "buffer-update pdf" instead, and I'd make it C-S-T, as that is consistent 
> with what we have in mac.bind.

Does it mean that by default we have now 2 shortcuts for pdf (c-r & c-t)
and no shortcut for ps?

Pavel

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> > I consider it also document, not user, setting. It would cause confusions
> > if this setting is not transfered to my collaborators within the document.
> 
> I disagree. There is no confusion possible.

It is. When the document circles I want the CT be part of document
setting not dependent whether this or another collaborator forgot
to switch CT.

Pavel

new patch for Xe/LuaTeX with TeX-fonts

[Guenter Milde]

Dear LyX developers,

the patch below solves some of the unresolved FIXMES in the 
"Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems"
1523fc6023440f10ca0/lyxgit

Testing shows, that this improves LuaTeX export with the minimal example of
ticket #6216  that triggered the code containing the FIXMES:
http://www.lyx.org/trac/raw-attachment/ticket/6216/6216.lyx

With branch, exporting it with XeTeX and LuaTeX fails.

With current master, export with XeTeX works but export to the LuaTeX file
fails (due to the encoding beeing changed (no-tex fonts) but not beeing reset
wrong test for FullUnicode instead of useNonTeXFonts in output_latex.cpp)

With the patch, export with XeTeX works. Export to the LuaTeX file works,
too. Compiling with LuaTeX fails (luainputenc problem) but the "show
anyway" button shows the correct result.

This means, the patch does not help to cure any case but improves LuaTeX
export.

There are new FIXMEs, where I were to lazy to get "buf" into the scope and
fix all side-effects:

+   // BufferParams const & bparams = buf.params(); //FIXME: ‘buf’ was not 
declared in this scope

Instead, I just commented the affected nonTeXFonts tests - the
abovementionend test document still works also after selecting nonTeXFonts,
so maybe the test are just to save time but have no effect on the output.

Please test and apply if found useful and error-free.

Günter

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Guillaume Munch]

Le 04/11/2015 20:06, Georg Baum a écrit :

Guillaume Munch wrote:


Le 03/11/2015 21:16, Georg Baum a écrit :


I don't think there is an easy solution, because it depends on the use
case. For example, in our documentation workflows \tracking_changes needs
to be the same for all users, so this should not go into the preferences.
For the other two I am not sure.



For context:

\track_changes : whether the track changes button is enabled (does not
affect the existing contents)


But it affects what happens if a change is made to the document. One author
using change tracking and the next one making changes without change
tracking is a very special case IMO. The usual case is that either all
authors or nobody uses change tracking for a particular document. For
example, in our own docs, we require everybody to use change tracking so
that the translations can be updated. Therefore it should be switched on all
the time.




My experience with multi-author collaboration and change tracking
differs. The various portions of the document tend to "belong" to one
author and an author uses change tracking depending on whether that part
belongs to them. Also, for trivial edits (typos...) they would disable
change tracking. This is from my actual experience. So we tend to switch
change tracking many times. The interface tends to concur with this
usage: it is located on a toolbar and is assigned a keyboard shortcut.

On the contrary, the use case that you mention where everybody has to
track changes at the same time seems to be due to external constraints:
change tracking is not used to facilitate multi-author collaboration,
but to facilitate translations. This use of change-tracking appears very
special to me.

In addition, what appears even more special to me is the number of times
when it produces the effects that you mention: the only times when a
per-user, per-document preference would not produce the same effect is
the very first time that the user edits the document. I am willing to
bet that that this happened fewer times overall in the past few months
for LyX's documentations than the number of times where I had to
synchronise with my co-author in the same time frame for a single
article. And in any case, having change tracking set automatically on
opening is not enough, because you still have to tell new contributors
that it is important to track changes. Or did I miss something from your
argument?

Another argument is the principle of least surprise: I think that users
would tend to assume that it is a per-user, per-document preference,
similar to the last cursor position mentioned by Vincent. Currently, it
is more confusing, in the context where change tracking is enabled
intermittently, that my co-author gets my own latest state instead of their.

I agree with Vincent: \justification is per user, and the other two are
per user, per document.


Guillaume

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

Op 4-11-2015 om 21:06 schreef Georg Baum:

Guillaume Munch wrote:


Le 03/11/2015 21:16, Georg Baum a écrit :

I don't think there is an easy solution, because it depends on the use
case. For example, in our documentation workflows \tracking_changes needs
to be the same for all users, so this should not go into the preferences.
For the other two I am not sure.


For context:

\track_changes : whether the track changes button is enabled (does not
affect the existing contents)

But it affects what happens if a change is made to the document. One author
using change tracking and the next one making changes without change
tracking is a very special case IMO. The usual case is that either all
authors or nobody uses change tracking for a particular document. For
example, in our own docs, we require everybody to use change tracking so
that the translations can be updated. Therefore it should be switched on all
the time.
I think that a regular use-case is that one author writes, and the other 
one provides feedback using track changes.


Toggling track_changes does not even mark the document as changed, so 
you cannot save it. So, when I'm ready writing and I want my 
collaborator to use track changes, I'll have turn on track changes, make 
a change, undo the change, and save.


Vincent

Re: [LyX/master] Document the export tests and other tests

[Georg Baum]

Guenter Milde wrote:

> On 2015-10-30, Georg Baum wrote:
>> Kornel Benko wrote:
> 
>> These directories are clearly not suitable for pure test files, so I'll
>> need to add a new one. Would lib/tests be OK?
> 
> If you use such a generic name, it should have sub-directories for
> 
> * unittests

unit tests are sources which need to be compiled (except for the lyx2lyx 
ones which do already have an own directory). I think these do not belong 
under lib, but somewhere under src/.

> * functional-tests (run LyX on a document and compare the output to a
> known example)
>   + test-scripts
>   + input# input documents for functional tests
>   + output   # documents generated by the functional tests (empty in the
>   repository) + expected # example documents with expected output
>   
> * export-tests (example documents where we just test for export errors)
>   (maybe also with subdirs for "topics")

This makes sense. Especially the distinction between functional and export 
tests at the first level is very friendly to the existing testing machinery.

Below that we will probably get some deeper structure in the future, but 
since you can only sort by one criterion at each levekl, there will always 
be people who disagree with the chosen directories. Therefore, we'll need 
alternative criteria as well which do not rely on the file system (e.g. the 
labels).

For now I'll simply put all files in lib/test/export (I only plan to add 
export test for now), once we have 20 or 30 files in there we can create 
sub-directories, and then it might also be clear how to name these.


Georg

Re: Two Shortcut Changes

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 21:22:34, schrieb Georg Baum 

> Richard Heck wrote:
> 
> > Attached are two patches inspired by bug #9830. The request there was to
> > make master-buffer-view and master-buffer-update fall back to
> > buffer-view and buffer-update, since it's annoying to have to use
> > different shortcuts with different documents, if one is used to working
> > with master documents. In fact, all that is really needed is to change
> > the shortcuts to use command-alternatives. I've done this myself for a
> > long time, and it seems a simple enough change. That is the first patch.
> 
> Did not know that it was so easy. I like it.

+1

> > The second patch addresses a related but different issue. In cua.bind,
> > C-S-T is bound to "buffer-update ps" and C-S-D to "buffer-update dvi".
> > It seems to me that it would be good to have one of these bound to
> > "buffer-update pdf" instead, and I'd make it C-S-T, as that is
> > consistent with what we have in mac.bind.

emacs.bind could also be corrected. ATM it binds "C-x r", "C-x t" and "C-x C-t" 
to "buffer-update dvi".

> I have no opinion on this.
> 
> 
> Georg

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Plan for the current testing situation

[Georg Baum]

Guenter Milde wrote:

> On 2015-11-02, Georg Baum wrote:
> 
>> 1) Fix the first half of bug #9744. This is an easy and safe change
> 
> Actually, "allowing parallel configuration of TeX and non-TeX fonts" is a
> precondition for the proposed config value "automatic" for "use non-TeX
> fonts":
> 
> * Currently, the LyX file stores font configuration only for one font set,
>   either TeX-fonts or non-TeX-fonts, however
>   
> * documents with non-default fonts usually require configuration for both
> sets
>   to get a consistent look (e.g. choose Times/Helvetica/Courier lookalikes
>   or "Linux Libertine" fonts - be it 8-bit or Unicode encoded fonts).

Thanks, now I finally understand what was meant by "parallel configuration". 
I always thought that it meant the LaTeX side, so that it should somehow be 
possible to use both (which I did not understand how that could work).

Such a change would be easy as well.

>> Günter, maybe you want to have a try yourself (if Scott agrees to do
>> this before 2.2.0)?
> 
> I am willing to help but cannot do this.

I'll try to find some time.


Georg

Re: Two Shortcut Changes

[Georg Baum]

Richard Heck wrote:

> Attached are two patches inspired by bug #9830. The request there was to
> make master-buffer-view and master-buffer-update fall back to
> buffer-view and buffer-update, since it's annoying to have to use
> different shortcuts with different documents, if one is used to working
> with master documents. In fact, all that is really needed is to change
> the shortcuts to use command-alternatives. I've done this myself for a
> long time, and it seems a simple enough change. That is the first patch.

Did not know that it was so easy. I like it.

> The second patch addresses a related but different issue. In cua.bind,
> C-S-T is bound to "buffer-update ps" and C-S-D to "buffer-update dvi".
> It seems to me that it would be good to have one of these bound to
> "buffer-update pdf" instead, and I'd make it C-S-T, as that is
> consistent with what we have in mac.bind.

I have no opinion on this.


Georg

Re: RFC: better submenu for tables

[Georg Baum]

Richard Heck wrote:

> On 11/04/2015 04:42 AM, Jean-Marc Lasgouttes wrote:
>> Le 03/11/2015 01:43, Uwe Stöhr a écrit :
>>> If you open the submenu of tables you see many entries. In my opinion
>>> too many, at least too many for laptops with small screens.
>>>
>>> In general I think it should be less crowded. Thus a proposal:
>>>
>>> - everything is removed for which we also have toolbar button. (If users
>>> disabled the automatic show of the table toolbar they apparently don't
>>> use tables that much and the table settings dialog is sufficient)
>>
>> This is not how contextual menus are supposed to work IMO. I would
>> propose instead to use submenus and to micmick what libreoffice (for
>> ex.) does.
> 
> I personally hate toolbars and almost never use them. So I'd prefer that
> things not be removed simply because they're also on a toolbar.

+1

This with larger screens should not suffer from the limitations of small 
screens. Instead, the table context menu should be better structured with 
submenus, so that it looks better on small screens.


Georg

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Georg Baum]

Guillaume Munch wrote:

> Le 03/11/2015 21:16, Georg Baum a écrit :
>>
>> I don't think there is an easy solution, because it depends on the use
>> case. For example, in our documentation workflows \tracking_changes needs
>> to be the same for all users, so this should not go into the preferences.
>> For the other two I am not sure.
>>
> 
> For context:
> 
> \track_changes : whether the track changes button is enabled (does not
> affect the existing contents)

But it affects what happens if a change is made to the document. One author 
using change tracking and the next one making changes without change 
tracking is a very special case IMO. The usual case is that either all 
authors or nobody uses change tracking for a particular document. For 
example, in our own docs, we require everybody to use change tracking so 
that the translations can be updated. Therefore it should be switched on all 
the time.


Georg

Re: status update on the export tests

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 19:27:06, schrieb Guenter Milde 

> On 2015-11-04, Kornel Benko wrote:
> > Am Mittwoch, 4. November 2015 um 15:36:45, schrieb Guenter Milde 
> > 
> 
> ...
> 
> >> Not only, with "suspending" I also mean "The outcome is of no value for
> >> finding new bugs or regressions until someone solves the known bug ...".
> 
> > OK.
> 
> >> However, we usually know what the outcome should be if the bug is
> >> solved: if the expected outcome is "pass", this test should not be
> >> inverted.
> 
> > Here we disagree. Matter of taste I suppose. For me the test fails
> > _now_. We don't care now (because we know what's going on etc.).
> > Therefore the test is to be inverted as to not catch unwanted
> > attention.
> 
> I still do not understand the reasoning. It will not catch attention if
> it is suspended, that is why it should be suspended.

It is suspended _only_ if you select testcases with the '-L' parameter.

> OTOH, if a test that should pass but does not is inverted & suspended (2
> actions), we need to uninvert and to unsuspend (again 2 actions) once the
> problem causing the failure is solved.

No, we need only uninvert. 'Suspend' has no effect or non-inverted tests.

> In contrast, if the "inversion status" matches the expected test result, we
> can run suspended tests from time to time and "unsuspend" the tests that now
> give the expected output.

No, only uninvert.

> Also, when looking at inverted tests, we do not know whether this is a 
> "good" inversion (the test should fail) or a "bad" inversion (the test
> should pass but currently does not).
> 

Sure, but look into suspendedTests, there is only 1 regex (for now, I know) 
selecting
from the inverted tests.

> Günter
> 

Kornel 

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Scott Kostyshak]

On Wed, Nov 04, 2015 at 08:45:48PM +0100, Kornel Benko wrote:
> > Besides suspending the test, we should create a specific test that tests 
> > the compatibility of chemgreek with Xe/LuaTeX and invert that test.
> 
> That would be nice.
> 
> > This documents the incompatibility we found, and the test will report 
> > whenever the incompatibility is solved.
> 
> The reason for suspending is exactly this.
> Testing only suspended tests will show exactly which case (if any) improved.
> 
> > Vincent

Yes this would be nice. Did we end up creating a folder for specific
tests like these? I remember we talked about it recently but not sure
what came of it.

Scott

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 20:20:31, schrieb Vincent van Ravesteijn 

> Op 4-11-2015 om 20:15 schreef Guenter Milde:
> > On 2015-11-04, Kornel Benko wrote:
> >
> >> [-- Type: text/plain, Encoding: quoted-printable --]
> >> Am Dienstag, 3. November 2015 um 00:23:47, schrieb Uwe Stöhr 
> >> 
> >>> commit 279d0849460aac82c3adeac42d3f0e255274e7c8
> >>> Author: Uwe Stöhr 
> >>> Date:   Tue Nov 3 00:23:41 2015 +0100
> >>>  Math.lyx: replace tables by formal ones - final part 7/7
> >
> >> With this commit there are new failing export tests.
> >> export/doc/Math_dvi3_texF
> >> export/doc/Math_pdf5_texF
> >> export/doc/de/Math_dvi3_texF
> >> export/doc/de/Math_pdf5_texF
> >> export/doc/es/Math_dvi3_texF
> >> export/doc/es/Math_pdf5_texF
> >> export/doc/fr/Math_dvi3_texF
> >> export/doc/fr/Math_pdf5_texF
> >> Apparently, we need more failing ...
> > This is both luatex export, what is the error message:
> >
> >! Argument of \__str_case_end:nw has an extra }.
> >
> >\par
> >l.573 \chemgreek_drop_symbols:
> >
> >Runaway argument?
> >! Paragraph ended before \__str_case_end:nw was complete.
> >
> >\par
> >l.573 \chemgreek_drop_symbols:
> >
> > Familiar from the XeTeX export. Same reason, incompatibility of
> > the chemgreek package (used by mhchem) with Xe/LuaTeX.
> >
> > Math.lyx with Xe/LuaTeX is a candidate for suspension.
> >
> > Günter
> Besides suspending the test, we should create a specific test that tests 
> the compatibility of chemgreek with Xe/LuaTeX and invert that test.

That would be nice.

> This documents the incompatibility we found, and the test will report 
> whenever the incompatibility is solved.

The reason for suspending is exactly this.
Testing only suspended tests will show exactly which case (if any) improved.

> Vincent

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 14:00:16, schrieb Scott Kostyshak 

> On Wed, Nov 04, 2015 at 07:28:50PM +0100, Kornel Benko wrote:
> > Am Dienstag, 3. November 2015 um 00:23:47, schrieb Uwe Stöhr 
> > 
> > > commit 279d0849460aac82c3adeac42d3f0e255274e7c8
> > > Author: Uwe Stöhr 
> > > Date:   Tue Nov 3 00:23:41 2015 +0100
> > > 
> > > Math.lyx: replace tables by formal ones - final part 7/7
> > > 
> > 
> > With this commit there are new failing export tests. 
> > 
> > export/doc/Math_dvi3_texF
> > export/doc/Math_pdf5_texF
> > 
> > export/doc/de/Math_dvi3_texF
> > export/doc/de/Math_pdf5_texF
> > 
> > export/doc/es/Math_dvi3_texF
> > export/doc/es/Math_pdf5_texF
> > 
> > export/doc/fr/Math_dvi3_texF
> > export/doc/fr/Math_pdf5_texF
> > 
> > Apparently, we need more failing ...
> 
> I think we should invert these based on Günter's advice here:
> https://www.mail-archive.com/search?l=mid&q=n0sne9%24iis%241%40ger.gmane.org
> 
> I already inverted the pdf4_texF here 50e99b82 but I did not invert the
> pdf5_texF there because they were passing (I suppose by luck). Perhaps
> this is a use case for suspended tests? I don't know.
> 
> Kornel, if you prefer to suspend or invert, I suggest you go ahead.

OK, I added them to reverted.

Reverted is changed to contain also dvi3_texF and pdf5_texF.
This means 70 more testcases are joined the suspend party.

I will test before committing, no one of the suspended tests should march to a 
different drummer.

> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: status update on the export tests

[Guenter Milde]

On 2015-11-04, Kornel Benko wrote:
> Am Mittwoch, 4. November 2015 um 15:36:45, schrieb Guenter Milde 
> 

...

>> Not only, with "suspending" I also mean "The outcome is of no value for
>> finding new bugs or regressions until someone solves the known bug ...".

> OK.

>> However, we usually know what the outcome should be if the bug is
>> solved: if the expected outcome is "pass", this test should not be
>> inverted.

> Here we disagree. Matter of taste I suppose. For me the test fails
> _now_. We don't care now (because we know what's going on etc.).
> Therefore the test is to be inverted as to not catch unwanted
> attention.

I still do not understand the reasoning. It will not catch attention if
it is suspended, that is why it should be suspended.

OTOH, if a test that should pass but does not is inverted & suspended (2
actions), we need to uninvert and to unsuspend (again 2 actions) once the
problem causing the failure is solved.

In contrast, if the "inversion status" matches the expected test result, we
can run suspended tests from time to time and "unsuspend" the tests that now
give the expected output.

Also, when looking at inverted tests, we do not know whether this is a 
"good" inversion (the test should fail) or a "bad" inversion (the test
should pass but currently does not).


Günter

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Vincent van Ravesteijn]

Op 4-11-2015 om 20:15 schreef Guenter Milde:

On 2015-11-04, Kornel Benko wrote:


[-- Type: text/plain, Encoding: quoted-printable --]
Am Dienstag, 3. November 2015 um 00:23:47, schrieb Uwe Stöhr 


commit 279d0849460aac82c3adeac42d3f0e255274e7c8
Author: Uwe Stöhr 
Date:   Tue Nov 3 00:23:41 2015 +0100
 Math.lyx: replace tables by formal ones - final part 7/7



With this commit there are new failing export tests.
export/doc/Math_dvi3_texF
export/doc/Math_pdf5_texF
export/doc/de/Math_dvi3_texF
export/doc/de/Math_pdf5_texF
export/doc/es/Math_dvi3_texF
export/doc/es/Math_pdf5_texF
export/doc/fr/Math_dvi3_texF
export/doc/fr/Math_pdf5_texF
Apparently, we need more failing ...

This is both luatex export, what is the error message:

   ! Argument of \__str_case_end:nw has an extra }.
   
   \par
   l.573 \chemgreek_drop_symbols:
   
   Runaway argument?

   ! Paragraph ended before \__str_case_end:nw was complete.
   
   \par
   l.573 \chemgreek_drop_symbols:

Familiar from the XeTeX export. Same reason, incompatibility of
the chemgreek package (used by mhchem) with Xe/LuaTeX.

Math.lyx with Xe/LuaTeX is a candidate for suspension.

Günter
Besides suspending the test, we should create a specific test that tests 
the compatibility of chemgreek with Xe/LuaTeX and invert that test.


This documents the incompatibility we found, and the test will report 
whenever the incompatibility is solved.


Vincent

Re: RFC: better submenu for tables

[Guenter Milde]

On 2015-11-04, Kornel Benko wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> Am Mittwoch, 4. November 2015 um 11:19:21, schrieb Richard Heck 
> 
>> On 11/04/2015 04:42 AM, Jean-Marc Lasgouttes wrote:
>> > Le 03/11/2015 01:43, Uwe Stöhr a écrit :
>> >> If you open the submenu of tables you see many entries. In my opinion
>> >> too many, at least too many for laptops with small screens.
>> >>
>> >> In general I think it should be less crowded. Thus a proposal:
>> >>
>> >> - everything is removed for which we also have toolbar button. (If users
>> >> disabled the automatic show of the table toolbar they apparently don't
>> >> use tables that much and the table settings dialog is sufficient)
>> >
>> > This is not how contextual menus are supposed to work IMO. I would 
>> > propose instead to use submenus and to micmick what libreoffice (for 
>> > ex.) does.

>> I personally hate toolbars and almost never use them. So I'd prefer that 
>> things not be removed simply because they're also on a toolbar.

> +1

Seconded.

Günter

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Guenter Milde]

On 2015-11-04, Kornel Benko wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> Am Dienstag, 3. November 2015 um 00:23:47, schrieb Uwe Stöhr 
> 
>> commit 279d0849460aac82c3adeac42d3f0e255274e7c8
>> Author: Uwe Stöhr 
>> Date:   Tue Nov 3 00:23:41 2015 +0100

>> Math.lyx: replace tables by formal ones - final part 7/7


> With this commit there are new failing export tests. 

> export/doc/Math_dvi3_texF
> export/doc/Math_pdf5_texF

> export/doc/de/Math_dvi3_texF
> export/doc/de/Math_pdf5_texF

> export/doc/es/Math_dvi3_texF
> export/doc/es/Math_pdf5_texF

> export/doc/fr/Math_dvi3_texF
> export/doc/fr/Math_pdf5_texF

> Apparently, we need more failing ...

This is both luatex export, what is the error message:

  ! Argument of \__str_case_end:nw has an extra }.
   
  \par 
  l.573 \chemgreek_drop_symbols:
  
  Runaway argument?
  ! Paragraph ended before \__str_case_end:nw was complete.
   
  \par 
  l.573 \chemgreek_drop_symbols:

Familiar from the XeTeX export. Same reason, incompatibility of
the chemgreek package (used by mhchem) with Xe/LuaTeX.

Math.lyx with Xe/LuaTeX is a candidate for suspension.

Günter

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Scott Kostyshak]

On Wed, Nov 04, 2015 at 07:28:50PM +0100, Kornel Benko wrote:
> Am Dienstag, 3. November 2015 um 00:23:47, schrieb Uwe Stöhr 
> 
> > commit 279d0849460aac82c3adeac42d3f0e255274e7c8
> > Author: Uwe Stöhr 
> > Date:   Tue Nov 3 00:23:41 2015 +0100
> > 
> > Math.lyx: replace tables by formal ones - final part 7/7
> > 
> 
> With this commit there are new failing export tests. 
> 
> export/doc/Math_dvi3_texF
> export/doc/Math_pdf5_texF
> 
> export/doc/de/Math_dvi3_texF
> export/doc/de/Math_pdf5_texF
> 
> export/doc/es/Math_dvi3_texF
> export/doc/es/Math_pdf5_texF
> 
> export/doc/fr/Math_dvi3_texF
> export/doc/fr/Math_pdf5_texF
> 
> Apparently, we need more failing ...

I think we should invert these based on Günter's advice here:
https://www.mail-archive.com/search?l=mid&q=n0sne9%24iis%241%40ger.gmane.org

I already inverted the pdf4_texF here 50e99b82 but I did not invert the
pdf5_texF there because they were passing (I suppose by luck). Perhaps
this is a use case for suspended tests? I don't know.

Kornel, if you prefer to suspend or invert, I suggest you go ahead.

Scott

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Kornel Benko]

Am Dienstag, 3. November 2015 um 00:23:47, schrieb Uwe Stöhr 

> commit 279d0849460aac82c3adeac42d3f0e255274e7c8
> Author: Uwe Stöhr 
> Date:   Tue Nov 3 00:23:41 2015 +0100
> 
> Math.lyx: replace tables by formal ones - final part 7/7
> 

With this commit there are new failing export tests. 

export/doc/Math_dvi3_texF
export/doc/Math_pdf5_texF

export/doc/de/Math_dvi3_texF
export/doc/de/Math_pdf5_texF

export/doc/es/Math_dvi3_texF
export/doc/es/Math_pdf5_texF

export/doc/fr/Math_dvi3_texF
export/doc/fr/Math_pdf5_texF

Apparently, we need more failing ...

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: [patch] Finding the generated latex file

[PhilipPirrip]

On 11/03/2015 07:00 PM, Andrew Parsloe wrote:


I have found the message helpful, particularly when developing a module
or a latex package to work with LyX. In the latter case, the failure to
remove the temp directory may indicate that a latex process is still
running. (Failure of a preview snippet for instance.) From experience I
know that this can lead to multiple occurrences of the latex executable
running at once, and LyX becoming more and more sluggish.



I personally find this very annoying. As a user. It doesn't happen on 
Linux, so I'm still good, but on Windows:
I tested the patch on Windows, no messages were shown if LyX was closed, 
Windows Explorer window would just close upon the deletion of the temp 
folder. But, if I had Acrobat Reader open with the document still loaded 
in, two error messages would pop out giving me totally irrelevant 
information... I press ok, and than what? LyX is going to close anyway, 
should I look for the temp folder and delete it myself?


I don't think this is the right way of debugging things. There's 
View>Message pane, why not just print the error message there. Worse 
things happen than the temp folder not being deleted and no windows pop 
out like this.

Re: RFC: better submenu for tables

[PhilipPirrip]

I agree with you, Uve.
I'd rather see a few submenus for setting tables, than this 'More...' 
that we have now. What do you mean "more" when nothing about setting the 
table was offered in the first contextual menu. This 'More..." should 
rather be "Table...".
I'd group things that are now in the submenu (row, column, lines, 
settings, etc), put those groups separately into the contextual menu.
What are the "move paragraph up/down" supposed to do for the tables? 
Paragraph settings - always disabled?





On 11/02/2015 07:43 PM, Uwe Stöhr wrote:

If you open the submenu of tables you see many entries. In my opinion
too many, at least too many for laptops with small screens.

In general I think it should be less crowded. Thus a proposal:

- everything is removed for which we also have toolbar button. (If users
disabled the automatic show of the table toolbar they apparently don't
use tables that much and the table settings dialog is sufficient)

- As result everything can be removed, but these settings are added:
   - set/unset formal table
   - set/unset longtable

The result will be a small and clean submenu.

opinions?

thanks and regards
Uwe

Re: RFC: better submenu for tables

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 11:19:21, schrieb Richard Heck 
> On 11/04/2015 04:42 AM, Jean-Marc Lasgouttes wrote:
> > Le 03/11/2015 01:43, Uwe Stöhr a écrit :
> >> If you open the submenu of tables you see many entries. In my opinion
> >> too many, at least too many for laptops with small screens.
> >>
> >> In general I think it should be less crowded. Thus a proposal:
> >>
> >> - everything is removed for which we also have toolbar button. (If users
> >> disabled the automatic show of the table toolbar they apparently don't
> >> use tables that much and the table settings dialog is sufficient)
> >
> > This is not how contextual menus are supposed to work IMO. I would 
> > propose instead to use submenus and to micmick what libreoffice (for 
> > ex.) does.
> 
> I personally hate toolbars and almost never use them. So I'd prefer that 
> things not be removed simply because they're also on a toolbar.

+1

> Richard

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: status update on the export tests

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 15:36:45, schrieb Guenter Milde 

> On 2015-11-04, Kornel Benko wrote:
> 
> > [-- Type: text/plain, Encoding: 7bit --]
> 
> > Am Mittwoch, 4. November 2015 um 14:36:19, schrieb Vincent van Ravesteijn 
> > 
> >> > In my view, suspension is orthogonal to reversion:
> >> >
> >> > - normal:  we want the test to pass
> >> >   revert:  we want the test to fail
> 
> >> You mean: revert is that "it is known to fail", but we haven't fixed it 
> >> yet.
> 
> > Yes. We hope to do it eventually.
> 
> We have also tests that correctly fail:
> "it is known to fail", there is nothing to fix, and we must ensure that it
> continues to fail.
> The third point is, what prevents us from ignoring this test.
> 
> >> > - normal:  run the test
> >> >   suspend: skip the test temporarily
> >> >   ignore:  skip the test permanently
> >> >
> 
> >> Suspending means: "The outcome is noisy, so skip it until someone
> >> looks into it and makes the test better."
> 
> > Sort of, if we are careful enough about which test should go there.
> 
> Not only, with "suspending" I also mean "The outcome is of no value for
> finding new bugs or regressions until someone solves the known bug ...".

OK.

> However, we usually know what the outcome should be if the bug is solved: if
> the expected outcome is "pass", this test should not be inverted.
> 

Here we disagree. Matter of taste I suppose.
For me the test fails _now_. We don't care now (because we know what's going on 
etc.).
Therefore the test is to be inverted as to not catch unwanted attention.

> > For the actual committed cmake build, suspended test means:
> > a.) Test is one of export tests
> > b.) Test is failing, and therefore it is part of revertedTests
> > c.) In 'normal' use like 'ctest -L export' it is hidden
> > d.) Test gets the ctest-label 'suspended'
> > You can run all suspended tests with 'ctest -L suspended'.
> > Or, for a known testname (say xyzzy) you can use 'ctest -R xyzzy'.
> 
> >> Ignore: Skipping a test permanently is the same as just removing the
> >> test.. ??
> 
> > This is effectively the same here. Because the testcase should be
> > ignored (it is part of ignoredTests) it will not be added with
> > add_test(). E.g. it is not known to ctest.
> 
> However, as the test rules are something like: "test exporting all our
> manuals to PDF (pdflatex)", we need to specify cases where a manual is
> known not to compile, e.g. because it relies on non-TeX fonts or special
> features of LuaTeX.

I was describing the machinery how our ctests currently works. Not politics, 
that is how we organize
our config files (ignoredTests, revertedTests, suspendedTests).

> Günter
> 

Kornel

signature.asc
Description: This is a digitally signed message part.

Two Shortcut Changes

[Richard Heck]

Attached are two patches inspired by bug #9830. The request there was to 
make master-buffer-view and master-buffer-update fall back to 
buffer-view and buffer-update, since it's annoying to have to use 
different shortcuts with different documents, if one is used to working 
with master documents. In fact, all that is really needed is to change 
the shortcuts to use command-alternatives. I've done this myself for a 
long time, and it seems a simple enough change. That is the first patch.


The second patch addresses a related but different issue. In cua.bind, 
C-S-T is bound to "buffer-update ps" and C-S-D to "buffer-update dvi". 
It seems to me that it would be good to have one of these bound to 
"buffer-update pdf" instead, and I'd make it C-S-T, as that is 
consistent with what we have in mac.bind.


Comments?

Richard

>From 218ea8d2f5e92af1b068952b1eb69f90775371ea Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Wed, 4 Nov 2015 11:26:36 -0500
Subject: [PATCH 1/2] Make shortcuts for master-buffer-X fall back to buffer-X.

---
 lib/bind/cua.bind | 10 +-
 lib/bind/mac.bind |  8 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/bind/cua.bind b/lib/bind/cua.bind
index b7903b6..2aa9be5 100644
--- a/lib/bind/cua.bind
+++ b/lib/bind/cua.bind
@@ -45,14 +45,14 @@ Format 2
 \bind "C-r"			"buffer-view"
 \bind "C-d"			"buffer-view dvi"	# 'd' for dvi
 \bind "C-t"			"buffer-view ps"
-\bind "C-M-r"			"master-buffer-view"
-\bind "C-M-t"			"master-buffer-view ps"
-\bind "C-M-d"			"master-buffer-view dvi"
+\bind "C-M-r"			"command-alternatives master-buffer-view; buffer-view"
+\bind "C-M-t"			"command-alternatives master-buffer-view ps; buffer-view ps"
+\bind "C-M-d"			"command-alternatives master-buffer-view dvi; buffer-view dvi"
 \bind "C-S-R"			"buffer-update"
 \bind "C-S-D"			"buffer-update dvi"	# 'd' for dvi
 \bind "C-S-T"			"buffer-update ps"
-\bind "C-M-S-t"			"master-buffer-update ps"
-\bind "C-M-S-d"			"master-buffer-update dvi"
+\bind "C-M-S-t"			"command-alternatives master-buffer-update ps; buffer-update ps"
+\bind "C-M-S-d"			"command-alternatives master-buffer-update dvi; buffer-update dvi"
 \bind "C-q"			"lyx-quit"
 \bind "C-Next"			"buffer-next"
 \bind "C-Tab"			"buffer-next"
diff --git a/lib/bind/mac.bind b/lib/bind/mac.bind
index 5190332..18d0862 100644
--- a/lib/bind/mac.bind
+++ b/lib/bind/mac.bind
@@ -136,7 +136,7 @@ Format 2
 #  +: "Option-Command-D" # Show or hide the Dock
 #  -: "Command-Control D"# Display the definition of the selected word in the Dictionary application
 \bind "C-d"  "buffer-view dvi"	# 'd' for dvi
-\bind "C-M-d""master-buffer-view dvi"
+\bind "C-M-d""command-alternatives master-buffer-view dvi; buffer.view dvi"
 \bind "C-S-D""buffer-update dvi"	# 'd' for dvi
 #  -: "Command-E"# Use the selection for a find
 \bind "C-e"  "font-emph"
@@ -176,7 +176,7 @@ Format 2
 \bind "C-S-S""buffer-write-as"
 #  -: "Command-T"# Display the Fonts window
 \bind "C-t"  "buffer-view pdf"
-\bind "C-M-t""master-buffer-view pdf"
+\bind "C-M-t""command-alternatives master-buffer-view pdf; buffer-view pdf"
 #  -: "Option-Command-T" # Show or hide a toolbar
 #  -: "Command-U"# Underline the selected text or turn underlining on or off
 \bind "C-u"  "font-underline"
@@ -253,8 +253,8 @@ Format 2
 \bind "C-S-O""font-strikeout"
 \bind "C-S-T""buffer-update pdf" # (pdflatex; was "ps")
 \bind "C-S-R""buffer-update"
-\bind "C-M-S-T"  "master-buffer-update pdf"
-\bind "C-M-S-D"  "master-buffer-update dvi"
+\bind "C-M-S-T"  "command-alternatives master-buffer-update pdf; buffer-update pdf"
+\bind "C-M-S-D"  "command-alternatives master-buffer-update dvi; buffer-update dvi"
 
 \bind "C-S-E""changes-track" # it's what MS Word uses
 \bind "~S-M-quotedbl""quote-insert single"
-- 
2.4.3

>From 9914eca0fa6ca3b6e03b364c512c0635be89edf1 Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Wed, 4 Nov 2015 11:27:28 -0500
Subject: [PATCH 2/2] Change Postscript shortcuts to PDF shortcuts.

---
 lib/bind/cua.bind | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/bind/cua.bind b/lib/bind/cua.bind
index 2aa9be5..b8c920c 100644
--- a/lib/bind/cua.bind
+++ b/lib/bind/cua.bind
@@ -44,14 +44,14 @@ Format 2
 \bind "C-S-S"			"buffer-write-as"
 \bind "C-r"			"buffer-view"
 \bind "C-d"			"buffer-view dvi"	# 'd' for dvi
-\bind "C-t"			"buffer-view ps"
+\bind "C-t"			"buffer-view pdf"
 \bind "C-M-r"			"command-alternatives master-buffer-view; buffer-vie

Re: RFC: better submenu for tables

[Richard Heck]

On 11/04/2015 04:42 AM, Jean-Marc Lasgouttes wrote:

Le 03/11/2015 01:43, Uwe Stöhr a écrit :

If you open the submenu of tables you see many entries. In my opinion
too many, at least too many for laptops with small screens.

In general I think it should be less crowded. Thus a proposal:

- everything is removed for which we also have toolbar button. (If users
disabled the automatic show of the table toolbar they apparently don't
use tables that much and the table settings dialog is sufficient)


This is not how contextual menus are supposed to work IMO. I would 
propose instead to use submenus and to micmick what libreoffice (for 
ex.) does.


I personally hate toolbars and almost never use them. So I'd prefer that 
things not be removed simply because they're also on a toolbar.


Richard

Re: status update on the export tests

[Guenter Milde]

On 2015-11-04, Kornel Benko wrote:

> [-- Type: text/plain, Encoding: 7bit --]

> Am Mittwoch, 4. November 2015 um 14:36:19, schrieb Vincent van Ravesteijn 
> 
>> > In my view, suspension is orthogonal to reversion:
>> >
>> > - normal:  we want the test to pass
>> >   revert:  we want the test to fail

>> You mean: revert is that "it is known to fail", but we haven't fixed it yet.

> Yes. We hope to do it eventually.

We have also tests that correctly fail:
"it is known to fail", there is nothing to fix, and we must ensure that it
continues to fail.
The third point is, what prevents us from ignoring this test.

>> > - normal:  run the test
>> >   suspend: skip the test temporarily
>> >   ignore:  skip the test permanently
>> >

>> Suspending means: "The outcome is noisy, so skip it until someone
>> looks into it and makes the test better."

> Sort of, if we are careful enough about which test should go there.

Not only, with "suspending" I also mean "The outcome is of no value for
finding new bugs or regressions until someone solves the known bug ...".
However, we usually know what the outcome should be if the bug is solved: if
the expected outcome is "pass", this test should not be inverted.


> For the actual committed cmake build, suspended test means:
>   a.) Test is one of export tests
>   b.) Test is failing, and therefore it is part of revertedTests
>   c.) In 'normal' use like 'ctest -L export' it is hidden
>   d.) Test gets the ctest-label 'suspended'
> You can run all suspended tests with 'ctest -L suspended'.
> Or, for a known testname (say xyzzy) you can use 'ctest -R xyzzy'.

>> Ignore: Skipping a test permanently is the same as just removing the
>> test.. ??

> This is effectively the same here. Because the testcase should be
> ignored (it is part of ignoredTests) it will not be added with
> add_test(). E.g. it is not known to ctest.

However, as the test rules are something like: "test exporting all our
manuals to PDF (pdflatex)", we need to specify cases where a manual is
known not to compile, e.g. because it relies on non-TeX fonts or special
features of LuaTeX.

Günter

Re: status update on the export tests

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 14:36:19, schrieb Vincent van Ravesteijn 

> > In my view, suspension is orthogonal to reversion:
> >
> > - normal:  we want the test to pass
> >   revert:  we want the test to fail
> 
> You mean: revert is that "it is known to fail", but we haven't fixed it yet.

Yes. We hope to do it eventually.

> >
> > - normal:  run the test
> >   suspend: skip the test temporarily
> >   ignore:  skip the test permanently
> >
> 
> Suspending means: "The outcome is noisy, so skip it until someone
> looks into it and makes the test better."

Sort of, if we are careful enough about which test should go there.

For the actual committed cmake build, suspended test means:
a.) Test is one of export tests
b.) Test is failing, and therefore it is part of revertedTests
c.) In 'normal' use like 'ctest -L export' it is hidden
d.) Test gets the ctest-label 'suspended'
You can run all suspended tests with 'ctest -L suspended'.
Or, for a known testname (say xyzzy) you can use 'ctest -R xyzzy'.

> Ignore: Skipping a test permanently is the same as just removing the test.. ??

This is effectively the same here. Because the testcase should be ignored (it 
is part of ignoredTests)
it will not be added with add_test(). E.g. it is not known to ctest.

> Vincent

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: status update on the export tests

[Vincent van Ravesteijn]

> In my view, suspension is orthogonal to reversion:
>
> - normal:  we want the test to pass
>   revert:  we want the test to fail

You mean: revert is that "it is known to fail", but we haven't fixed it yet.

>
> - normal:  run the test
>   suspend: skip the test temporarily
>   ignore:  skip the test permanently
>

Suspending means: "The outcome is noisy, so skip it until someone
looks into it and makes the test better."

Ignore: Skipping a test permanently is the same as just removing the test.. ??

Vincent

Re: Unit testing

[Vincent van Ravesteijn]

> If there is no known advantage of gtest, I suggest using one of
> boost::test or QTest, as these come from sources we already rely on.
>

The major advantage of "gtest" is that I only have to type "git push"
and we have the
framework up and running.

A downside of boost::test is, according someone on the internet, that
it heavily relies
on templates. This makes it slightly more difficult to debug, and
maybe slightly more
advanced usage.

All living souls on the planet already rely on Google anyhow... ;)

> However, I would also count as advantage, if there is someone familiar with
> the framework and willing to do the setup and lend a helping hand to others.
> (Maybe, the toolkit with the most developers willing to work on should win.)
>

We have discussed this topic several times, and no one ever stood up
with a strong
preference for, or claimed to have a lot of experience with one of the
frameworks.

Vincent

Re: status update on the export tests

[Guenter Milde]

On 2015-11-04, Kornel Benko wrote:
> Am Mittwoch, 4. November 2015 um 09:30:03, schrieb Guenter Milde 
> 
>> On 2015-11-02, Kornel Benko wrote:
>> > Am 2. November 2015 um 08:36:05, schrieb Guenter Milde 
>> >> On 2015-11-02, Scott Kostyshak wrote:
>> >> > On Sun, Nov 01, 2015 at 10:36:17PM +0100, Kornel Benko wrote:
>> >> >> Am 1. November 2015 um 21:27:11, schrieb Guenter Milde

>> >> >> > Could we introduce a new status "suspended" - meaning just skip the
>> >> >> > test until a known bug is solved as we know the result is
>> >> >> > insignificant until then?
...
>> >> Candidates for "suspended" tests are 

>> >> * "fragile" documents (many packages, ERT, heavy preamble, ...), 
>> >> * "fragile" export routes (XeTeX/LuaTeX with TeX fonts), 
>> >> * non-default export routes 
>> >> and especially combinations of these.


>> > OK, here is my suggestion
>> > 1.) We add the appropriate tests into revertedTests

>> Why? This would undo one important benefit of "suspended" tests:

> I was not clear about this. These tests will not be run with e.g.
> 'ctest -L export' (see the '-L' param). In this sense we get 'clean'
> export tests.

May be I was not clear either: 

In my view, suspension is orthogonal to reversion:

- normal:  we want the test to pass
  revert:  we want the test to fail

- normal:  run the test
  suspend: skip the test temporarily
  ignore:  skip the test permanently

In other words: while "normal" vs. "reverted" will be used to specify the
expected test result, ignore and suspend will be used if we established
the reason why a test currently gives the wrong result but cannot
immediately solve the issue.

Then we have 

* suspended reverted tests: should fail but currently passes, e.g.
wrong output/dataloss that does not lead to error.

* suspended normal tests: should pass but currently fails, e.g.
  ru/Intro.lyx with XeTeX+TeX-fonts

With the benefit:

>> >>   Suspending instead of reverting frees us from the need to
>> >>   reassess them if a change in the "real life documents" or a fix
>> >>   makes them pass again. Instead, they could/should be revised at a
>> >>   time we have fixed major known problems and no release
>> >>   pressure...


...

> So what do you propose for such tests (84% of export tests)?
> ctest -L export -N | wc => 3719
> ctest -L export -N |egrep '/(doc|examples)/'| wc => 3153
> 3153 / 3719 => 84.78%

I don't have any clue which tests are hidden behind these commands. The
general recipe is:

* inspect the file,
* run the export command "by hand",
* try to find the reason for the test failure result

If the current "inversion state" does not match the expected test outcome
(pass/fail), correct it.

If it is "easyfix", fix.
If fixing »the right way« takes time, suspend (stating the established
reason).

The idea is, to de-couple the test analysis (from failure to bug report)
from the repair of found problems. This will hopefully allow us 
to get the test suite clean without hackish quick-fixes.

> For now committed 1.b at 538228d

Thanks

Günter

Re: [LyX/master] Fix some XeTeX + TeX-fonts regressions introduced by fixing #9740.

[Jean-Marc Lasgouttes]

Le 04/11/2015 14:02, Guenter Milde a écrit :

Now, that your patch has been commited as well, do I need to do anything
about this?


No, it is OK now.

JMarc

Re: [LyX/master] Fix some XeTeX + TeX-fonts regressions introduced by fixing #9740.

[Guenter Milde]

On 2015-11-04, Jean-Marc Lasgouttes wrote:
> Le 04/11/2015 11:42, Stephan Witt a écrit :
>>> } else if (token == "\\pdf_quoted_options") {
>>> lex >> quoted_options;
>>> +   lyxerr << "Q_O=" << quoted_options << endl;
>>> } else {
>>> return token;
>>> }

>> Did you put this change in intentionally?

> No this one is mine from an unrelated patch Günter has been testing.

Now, that your patch has been commited as well, do I need to do anything
about this?

Günter

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 10:33:58, schrieb Guenter Milde 

> On 2015-11-03, Scott Kostyshak wrote:
> > On Tue, Nov 03, 2015 at 06:49:01AM -0800, Kornel Benko wrote:
> >> > 
> >> > * to fix the regressions with "XeTeX + TeX fonts", a simple change in
> >> >   PDFOptions.cpp is sufficient.
> 
> >> That is, 29 tests are now better than before.
> >> Checking the output, all 29 are of type pdf4_texF (XeTeX + TeX fonts).
> 
> Good news.
> 
> Committed: f739c98fd7aa9cc6c7607/lyxgit

Thanks.

> ...
> 
> >> > * the updated "comprehensive but incomplete" patch based on your work is 
> >> > now
> >> >   at http://www.lyx.org/trac/ticket/9839, so the work is not lost.
> >> >   
> >> >   With the "show output anyway" option in 2.2, the status quo is actually
> >> >   tolerable. I'll try the patch for #9830, then there is also a 
> >> > workaround for
> >> >   ASCII export (i.e. the user can write G\"unter instead of Günter).
> 
> > Do we have a bug report for the workaround for ASCII export?
> 
> I added a comment http://www.lyx.org/trac/ticket/9839#comment:1
> 
> ...
> 
> > Günter, thanks for your work on these tricky issues. After alpha is
> > released, let me know if there is anything pending that you would like
> > for me to work on. Since I know nothing about this topic, you would need
> > to break it down into simple steps like you did for me before so I can
> > focus on the C++.

+1

> Thanks for your offer. We will see what we can do one alpha is out...
> 
> I'll also have a look at the other FIXMES and may ask for help there.
> 
> 
> Günter

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: status update on the export tests

[Kornel Benko]

Am Mittwoch, 4. November 2015 um 09:30:03, schrieb Guenter Milde 

> On 2015-11-02, Kornel Benko wrote:
> > Am 2. November 2015 um 08:36:05, schrieb Guenter Milde 
> >> On 2015-11-02, Scott Kostyshak wrote:
> >> > On Sun, Nov 01, 2015 at 10:36:17PM +0100, Kornel Benko wrote:
> >> >> Am 1. November 2015 um 21:27:11, schrieb Guenter Milde
> 
> >> >> > Could we introduce a new status "suspended" - meaning just skip the
> >> >> > test until a known bug is solved as we know the result is
> >> >> > insignificant until then?
> 
> >> >> We already have such (specified in file "ignoredTests"). But as this
> >> >> tests are never executed, nobody cares for them anymore.
> >> >> The tests here are such, that we know, we never resolve them.
> 
> But even here, there are two cases: 
> 
> a) cases that fail for a good reason and should always fail 
>(e.g. export document with non-TeX fonts using 8-bit LaTeX)
>
> b) cases that should not fail but do (for reasons we cannot change).
> 
> While a) should be "permanently inverted" (to give a warning if a change
> makes the export pass but we expect the result to be faulty), b) is
> correctly placed in "ignored" -- the test case does not help detect LyX
> buts in any way.
> 
> 
> >> Suggestion:
> 
> >>   Specified in file "suspendedTests") with the reason for suspending
> >>   (bug report, commit that turned hidden problems into export failure, ...)
> 
> >>   These tests are normally skipped, but they are not forgotten.
> 
> >>   The tests here are such, that we know, we can resolve them but their
> >>   failure is a minor issue that can be postponed (comparable to enhancement
> >>   requests in Trac).
> 
> 
> >> Candidates for "suspended" tests are 
> 
> >> * "fragile" documents (many packages, ERT, heavy preamble, ...), 
> >> * "fragile" export routes (XeTeX/LuaTeX with TeX fonts), 
> >> * non-default export routes 
> 
> >> and especially combinations of these.
> 
> 
> > OK, here is my suggestion
> > 1.) We add the appropriate tests into revertedTests
> 
> Why? This would undo one important benefit of "suspended" tests:

I was not clear about this. These tests will not be run with e.g. 'ctest -L 
export' (see the '-L' param).
In this sense we get 'clean' export tests.

> >>   Suspending instead of reverting also frees us from the need to reassess
> >>   them if a change in the "real life documents" or a fix makes them pass
> >>   again. Instead, they could/should be revised at a time we have fixed
> >>   major known problems and no release pressure...
> 
> I'd only add the test to "revertedTests", too, if it is established that
> the correct result for this test is a failure.
> 
> > The content in suspendedTests may be (in our case) e.g.
> > pdf4_texF
> 
> > 1.a)
> > If a test is to be inverted, we check suspendedTest,
> > and if there, we ignore the testcase.
> 
> Here, I'd change the priority: 
>   
>   * with a normal run, all suspended tests are ignored,
>   
>   * with "run suspended tests" or "include suspended tests",
> suspended test are run, taking into consideration their
> "inversion state".
> 
> > or
> > 1.b)
> > Such a test may get a label "suspended" instead of
> > "export", so that 'ctest -L export' will be clean, but
> > we also have the possibility to use 'ctest -L
> > suspended'.
> 
> > This does neither effect non-inverted nor ignored.
> 
> My suggestion would affect non-inverted tests (the ones with the label
> "suspended").
> 
> This means for failing test you will have 3 options:
> 
> 1. if failing is the expected outcome: invert
> 2. if failing for permanent reasons that are none of our business: ignore
> 3. if failing for minor reasons or a known bug: suspend
> 
> Motivation: 
> 
> Some bugs only lead to failures depending on document content. We do
> "road testing" with real life documents (manuals, examples). Work on the
> documents could easily change the export status of tests without any
> progress on fixing the underlying problem! (Examples: adding/removing a
> character not available with non-default export route, adding non-ASCII
> character to the PDF Header Information with "inputenc=ascii",
> Writing my name as G\"unter in the PDF Header Information before solving
> #9830, ...)
> 
> However, editing manuals or examples should not require immediate
> revision of test cases using this document if the basic problem is not
> solved.

So what do you propose for such tests (84% of export tests)?
ctest -L export -N | wc => 3719
ctest -L export -N |egrep '/(doc|examples)/'| wc => 3153
3153 / 3719 => 84.78%

> OTOH, if bugs that triggered suspension of some test cases are solved,
> it is time to revisit the set of suspended tests, reactivate the ones
> that pass and re-label the ones that still fail.
> 
> 
> 
> > I prefer 1.b.
> 
> Whatever works best 

Re: [LyX/master] Fix some XeTeX + TeX-fonts regressions introduced by fixing #9740.

[Jean-Marc Lasgouttes]

Le 04/11/2015 11:42, Stephan Witt a écrit :

} else if (token == "\\pdf_quoted_options") {
lex >> quoted_options;
+   lyxerr << "Q_O=" << quoted_options << endl;
} else {
return token;
}


Did you put this change in intentionally?


No this one is mine from an unrelated patch Günter has been testing.

JMarc

Re: [LyX/master] Fix some XeTeX + TeX-fonts regressions introduced by fixing #9740.

[Stephan Witt]

Am 04.11.2015 um 11:21 schrieb Günter Milde :

> commit f739c98fd7aa9cc6c7607b2eb9e8f8da2727e988
> Author: Günter Milde 
> Date:   Wed Nov 4 11:21:22 2015 +0100
> 
>Fix some XeTeX + TeX-fonts regressions introduced by fixing #9740.
> 
>hyperref expects LICR macros for non-ASCII chars in the PDF Header 
> Information.
>As hyperref provides good coverage for \inputencoding{utf8}, we try
>this if the current input encoding does not support a character.
> 
>With XeTeX, we do not load inputenc and cannot use \inputencoding.
>However, utf-8 works out of the box so we can write the content in UTF8.
> 


> 
> @@ -247,6 +240,7 @@ string PDFOptions::readToken(Lexer &lex, string const & 
> token)
>   lex >> pagemode;
>   } else if (token == "\\pdf_quoted_options") {
>   lex >> quoted_options;
> + lyxerr << "Q_O=" << quoted_options << endl;
>   } else {
>   return token;
>   }

Did you put this change in intentionally?

Stephan

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

On Wed, Nov 4, 2015 at 7:26 AM, Pavel Sanda  wrote:
> Guillaume Munch wrote:
>> For \track_changes, I do not understand your rationale for making it a
>> setting of the document. It is not locked on, so the user who edits the
>> documentations has to know in any case that he should track changes (if I
>> had not been told to, then I'd have turned it off even if it was on).
>
> I consider it also document, not user, setting. It would cause confusions
> if this setting is not transfered to my collaborators within the document.
>

I disagree. There is no confusion possible.

If it was, then we should also make the cursor position a document
property, so my collaborator would not be confused where to start
writing ...

Vincent

Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".

[Guenter Milde]

On 2015-11-03, Scott Kostyshak wrote:
> On Tue, Nov 03, 2015 at 06:49:01AM -0800, Kornel Benko wrote:
>> > 
>> > * to fix the regressions with "XeTeX + TeX fonts", a simple change in
>> >   PDFOptions.cpp is sufficient.

>> That is, 29 tests are now better than before.
>> Checking the output, all 29 are of type pdf4_texF (XeTeX + TeX fonts).

Good news.

Committed: f739c98fd7aa9cc6c7607/lyxgit

...

>> > * the updated "comprehensive but incomplete" patch based on your work is 
>> > now
>> >   at http://www.lyx.org/trac/ticket/9839, so the work is not lost.
>> >   
>> >   With the "show output anyway" option in 2.2, the status quo is actually
>> >   tolerable. I'll try the patch for #9830, then there is also a workaround 
>> > for
>> >   ASCII export (i.e. the user can write G\"unter instead of Günter).

> Do we have a bug report for the workaround for ASCII export?

I added a comment http://www.lyx.org/trac/ticket/9839#comment:1

...

> Günter, thanks for your work on these tricky issues. After alpha is
> released, let me know if there is anything pending that you would like
> for me to work on. Since I know nothing about this topic, you would need
> to break it down into simple steps like you did for me before so I can
> focus on the C++.

Thanks for your offer. We will see what we can do one alpha is out...

I'll also have a look at the other FIXMES and may ask for help there.


Günter

Re: status update on the export tests

[Kornel Benko]

Am Montag, 2. November 2015 um 08:39:59, schrieb Guenter Milde 

> On 2015-11-02, Scott Kostyshak wrote:
> 
> > Good point. On the other hand, if we make regex changes then it is
> > harder to revert them. Problems have come up before of us
> > misconstructing the regexes.
> 
> If possible, make separate regexp patterns for separate "fail reasons".
> Then, we just have to delete one regexp if the cause for the inversion is
> gone...

I don't understand. There is no such reference in testcase-names.

> Günter

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

On Wed, Nov 4, 2015 at 1:50 AM, Guillaume Munch  wrote:
> Le 03/11/2015 21:16, Georg Baum a écrit :
>>
>> Guillaume Munch wrote:
>>
>>> 
>>>
>>> I am bringing this to the list due to the timing, due to the fact that
>>> it is a file format change, and due to the fact that it looks severe in
>>> the above context.
>>>
>>> I suggest moving these settings to the user preferences.
>>>
>>> Can we agree on the issue? On the solution? Is it easy to do?
>>
>>
>> I don't think there is an easy solution, because it depends on the use
>> case.
>> For example, in our documentation workflows \tracking_changes needs to be
>> the same for all users, so this should not go into the preferences. For
>> the
>> other two I am not sure.
>>
>
> For context:
>
> \justification : whether justification is displayed in the LyX window (does
> not affect output)

user preference.

>
> \track_changes : whether the track changes button is enabled (does not
> affect the existing contents)

user-per-document preference.

>
> \output_changes : whether the changes are displayed in the output (I can
> agree that this one could be considered as part of the document.)
>

user-per-document preference.

> Also, is there a way to have settings which are per-user *and* per-file?
>

Yes, we write for instance the cursor position per file into the session file.

Vincent

screen indenting after frames

[Edwin Leuven]

dear all,

atm when using beamer the text is indented after a new frame:

Frame  [title]

->|Text starts here

and with a fragile frame it is indented even more

Frame (fragile)  [title]

>|Text starts here


not only is the unequal indenting across different frame types ugly,
but i find this indenting more in general a waste of screen estate

i was therefore wondering whether there is a way to get rid of it altogether?

thanks, edwin

Re: Plan for the current testing situation

[Guenter Milde]

On 2015-11-02, Georg Baum wrote:
> Scott Kostyshak wrote:

>> So in summary, regarding the XeTeX + TeX fonts, I propose the above policy
>> to start with; and if we find that there really is such a low signal to
>> noise ratio then we can change our minds and ignore them. But we will
>> never know what the signal to noise ratio is if we just ignore them now.

> This does all make sense (including the snipped part). Nevertheless I'd like 
> to propose that we put some intermediate steps in:

> 1) Fix the first half of bug #9744. This is an easy and safe change 

Actually, "allowing parallel configuration of TeX and non-TeX fonts" is a
precondition for the proposed config value "automatic" for "use non-TeX
fonts":

* Currently, the LyX file stores font configuration only for one font set,
  either TeX-fonts or non-TeX-fonts, however
  
* documents with non-default fonts usually require configuration for both sets
  to get a consistent look (e.g. choose Times/Helvetica/Courier lookalikes
  or "Linux Libertine" fonts - be it 8-bit or Unicode encoded fonts).
  
* Documents using non-Latin scripts or "exotic" accented characters may even
  fail to compile with the default fonts (either TeX or non-TeX) due to our
  new "missing character" error.
  (E.g. the "Latin Modern" default for non-TeX fonts has no small Greek
  letters nor Cyrillic ones.)
  
> which has the additional benefit to make most of Günters concerns about
> the "View XeTeX" toolbar button much less important. 

Just using non-TeX fonts will lead to failures with, e.g., all Russian,
Bulgarian, Serbian, Greek and Hebrew manuals!

> Also, if we do not do it before 2.2.0, we cannot do it for 2.2.x (file
> format change). 

This also regards both parts of the proposed change.

> Günter, maybe you want to have a try yourself (if Scott agrees to do
> this before 2.2.0)?

I am willing to help but cannot do this.

> 2) Set the new "automatic" value for "use non-TeX fonts" for all documents 
> that should work with XeTeX in principle

> 3) Re-evaluate the test status and decide then whether some tests do still 
> need to be suspended or inverted.

> My guess would be that after these three steps, the tests would be much more 
> usable, and that the tests that do then still fail would point to real 
> problems which should not be ignored.

As said above, many documents that shall work with XeTeX "in principle"
require font customization with non-TeX fonts.

Maybe we need a "default non-TeX fonts mechanism" for non-Latin scripts.

Günter

Re: RFC: better submenu for tables

[Jean-Marc Lasgouttes]

Le 03/11/2015 01:43, Uwe Stöhr a écrit :

If you open the submenu of tables you see many entries. In my opinion
too many, at least too many for laptops with small screens.

In general I think it should be less crowded. Thus a proposal:

- everything is removed for which we also have toolbar button. (If users
disabled the automatic show of the table toolbar they apparently don't
use tables that much and the table settings dialog is sufficient)


This is not how contextual menus are supposed to work IMO. I would 
propose instead to use submenus and to micmick what libreoffice (for 
ex.) does.



- As result everything can be removed, but these settings are added:
   - set/unset formal table
   - set/unset longtable


Yes.

JMarc

Re: status update on the export tests

[Guenter Milde]

On 2015-11-02, Kornel Benko wrote:
> Am 2. November 2015 um 08:36:05, schrieb Guenter Milde 
>> On 2015-11-02, Scott Kostyshak wrote:
>> > On Sun, Nov 01, 2015 at 10:36:17PM +0100, Kornel Benko wrote:
>> >> Am 1. November 2015 um 21:27:11, schrieb Guenter Milde

>> >> > Could we introduce a new status "suspended" - meaning just skip the
>> >> > test until a known bug is solved as we know the result is
>> >> > insignificant until then?

>> >> We already have such (specified in file "ignoredTests"). But as this
>> >> tests are never executed, nobody cares for them anymore.
>> >> The tests here are such, that we know, we never resolve them.

But even here, there are two cases: 

a) cases that fail for a good reason and should always fail 
   (e.g. export document with non-TeX fonts using 8-bit LaTeX)
   
b) cases that should not fail but do (for reasons we cannot change).

While a) should be "permanently inverted" (to give a warning if a change
makes the export pass but we expect the result to be faulty), b) is
correctly placed in "ignored" -- the test case does not help detect LyX
buts in any way.


>> Suggestion:

>>   Specified in file "suspendedTests") with the reason for suspending
>>   (bug report, commit that turned hidden problems into export failure, ...)

>>   These tests are normally skipped, but they are not forgotten.

>>   The tests here are such, that we know, we can resolve them but their
>>   failure is a minor issue that can be postponed (comparable to enhancement
>>   requests in Trac).


>> Candidates for "suspended" tests are 

>> * "fragile" documents (many packages, ERT, heavy preamble, ...), 
>> * "fragile" export routes (XeTeX/LuaTeX with TeX fonts), 
>> * non-default export routes 

>> and especially combinations of these.


> OK, here is my suggestion
> 1.) We add the appropriate tests into revertedTests

Why? This would undo one important benefit of "suspended" tests:

>>   Suspending instead of reverting also frees us from the need to reassess
>>   them if a change in the "real life documents" or a fix makes them pass
>>   again. Instead, they could/should be revised at a time we have fixed
>>   major known problems and no release pressure...

I'd only add the test to "revertedTests", too, if it is established that
the correct result for this test is a failure.

> The content in suspendedTests may be (in our case) e.g.
>   pdf4_texF

>   1.a)
>   If a test is to be inverted, we check suspendedTest,
>   and if there, we ignore the testcase.

Here, I'd change the priority: 

* with a normal run, all suspended tests are ignored,

* with "run suspended tests" or "include suspended tests",
  suspended test are run, taking into consideration their
  "inversion state".

> or
>   1.b)
>   Such a test may get a label "suspended" instead of
>   "export", so that 'ctest -L export' will be clean, but
>   we also have the possibility to use 'ctest -L
>   suspended'.

> This does neither effect non-inverted nor ignored.

My suggestion would affect non-inverted tests (the ones with the label
"suspended").

This means for failing test you will have 3 options:

1. if failing is the expected outcome: invert
2. if failing for permanent reasons that are none of our business: ignore
3. if failing for minor reasons or a known bug: suspend

Motivation: 

Some bugs only lead to failures depending on document content. We do
"road testing" with real life documents (manuals, examples). Work on the
documents could easily change the export status of tests without any
progress on fixing the underlying problem! (Examples: adding/removing a
character not available with non-default export route, adding non-ASCII
character to the PDF Header Information with "inputenc=ascii",
Writing my name as G\"unter in the PDF Header Information before solving
#9830, ...)

However, editing manuals or examples should not require immediate
revision of test cases using this document if the basic problem is not
solved.

OTOH, if bugs that triggered suspension of some test cases are solved,
it is time to revisit the set of suspended tests, reactivate the ones
that pass and re-label the ones that still fail.



> I prefer 1.b.

Whatever works best in praxi.

Günter

Re: Unit testing

[Guenter Milde]

On 2015-11-03, Georg Baum wrote:
> Vincent van Ravesteijn wrote:
>> On Tue, Nov 3, 2015 at 2:28 PM, Jean-Marc Lasgouttes 
>> wrote:

> Regarding the test framework there is also boost::test (which would fit our 
> needs as well). Unfortunately I have neither experience with gtest nor with 
> QTest, so I don't know how it compares to these frameworks. Anyway, I think 
> the most important thing is to have a working setup, so I don't care much 
> which framework is used in the end.


If there is no known advantage of gtest, I suggest using one of
boost::test or QTest, as these come from sources we already rely on.

However, I would also count as advantage, if there is someone familiar with
the framework and willing to do the setup and lend a helping hand to others.
(Maybe, the toolkit with the most developers willing to work on should win.)

Günter