date:20151101

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

2015-11-01 Thread Kornel Benko

Am Sonntag, 1. November 2015 um 11:52:26, schrieb Kornel Benko 
> Am Samstag, 31. Oktober 2015 um 19:11:10, schrieb Scott Kostyshak 
> 
> > On Sat, Oct 31, 2015 at 05:57:46PM -0400, Scott Kostyshak wrote:
> > > On Sat, Oct 31, 2015 at 09:21:15PM +, Guenter Milde wrote:
> > 
> > > > I'd prefer you to do this.
> > > 
> > > OK I'll work on it.
> > 
> > Does the attached patch look good?
> > 
> > We need to do something similar for the other FIXMEs you put in
> > 1523fc60, right?
> > 
> > Scott
> 
> Applying this patch now _all_ export tests 'export/.*(pdf|dvi)' are failing.
> Probably because the patch is only partial I suppose.
> 

I was too fast. The first 208 (out of 3761) did not pass as I wrote the mail.
Now I see some other passing.
I will report the outcome, have to wait a 'little' more.

Kornel

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

RE: #9529: copy / pasting only works first time Lyx 2.1.3 windows 8

2015-11-01 Thread Andrew

Skostysh, after installing Ubuntu I had no further problems with that issue. 
Actually now I am running Windows 10 and haven't encountered it either 
(although I also went from 2gb to 8gb of ram, so I wonder if that helped). 

-Original Message-
From: LyX Ticket Tracker [mailto:t...@lyx.org] 
Sent: Saturday, October 31, 2015 9:34 PM
To: backun...@gmail.com; lasgout...@lyx.org
Subject: Re: #9529: copy / pasting only works first time Lyx 2.1.3 windows 8

#9529: copy / pasting only works first time Lyx 2.1.3 windows 8
---+-
 Reporter:  backuntri  |   Owner:  lasgouttes
 Type:  defect |  Status:  new
 Priority:  normal |   Milestone:  2.2.0
Component:  general| Version:  2.1.3
 Severity:  normal |  Resolution:
 Keywords: |
---+-

Comment (by skostysh):

 backuntri, have you been able to reproduce on the full Ubuntu installation  
you did? I still wonder if this is Windows-specific.

--
Ticket URL: 
The LyX Project 
LyX -- The Document Processor

Re: #9627: Make the document name available to preview insets

2015-11-01 Thread Andrew Parsloe


On 1/11/2015 4:55 p.m., LyX Ticket Tracker wrote:

#9627: Make the document name available to preview insets
---+-
  Reporter:  aparsloe   |   Owner:  lasgouttes
  Type:  enhancement|  Status:  new
  Priority:  normal |   Milestone:  2.2.0
Component:  preview-latex  | Version:  2.1.3
  Severity:  normal |  Resolution:
  Keywords: |
---+-

Comment (by skostysh):

  Is anyone planning to work on this for 2.2.0? It doesn't seem like there
  is even agreement on what to do.

One way of achieving this would be to write a text file to the temporary 
directory for the given document. The text file has one line containing 
the document name (without the .lyx extension) and a distinctive file 
name like lyxjob.name. Latex files, when previewed, can look for 
lyxjob.name and read it's content. (It's certainly simple to do this 
with the expl3 macros of LaTeX3.) Thus when lyx_tmpbuf0 etc are created 
they are not empty, as at present, but contain a one-line file lyxjob.name.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

2015-11-01 Thread Kornel Benko

Am Sonntag, 1. November 2015 um 11:55:47, schrieb Kornel Benko 
> Am Sonntag, 1. November 2015 um 11:52:26, schrieb Kornel Benko 
> 
> > Am Samstag, 31. Oktober 2015 um 19:11:10, schrieb Scott Kostyshak 
> > 
> > > On Sat, Oct 31, 2015 at 05:57:46PM -0400, Scott Kostyshak wrote:
> > > > On Sat, Oct 31, 2015 at 09:21:15PM +, Guenter Milde wrote:
> > > 
> > > > > I'd prefer you to do this.
> > > > 
> > > > OK I'll work on it.
> > > 
> > > Does the attached patch look good?
> > > 
> > > We need to do something similar for the other FIXMEs you put in
> > > 1523fc60, right?
> > > 
> > > Scott
> > 
> > Applying this patch now _all_ export tests 'export/.*(pdf|dvi)' are failing.
> > Probably because the patch is only partial I suppose.
> > 
> 
> I was too fast. The first 208 (out of 3761) did not pass as I wrote the mail.
> Now I see some other passing.
> I will report the outcome, have to wait a 'little' more.
> 

It turned out, that all but the first 208 testcases pass.
Comparing the failed with the list of previously failed, there is no difference.

So even if your patch does not improve any test, it does not harm either.

Kornel

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

Re: Upgrade to boost 1.59?

2015-11-01 Thread Vincent van Ravesteijn

On Sun, Nov 1, 2015 at 4:51 PM, Scott Kostyshak  wrote:
> On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:
>> Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:
>> >On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:
>> >
>> >>I have it documented somewhere. Should I put it in development.lyx ?
>> >
>> >If you are able to find it easily then I would say yes, please do. Even
>> >though Peter already did the update it could be useful in the future.
>> >
>> >Scott
>> >
>>
>> Just call in boost extract.sh with the path to the new boot version,
>> then "git add --all", commit. That's it.
>
> Thanks, Peter. It is good to know it is so straightforward.
>
> Scott

It's only that simple if you have installed the bcp utility.

I have made a script that automatically downloads the latest boost,
unpacks the tar, compiles bcp, and uses it when running the extract
script. I'll share it later.

Vincent

Re: lyx2lyx bugs from export tests

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 01:36:53PM -0500, Scott Kostyshak wrote:
> On Sun, Nov 01, 2015 at 11:52:08AM -0500, Richard Heck wrote:
> > On 11/01/2015 11:37 AM, Scott Kostyshak wrote:
> > >On Sun, Nov 01, 2015 at 11:32:17AM -0500, Richard Heck wrote:
> > >>On 10/31/2015 05:47 PM, Scott Kostyshak wrote:
> > >>>The list of tests at the bottom of this message pass on current master
> > >>>[1] but do not pass on current master after exporting the .lyx files to
> > >>>2.1.x format. So this is in some sense a compilation test of roundtrip
> > >>>lyx2lyx.
> > >>Is what this shows just that exporting to 2.1.x format and then 
> > >>re-importing
> > >>to current format doesn't produce the same file? If so, then that isn't
> > >>itself a sign of any problem, since lyx2lyx almost never produces the same
> > >>file on roundtrip. This is because reversion often uses ERT.
> > >By "compilation test" I mean that it is a test of whether the LaTeX
> > >compiles with error. So each item on the list compiles without error but
> > >after exporting and re-importing it compiles with error. This is not a
> > >good test because it will miss many bugs, but it seems to me that a
> > >failure does suggest something to look at.
> > 
> > OK, well, that is more of a problem. Do you have any automated way to figure
> > out which step is causing the problem? One way to do this would be to export
> > to 498 and re-import, etc, and then see where it fails. Then we would at
> > least know which reversion-conersion sequence was the cause of the problem.
> 
> OK I will look into it and let you know.

497 is fine, 498 produces an error. One thing that is strange is that
after exporting to 498 in the .lyx file there is:
\lyxformat 474

I am using the command
/home/scott/lyxbuilds/master/repo/lib/lyx2lyx/lyx2lyx -t 498 
EmbeddedObjects.lyx > temp.lyx

Scott

Re: Upgrade to boost 1.59?

2015-11-01 Thread Scott Kostyshak

On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:
> Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:
> >On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:
> >
> >>I have it documented somewhere. Should I put it in development.lyx ?
> >
> >If you are able to find it easily then I would say yes, please do. Even
> >though Peter already did the update it could be useful in the future.
> >
> >Scott
> >
> 
> Just call in boost extract.sh with the path to the new boot version,
> then "git add --all", commit. That's it.

Thanks, Peter. It is good to know it is so straightforward.

Scott

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

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 01:13:39PM +0100, Kornel Benko wrote:
> Am Sonntag, 1. November 2015 um 11:55:47, schrieb Kornel Benko 
> 
> > Am Sonntag, 1. November 2015 um 11:52:26, schrieb Kornel Benko 
> > 
> > > Am Samstag, 31. Oktober 2015 um 19:11:10, schrieb Scott Kostyshak 
> > > 
> > > > On Sat, Oct 31, 2015 at 05:57:46PM -0400, Scott Kostyshak wrote:
> > > > > On Sat, Oct 31, 2015 at 09:21:15PM +, Guenter Milde wrote:
> > > > 
> > > > > > I'd prefer you to do this.
> > > > > 
> > > > > OK I'll work on it.
> > > > 
> > > > Does the attached patch look good?
> > > > 
> > > > We need to do something similar for the other FIXMEs you put in
> > > > 1523fc60, right?
> > > > 
> > > > Scott
> > > 
> > > Applying this patch now _all_ export tests 'export/.*(pdf|dvi)' are 
> > > failing.
> > > Probably because the patch is only partial I suppose.
> > > 
> > 
> > I was too fast. The first 208 (out of 3761) did not pass as I wrote the 
> > mail.
> > Now I see some other passing.
> > I will report the outcome, have to wait a 'little' more.
> > 

Thanks for running the tests, Kornel.

> It turned out, that all but the first 208 testcases pass.
> Comparing the failed with the list of previously failed, there is no 
> difference.

I think that ctest always runs the failed tests first. This has
surprised me before.

> So even if your patch does not improve any test, it does not harm either.

OK let's wait and see what Günter says then. I'm not even confident my
patch is correct. If he confirms that it is, then I can go on and make
the full patch. I'm not sure if the full patch is supposed to fix any
tests (although it would be nice if it whittles down some of those 208).

Scott

Re: lyx2lyx bugs from export tests

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 11:52:08AM -0500, Richard Heck wrote:
> On 11/01/2015 11:37 AM, Scott Kostyshak wrote:
> >On Sun, Nov 01, 2015 at 11:32:17AM -0500, Richard Heck wrote:
> >>On 10/31/2015 05:47 PM, Scott Kostyshak wrote:
> >>>The list of tests at the bottom of this message pass on current master
> >>>[1] but do not pass on current master after exporting the .lyx files to
> >>>2.1.x format. So this is in some sense a compilation test of roundtrip
> >>>lyx2lyx.
> >>Is what this shows just that exporting to 2.1.x format and then re-importing
> >>to current format doesn't produce the same file? If so, then that isn't
> >>itself a sign of any problem, since lyx2lyx almost never produces the same
> >>file on roundtrip. This is because reversion often uses ERT.
> >By "compilation test" I mean that it is a test of whether the LaTeX
> >compiles with error. So each item on the list compiles without error but
> >after exporting and re-importing it compiles with error. This is not a
> >good test because it will miss many bugs, but it seems to me that a
> >failure does suggest something to look at.
> 
> OK, well, that is more of a problem. Do you have any automated way to figure
> out which step is causing the problem? One way to do this would be to export
> to 498 and re-import, etc, and then see where it fails. Then we would at
> least know which reversion-conersion sequence was the cause of the problem.

OK I will look into it and let you know.

> >Since you brought it up though, Kornel and I have discussed comparing
> >the .tex files. While we understand that the .lyx files are not expected
> >to be the same (for the reason you mentioned above), do you think it is
> >reasonable to expect the LaTeX output to be the same?
> 
> Not really. It'd be more reasonable to expect the compiled documents (PDFs,
> e.g.) to be the same, but even that we do not always guarantee.

I see. So it is reasonable to expect a md5sum on the PDFs to be the
same?

Scott

Re: lyx2lyx bugs from export tests

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 11:32:17AM -0500, Richard Heck wrote:
> On 10/31/2015 05:47 PM, Scott Kostyshak wrote:
> >The list of tests at the bottom of this message pass on current master
> >[1] but do not pass on current master after exporting the .lyx files to
> >2.1.x format. So this is in some sense a compilation test of roundtrip
> >lyx2lyx.
> 
> Is what this shows just that exporting to 2.1.x format and then re-importing
> to current format doesn't produce the same file? If so, then that isn't
> itself a sign of any problem, since lyx2lyx almost never produces the same
> file on roundtrip. This is because reversion often uses ERT.

By "compilation test" I mean that it is a test of whether the LaTeX
compiles with error. So each item on the list compiles without error but
after exporting and re-importing it compiles with error. This is not a
good test because it will miss many bugs, but it seems to me that a
failure does suggest something to look at.

Since you brought it up though, Kornel and I have discussed comparing
the .tex files. While we understand that the .lyx files are not expected
to be the same (for the reason you mentioned above), do you think it is
reasonable to expect the LaTeX output to be the same?

Scott

Re: lyx2lyx bugs from export tests

2015-11-01 Thread Richard Heck


On 10/31/2015 05:47 PM, Scott Kostyshak wrote:

The list of tests at the bottom of this message pass on current master
[1] but do not pass on current master after exporting the .lyx files to
2.1.x format. So this is in some sense a compilation test of roundtrip
lyx2lyx.


Is what this shows just that exporting to 2.1.x format and then 
re-importing to current format doesn't produce the same file? If so, 
then that isn't itself a sign of any problem, since lyx2lyx almost never 
produces the same file on roundtrip. This is because reversion often 
uses ERT.


Richard




Any lyx2lyx experts want to take a look?

Scott

[1] I am running the tests after the following command:
git revert --no-edit c061e339 3d521cfc 664ef2c4 2aa65fdc
36b9645b 1523fc60
I'm doing this because otherwise there are so many failures (many for
good reason) that we might miss some regressions.

export/doc/EmbeddedObjects_dvi
export/doc/EmbeddedObjects_dvi3_texF
export/doc/EmbeddedObjects_dvi3_systemF
export/doc/EmbeddedObjects_pdf
export/doc/EmbeddedObjects_pdf2
export/doc/EmbeddedObjects_pdf3
export/doc/EmbeddedObjects_pdf4_texF
export/doc/EmbeddedObjects_pdf4_systemF
export/doc/EmbeddedObjects_pdf5_texF
export/doc/EmbeddedObjects_pdf5_systemF
export/doc/Intro_pdf2
export/doc/Math_pdf2
export/doc/Tutorial_pdf2
export/doc/UserGuide_pdf2
export/doc/attic/eu_Additional_pdf2
export/doc/attic/eu_UserGuide_pdf2
export/doc/attic/it_UserGuide_pdf2
export/doc/attic/pl_Additional_pdf2
export/doc/attic/sk_UserGuide_pdf2
export/doc/ca/Intro_pdf2
export/doc/de/Customization_pdf2
export/doc/de/EmbeddedObjects_dvi
export/doc/de/EmbeddedObjects_dvi3_texF
export/doc/de/EmbeddedObjects_dvi3_systemF
export/doc/de/EmbeddedObjects_pdf
export/doc/de/EmbeddedObjects_pdf2
export/doc/de/EmbeddedObjects_pdf3
export/doc/de/EmbeddedObjects_pdf4_texF
export/doc/de/EmbeddedObjects_pdf4_systemF
export/doc/de/EmbeddedObjects_pdf5_texF
export/doc/de/EmbeddedObjects_pdf5_systemF
export/doc/de/Intro_pdf2
export/doc/de/Math_pdf2
export/doc/de/Tutorial_pdf2
export/doc/de/UserGuide_pdf2
export/doc/el/Intro_pdf2
export/doc/es/EmbeddedObjects_dvi
export/doc/es/EmbeddedObjects_dvi3_texF
export/doc/es/EmbeddedObjects_dvi3_systemF
export/doc/es/EmbeddedObjects_pdf
export/doc/es/EmbeddedObjects_pdf2
export/doc/es/EmbeddedObjects_pdf3
export/doc/es/EmbeddedObjects_pdf4_texF
export/doc/es/EmbeddedObjects_pdf4_systemF
export/doc/es/EmbeddedObjects_pdf5_texF
export/doc/es/EmbeddedObjects_pdf5_systemF
export/doc/es/Intro_pdf2
export/doc/es/Math_pdf2
export/doc/es/Tutorial_pdf2
export/doc/es/UserGuide_pdf2
export/doc/eu/Tutorial_pdf2
export/doc/fr/EmbeddedObjects_dvi
export/doc/fr/EmbeddedObjects_dvi3_texF
export/doc/fr/EmbeddedObjects_dvi3_systemF
export/doc/fr/EmbeddedObjects_pdf
export/doc/fr/EmbeddedObjects_pdf2
export/doc/fr/EmbeddedObjects_pdf3
export/doc/fr/EmbeddedObjects_pdf4_texF
export/doc/fr/EmbeddedObjects_pdf4_systemF
export/doc/fr/EmbeddedObjects_pdf5_texF
export/doc/fr/EmbeddedObjects_pdf5_systemF
export/doc/fr/Intro_pdf2
export/doc/fr/Math_pdf2
export/doc/fr/Tutorial_pdf2
export/doc/fr/UserGuide_pdf2
export/doc/gl/Tutorial_pdf2
export/doc/hu/Intro_pdf2
export/doc/id/Intro_pdf2
export/doc/id/Tutorial_pdf2
export/doc/id/UserGuide_pdf2
export/doc/it/Intro_pdf2
export/doc/ja/EmbeddedObjects_dvi
export/doc/ja/EmbeddedObjects_pdf
export/doc/ja/EmbeddedObjects_pdf3
export/doc/nb/Intro_pdf2
export/doc/uk/Intro_pdf2
export/doc/zh_CN/Intro_pdf2
export/doc/zh_CN/Tutorial_pdf2
export/examples/PDF-form_pdf2
export/examples/PDF-form_pdf5_texF
export/examples/PDF-form_pdf5_systemF
export/examples/beamer_pdf2
export/examples/beamerposter_pdf2
export/examples/chessgame_pdf3
export/examples/colored-boxes_dvi
export/examples/colored-boxes_dvi3_texF
export/examples/colored-boxes_dvi3_systemF
export/examples/colored-boxes_pdf
export/examples/colored-boxes_pdf2
export/examples/colored-boxes_pdf3
export/examples/colored-boxes_pdf4_texF
export/examples/colored-boxes_pdf4_systemF
export/examples/colored-boxes_pdf5_texF
export/examples/colored-boxes_pdf5_systemF
export/examples/landslide_pdf2
export/examples/spreadsheet_dvi
export/examples/spreadsheet_pdf
export/examples/spreadsheet_pdf2
export/examples/spreadsheet_pdf3
export/examples/xypic_pdf2
export/examples/de/beamer_pdf2
export/examples/fr/xypic_pdf2

Re: Upgrade to boost 1.59?

2015-11-01 Thread Peter Kümmel

Using bcp from older boost releases also works, so the one from your package 
manager should be enough.
Peter 

Am 1. November 2015 17:42:51 MEZ, schrieb Vincent van Ravesteijn :
>On Sun, Nov 1, 2015 at 4:51 PM, Scott Kostyshak 
>wrote:
>> On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:
>>> Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:
>>> >On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn
>wrote:
>>> >
>>> >>I have it documented somewhere. Should I put it in development.lyx
>?
>>> >
>>> >If you are able to find it easily then I would say yes, please do.
>Even
>>> >though Peter already did the update it could be useful in the
>future.
>>> >
>>> >Scott
>>> >
>>>
>>> Just call in boost extract.sh with the path to the new boot version,
>>> then "git add --all", commit. That's it.
>>
>> Thanks, Peter. It is good to know it is so straightforward.
>>
>> Scott
>
>It's only that simple if you have installed the bcp utility.
>
>I have made a script that automatically downloads the latest boost,
>unpacks the tar, compiles bcp, and uses it when running the extract
>script. I'll share it later.
>
>Vincent

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: When to court Qt 5.6?

2015-11-01 Thread Georg Baum

Scott Kostyshak wrote:

> I was wrong---Qt 5.6 beta has now been delayed to 12 November. You can
> read the short discussion regarding the delay here:
> http://permalink.gmane.org/gmane.comp.lib.qt.releasing/1826
> We have a few options as to what we should do about LyX 2.2.0 alpha:
> 
> 1. Wait a couple weeks for Qt 5.6 beta to release alpha.
> 
> 2. Release alpha sooner with the Qt 5.6 snapshot. There is "Not full set
> of installers but at least one for each platform" [1]:
> http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/
> The beta blockers are here:
> https://bugreports.qt.io/browse/QTBUG-47958
> 
> 3. Release alpha sooner with Qt 5.5.1 (just released two weeks ago).

Since LyX is not tied to a qt version in general, I assume you mean the 
windows installer. I agree with Pavel here, I would not wait any longer and 
release the alpha now (and releasing means to publish source tarballs). If 
the windows installer comes later this is no problem IMHO (also for beta, 
and if people complain we can explain why and ask them to help or shup up).

Georg

Re: status update on the export tests

2015-11-01 Thread Georg Baum

Kornel Benko wrote:

> Am Sonntag, 1. November 2015 um 21:46:00, schrieb Georg Baum
> 
>> 
>> We have a chicken and egg problem here. I started to work on the language
>> nesting stuff, and fixing this without introducing regressions is
>> impossible without creating specific test cases first. So, for this
>> particular area of the code, the tests are already unusable, and we
>> cannot get it into a good state again without usable tests...
> 
> It is not only you. If our tests were usable at that time, then it would
> have been easy to check and set the appropriate tests in reverted drawer.

Definitely.

>> In principle I am with Kornel here, but in the current situation I think
>> the only option we have is to set up more specific tests, fix the code
>> one bug at a time, and then begin to look at the automatic export tests
>> again. In the mean time, I don't care too much whether the failing tests
>> are inverted or not.
> 
> 
> Does it mean 'delay 2.2 alpha'?

I don't think so. 2.1 has language nesting bugs as well, and the more simple 
cases do work. But we should probably mention that there are known language 
nesting bugs in the release notes. It is alpha after all (and I still hope 
to get some safe improvement for the beta).


Georg

Re: lyx2lyx bugs from export tests

2015-11-01 Thread Richard Heck


On 11/01/2015 01:49 PM, Scott Kostyshak wrote:

On Sun, Nov 01, 2015 at 01:36:53PM -0500, Scott Kostyshak wrote:

On Sun, Nov 01, 2015 at 11:52:08AM -0500, Richard Heck wrote:

On 11/01/2015 11:37 AM, Scott Kostyshak wrote:

On Sun, Nov 01, 2015 at 11:32:17AM -0500, Richard Heck wrote:

On 10/31/2015 05:47 PM, Scott Kostyshak wrote:

The list of tests at the bottom of this message pass on current master
[1] but do not pass on current master after exporting the .lyx files to
2.1.x format. So this is in some sense a compilation test of roundtrip
lyx2lyx.

Is what this shows just that exporting to 2.1.x format and then re-importing
to current format doesn't produce the same file? If so, then that isn't
itself a sign of any problem, since lyx2lyx almost never produces the same
file on roundtrip. This is because reversion often uses ERT.

By "compilation test" I mean that it is a test of whether the LaTeX
compiles with error. So each item on the list compiles without error but
after exporting and re-importing it compiles with error. This is not a
good test because it will miss many bugs, but it seems to me that a
failure does suggest something to look at.

OK, well, that is more of a problem. Do you have any automated way to figure
out which step is causing the problem? One way to do this would be to export
to 498 and re-import, etc, and then see where it fails. Then we would at
least know which reversion-conersion sequence was the cause of the problem.

OK I will look into it and let you know.

497 is fine, 498 produces an error. One thing that is strange is that
after exporting to 498 in the .lyx file there is:
\lyxformat 474

I am using the command
/home/scott/lyxbuilds/master/repo/lib/lyx2lyx/lyx2lyx -t 498 EmbeddedObjects.lyx 
> temp.lyx


The problem is that EmbeddedObjects.lyx was already format 498, and 
lyx2lyx seems to do the wrong thing when asked to convert it to the 
format it already is, i.e., to convert to 498.


I've committed a patch that simply does the null conversion in this 
case. As I say in the commit message, this seems better than aborting 
with an error.


Richard

Re: Changebar module file

2015-11-01 Thread Guillaume Munch


Le 01/11/2015 23:01, Jean-Marc Lasgouttes a écrit :

Le 01/11/15 23:48, Guillaume Munch a écrit :

List, is the attached correct?


I'd say yes. I do not like much the extra redefinition, but the only
other solution is plain \def. BTW, as it is implemented here, if it
works reliably, this looks like something that is easy to add natively
in LyX.



Thanks.

Yes, this has been discussed in the thread, but: 1) it does not work 
with XeTeX, and 2) nobody stepped forward.


Guillaume

Re: Changebar module file

2015-11-01 Thread Guillaume Munch


Le 01/11/2015 23:01, Jean-Marc Lasgouttes a écrit :

Le 01/11/15 23:48, Guillaume Munch a écrit :

List, is the attached correct?


I'd say yes. I do not like much the extra redefinition, but the only
other solution is plain \def. BTW, as it is implemented here, if it
works reliably, this looks like something that is easy to add natively
in LyX.




It's in at 646be959.

Re: [LyX/master] Add warning message if we do no conversion.

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 08:04:28PM -0500, Richard Heck wrote:
> On 11/01/2015 07:54 PM, Scott Kostyshak wrote:
> >On Sun, Nov 01, 2015 at 10:33:09PM +0100, Richard Heck wrote:
> >>commit 4c16c61579d37f00c252ace8cf79d0573ca626bb
> >>Author: Richard Heck 
> >>Date:   Sun Nov 1 16:32:52 2015 -0500
> >>
> >> Add warning message if we do no conversion.
> >Why have a warning?
> >
> >We do not have a warning for:
> >lyx -e lyx21x Customization.21.lyx
> >where Customization.21.lyx is already in 2.1.x format.
> >
> >There is no warning for:
> >convert abc.jpg abc.jpg
> 
> > convert nipaudit2014-004.jpg a.jpg
> > diff nipaudit2014-004.jpg a.jpg
> Binary files nipaudit2014-004.jpg and a.jpg differ
> 
> So apparently not a no-op.
> 
> >ffmpeg -i abc.flac abc.flac
> >
> >These are a little different though because I think they do actually do
> >something (not sure what though).
> 
> Yes, I think because there are certain defaults in place. In fact, I get:
> >ffmpeg -i a.mp4 b.mp4
> [aac @ 0x16ec700] The encoder 'aac' is experimental but experimental codecs
> are not enabled, add '-strict -2' if you want to use it.

OK those were indeed bad examples by me then.

dos2unix seems like a better example:

$ mv mynotes testing1
$ cp testing1 testing2
$ dos2unix testing1
dos2unix: converting file testing1 to Unix format ...
$ md5sum testing1 testing2
9ca7056b4ba26136eb22fe885a6704b2  testing1
9ca7056b4ba26136eb22fe885a6704b2  testing2

> >On the other hand, I do see some reasoning for the change. Why would
> >someone try to convert a file to the same format? If they are doing
> >that, then maybe they misunderstood something so we should give a
> >warning to make sure they did not make a mistake and want to export to a
> >different format. Is that the correct reasoning?
> 
> Yes, that was the idea. It's a somewhat strange thing to do. As I said,
> there's a perfectly good reason to do it---batch conversion---but it's not
> the normal case, and it seems worth at least saying, "Hey, you might want to
> check this".

Makes sense. I just wonder why no other conversion tool (either on
command line, or in a programming language) that I know of behaves like
this. Sometimes though it is good to break convention.

> The way lyx2lyx is called from LyX itself, this would never happen: We don't
> try to do that ourselves.

> So it would only happen from the command line in which case the warning
> can be ignored easily enough.

I don't know if I like this asymmetry between GUI and command line.

In any case, my objection falls under the category of "nitpicking" so
I'm fine with the change. We should discuss more important things :)
Sometimes I have to remind myself of that.

Scott

Re: status update on the export tests

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 09:48:28PM +, Guenter Milde wrote:
> On 2015-11-01, Kornel Benko wrote:

> > Most of these tests were working some time ago. 
> 
> Many of them "by chance": not failing but with incorrect output (Missing
> characters, wrong characters) or "fragile" (working, but would fail by
> addition of one non-ASCII character, say).

Agreed. I don't think "by chance" correctly describes the missing
characters situation, but only the "fragile" documents.

> > We already have many inverted test.
> 
> This also adds to the impression, that this is an area where test
> failures are to be expected for many reasons. I.e. the signal to noise ratio
> is rather bad for XeTeX+TeX fonts and we would be better of without these
> tests.

This might be. I admit I have very little knowledge of XeTeX + TeX
fonts.

> > I am strongly against such policy. First one has to check if the reason is 
> > really
> > babel/polyglossia conflict.
> 
> There are many more reasons, mhchem, babel language files, font problems, ...
> 
> The combination XeTeX + TeX-fonts is not supported by many packages,
> including standard LaTeX packages like "inputenc"! OTOH, it is so obscure
> that it is really not worth wasting much time to work around all the
> problems. Rather treat/document it as: avoid if possible, use at your own
> risk.

I am starting to be open to this idea. If it is true that performing a
simple, correct operation in a document leads to a significant chance of
it breaking compilation of XeTeX with TeX fonts, then it is true that
this could cause a lot of noise. On one hand, our manuals were pretty
darn complicated and compiled just fine with TeX fonts. This might be
partly due to 'luck' but since they use so many packages and ERT and
weird constructs, that would be a lot of luck. I guess the main issue is
the missing characters.

Scott

Plan for the current testing situation

2015-11-01 Thread Scott Kostyshak

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?

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). The only way I think there
will be support for this policy is if the tests are not fragile. If tests
commonly break even though a commit does not introduce a real bug, then this
policy would just create a lot of pain without much use. I think that
non-fragile export tests are a real possibility, but some changes might be
needed to achieve this.

Back from my dream world, the problem with the current situtation is that so
many tests are failing (200 or so) that it makes it difficult to see if there
are new regressions. Especially as we move forward in the release process,
catching new regressions is extremely important. I thus propose some temporary
measures to get a clean test output. I think that the tests that are failing
because of known bugs should be inverted. For example, the tests that are
failing because of the change from babel to polyglossia could be inverted and
marked with the reason why they are inverted, and referred to in a bug report.
Georg (who did not introduce the regressions but is kindly working on them) is
aware of the failing tests, and is also working on better tests that are
specific to testing language nesting, so in some sense the tests have already
done their job and we should move on for now.

A source of fragile tests is the XeTeX tests with TeX fonts. Günter has pointed
out that exporting using XeTeX and TeX fonts could go from succeeding to
failing because of an added package, addition of one non-ASCII character, babel
language files, font problems, and other issues. Further, we should not expect
that many users are using XeTeX with TeX fonts because it is not common (there
is a separate discussion we are having on discouraging such a combination).
Thus, a good question is should we even have tests for this combination?

It seems to me that the underlying causes of the XeTeX + TeX fonts tests will
not be fixed anytime soon (and that this is OK) so we have two options if we
want to clean up the test output. We can either invert the current test
failures or ignore all XeTeX TeX font tests. Ignoring the tests means that they
will not be run. Whether we invert or ignore basically depends on how low we
think the signal to noise ratio is. I am open to both possibilities, depending
on what others prefer. I do have a preference for inverting the current tests
(and not ignoring). I'm not convinced that the signal to noise ratio is *so*
low. If there is a significant chance that these tests will catch bugs that our
other tests should not, they should be kept. I thus propose to invert the
current failures (and specify the reason each is failing) and then to treat
future XeTeX TeX font failures as failures of fragile tests. In some sense,
fragile tests can be OK if we know they are fragile and treat them as such. We
could amend our policy to be such that if XeTeX + TeX font tests fail, the
author of the commit that broke them can simply invert them without having the
responsibility of fixing them. The advantage of still keeping them (and not
"ignoring" them) is that the author of the commit might realize "my commit
should not have broken these tests" and thus find a bug in the commit. For
example, many commits do not even intend to change LaTeX. You might think that
other tests would catch most bugs, but sometimes only a couple of tests fail
because of an obscure bug. For example, a couple of weeks ago a commit caused
export of our Japanese knitr and Sweave manuals to hang (and only these
manuals). I don't even know if the output of those manuals is correct but the
tests still helped in preventing a regression and if those tests had been
ignored the tests would not have caught the regression.

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

Re: [LyX/master] Add warning message if we do no conversion.

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 10:33:09PM +0100, Richard Heck wrote:
> commit 4c16c61579d37f00c252ace8cf79d0573ca626bb
> Author: Richard Heck 
> Date:   Sun Nov 1 16:32:52 2015 -0500
> 
> Add warning message if we do no conversion.

Why have a warning?

We do not have a warning for:
lyx -e lyx21x Customization.21.lyx
where Customization.21.lyx is already in 2.1.x format.

There is no warning for:
convert abc.jpg abc.jpg
ffmpeg -i abc.flac abc.flac

These are a little different though because I think they do actually do
something (not sure what though).

In the programming languages I know, there is no warning for something
like:

tolower('abc')

Or

echo "abc" | sed 's/a/a/'

On the other hand, I do see some reasoning for the change. Why would
someone try to convert a file to the same format? If they are doing
that, then maybe they misunderstood something so we should give a
warning to make sure they did not make a mistake and want to export to a
different format. Is that the correct reasoning?

Scott

Re: [LyX/master] Add warning message if we do no conversion.

2015-11-01 Thread Richard Heck

On 11/01/2015 07:54 PM, Scott Kostyshak wrote:

On Sun, Nov 01, 2015 at 10:33:09PM +0100, Richard Heck wrote:

commit 4c16c61579d37f00c252ace8cf79d0573ca626bb
Author: Richard Heck 
Date:   Sun Nov 1 16:32:52 2015 -0500

 Add warning message if we do no conversion.

Why have a warning?

We do not have a warning for:
lyx -e lyx21x Customization.21.lyx
where Customization.21.lyx is already in 2.1.x format.

There is no warning for:
convert abc.jpg abc.jpg

> convert nipaudit2014-004.jpg a.jpg
> diff nipaudit2014-004.jpg a.jpg
Binary files nipaudit2014-004.jpg and a.jpg differ

So apparently not a no-op.

ffmpeg -i abc.flac abc.flac

These are a little different though because I think they do actually do
something (not sure what though).

Yes, I think because there are certain defaults in place. In fact, I get:
>ffmpeg -i a.mp4 b.mp4
[aac @ 0x16ec700] The encoder 'aac' is experimental but experimental 
codecs are not enabled, add '-strict -2' if you want to use it.

In the programming languages I know, there is no warning for something
like:

tolower('abc')

Or

echo "abc" | sed 's/a/a/'

On the other hand, I do see some reasoning for the change. Why would
someone try to convert a file to the same format? If they are doing
that, then maybe they misunderstood something so we should give a
warning to make sure they did not make a mistake and want to export to a
different format. Is that the correct reasoning?

Yes, that was the idea. It's a somewhat strange thing to do. As I said, 
there's a perfectly good reason to do it---batch conversion---but it's 
not the normal case, and it seems worth at least saying, "Hey, you might 
want to check this".

The way lyx2lyx is called from LyX itself, this would never happen: We 
don't try to do that ourselves. So it would only happen from the command 
line, in which case the warning can be ignored easily enough.

Richard

Re: When to court Qt 5.6?

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 09:37:54PM +0100, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > I was wrong---Qt 5.6 beta has now been delayed to 12 November. You can
> > read the short discussion regarding the delay here:
> > http://permalink.gmane.org/gmane.comp.lib.qt.releasing/1826
> > We have a few options as to what we should do about LyX 2.2.0 alpha:
> > 
> > 1. Wait a couple weeks for Qt 5.6 beta to release alpha.
> > 
> > 2. Release alpha sooner with the Qt 5.6 snapshot. There is "Not full set
> > of installers but at least one for each platform" [1]:
> > http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/
> > The beta blockers are here:
> > https://bugreports.qt.io/browse/QTBUG-47958
> > 
> > 3. Release alpha sooner with Qt 5.5.1 (just released two weeks ago).
> 
> Since LyX is not tied to a qt version in general, I assume you mean the 
> windows installer.

Yes. And Mac installer.

> I agree with Pavel here, I would not wait any longer and 
> release the alpha now (and releasing means to publish source tarballs). If 
> the windows installer comes later this is no problem IMHO (also for beta, 
> and if people complain we can explain why and ask them to help or shup up).

Sounds good.

Scott

Re: #9785: lstinline in footnotes

2015-11-01 Thread Guillaume Munch


Dear Uwe,


Le 27/10/2015 00:40, Uwe Stöhr a écrit :

Am 26.10.2015 um 17:21 schrieb Guillaume Munch:


The user reported two valid use cases that are exceptions to this
behaviour: \lstinline and \usepackage{bigfoot}. This used to work before
⇒ regression.


As I wrote, I don't agree. We had a valid bug report where a user put a
listings inset in a footnote and the result was uncompilable.


I would be more convinced by your message if:
* you referred to #9321 as it is: a user reporting a crash,
* you were able to explain the cause of this crash,
* that point was not already raised in my message.


Therefore
this was forbidden and even backported to LyX 2.1.x


That nobody objected to your patch back then does not sound like an 
argument to me.




If you want a proper fix, then we must automatically add the "inline"
option if a listings inset is placed into a footnote or margin note.


I like your suggestion, but now see my other message.



That one can use listings in footnote nevertheless with special settings
or by adding preamble code doesn't matter in my opinion. The default
placement does not compile and average users obviously run into problems.
Imagine you write a thesis and your document becomes uncompilable. You
don't know why because the LaTeX error message is mystery for you since
you use LyX to hide LaTeX commands from you. That could suck a lot!

Those who know special settings and even preamble code to get listings
in footnotes,  can add \footnote{ as ERT before the listing and } behind
it. That is not much work and you still have LyX's full listings features.

So the question is who we address as user? In my opinion we should
address average users and they use in most cases default settings since
they are no experts. If this breaks compilation we should not allow this.




I see several issues with your approach.

You keep referring to "average users" vs. "expert users" but this 
distinction seems quite idealised. Anybody can copy-paste LaTeX code 
from the internet. On the other hand, from past experience with using 
ERT for a specialised package, this solution is too cumbersome to be 
advocated as long-term.


You propose to apply an idealised principle pushed to the extreme. A 
crash is "fixed" by curing the symptom. That a user took the time to 
complain about a regression does not count in the balance. ERT becomes a 
permanent solution rather than a workaround, in the name of principles.


And to me it looks like it is missing the point, because the compilation 
argument is the only one which I did not object to; I even suggested 
that it was a separate issue.




Sincerely,
Guillaume

Re: lyx2lyx bugs from export tests

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 09:56:55PM +0100, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > On Sun, Nov 01, 2015 at 11:52:08AM -0500, Richard Heck wrote:
> >> On 11/01/2015 11:37 AM, Scott Kostyshak wrote:
> >> 
> >> >Since you brought it up though, Kornel and I have discussed comparing
> >> >the .tex files. While we understand that the .lyx files are not expected
> >> >to be the same (for the reason you mentioned above), do you think it is
> >> >reasonable to expect the LaTeX output to be the same?
> 
> If you want to test lyx2lyx, then I would strongly advise to test lyx2lyx 
> alone, without LyX. This would be exactly the same procedure as we do with 
> tex2lyx: For each test case, keep the expected output of lyx2lyx as 
> reference, and verify once (when creating the test), that LyX will produce 
> the correct output. When testing, do only compare the lyx2lyx output against 
> the refernce. If you keep LyX (and even pdflatex) in the chain, then you 
> will be testing lyx2lyx, LyX and pdflatex at the same time, which will 
> increase the probability of failing tests, and the search for the cause will 
> be more difficult.

Agreed. This would be nice. The "lyx2lyx" tests I'm doing now are just
cheap tests, which I think are better than no tests. I will add your
suggestion to the TestsToDo file. Hopefully someone will be interested
in implementing them someday.

> >> Not really. It'd be more reasonable to expect the compiled documents
> >> (PDFs, e.g.) to be the same, but even that we do not always guarantee.
> > 
> > I see. So it is reasonable to expect a md5sum on the PDFs to be the
> > same?
> 
> No. The PDF contains time stamps, and more stuff that depends on the 
> pdflatex version etc.

I see. I was thinking of holding constant the pdflatex version, but this
would still have the time stamp problem.

> Finally I have a general remark: The forward conversion in lyx2lyx is much 
> more important than the backward conversion, and the only one we guarantee 
> to work for each format step. The backward conversion is only implemented 
> for those cases where it is possible with reasonable effort. If we start to 
> test lyx2lyx, then we should start with the forward conversion.

I did not know this. Good to know.

Scott

Re: status update on the export tests

2015-11-01 Thread Scott Kostyshak

On Sun, Nov 01, 2015 at 10:36:17PM +0100, Kornel Benko wrote:
> Am Sonntag, 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?

As Kornel mentions, we have "ignoredTests" for this.

> > This way, known problems will not mask new problems.

I agree with this goal. The current situation is a problem because like
you say it might mask new problems. I agree with Kornel that ignored
tests are not the solution. But I think that inverting the tests might
be a temporary solution. The only way to get clean working tests would
be to rever the commits and I don't think that is the right action for
this situation.

> 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.
> Example:
> We write a lyx file for odt/word/whatever output only. There is sense to 
> expect
> valid latex.

I agree. We should not use ignored tests for temporary issues. Once we
put something in ignoredTests chances are strong that we will forget
about them for a long time.

Scott

Re: [patch] use setProcessEnvironment, not shell escape (cmd / env)

2015-11-01 Thread PhilipPirrip

Hi Enrico, thank you for your response. I hope the others will help us
resolve this too.

I propose another simple test, it will show you that env variables do get
set by setProcessEnvironment(). Attaching the modified files.
Hope you'll trust me now ;)

There is nothing to trust but something to understand. A script without a
shebang line is executed by the current shell and QProcess doesn't take
that into account. Your example works because you add a shebang to your
script. This has a real impact and can cause hard to understand bugs.
Please, try reading the thread here:
http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg169545.html
to see that this causes real problems.

I'd rather call this a bug in the script than in setProcessEnvironment
and QProcess. Why would they need to guess what shell they have to
execute. Isn't it polite, at least, for each shell script to have a
shebang line?

http://unix.stackexchange.com/questions/87560/does-the-shebang-determine-the-shell-which-runs-the-script

Does the same 'bug' happen on Windows, or is this only for the shell
'bugs' on *nix?

Something tells me we're never gonna agree, so I'll rest my case.
Nothing has to be changed in SystemcallPrivate::startProcess part of the
code for the BIBINPUTS to work. It would be nice, I think, for many
other reasons, but that's totally up to you.

Fail: "Exec format error" in your test example only points to the fact
that QProcess does not know it's supposed to spawn a shell and execute
the script in it, nothing more.
If instead of myprog script you had a real binary executable (like
proc->start("/usr/bin/ls") or proc->start("/usr/bin/env")) no "Exec
format error" would appear in either case. Why?

It maybe does not execute cmd_ if cmd_="some.bat", but will execute
cmd_="cmd.exe /c some.bat". The shell will (hopefully) have the environment
variables set by setProcessEnvironment().
(bat files are not executables by themselves, are they? windows, when you
click on them, starts them by opening cmd.exe first)
This just means that some.bat is not a good cmd, and should be changed to
"cmd.exe /c some.bat"
(now... who and where uses .bat's?)

Now I hope you are joking. What would you think if you had to call a
converter of yours as "bash myscript" instead of simply "myscript"?
Do you expect to have to do that?

Well, isn't that what Windows does? Isn't that why you had to go back to
using QProcess when calling a viewer on Windows instead of the script...
You didn't want that black window to pop out, right? bat files are not
executables, they can be executed... by an executable, which is in this
case cmd.exe. I'm not pretending I know everything about this, I'm
telling all this from my limited experience.

How many faulty converters are there in LyX? Why do they have to be run
the same way LaTeX are, by using latexEnvCmdPrefix? Does evince
(pdf viewer) really need TEXINPUTS variable that gets set by using
latexEnvCmdPrefix?

Batch files are executable and you don't have to type "cmd /c some.bat"
to execute them but simply "some". The "cmd /c" prefix is necessary to
overcome the silly limitations imposed by QProcess.

You type some, but Windows has to spawn a shell, cmd.com, to execute it.
some.bat has no binary code in it, and it is not executable in that sense.

In a more conservative approach, BIBINPUTS support could be added by the
patch I proposed on http://www.lyx.org/trac/ticket/2645

This can be done, if now the limit for a command line on Windows is 8191
characters as documented at https://support.microsoft.com/en-us/kb/830473
but you are forgetting BSTINPUTS and TEXFONTS.

Did anyone complain about the lack of these two? I don't think many people
would need them. The reason I need them are all these ugly hacks with
\input@path here http://wiki.lyx.org/BibTeX/Biblatex

The fact that these two are not useful for you doesn't mean that they
are not useful. And even if people doesn't ask for them means nothing.
It may simply be that they are not aware of them. As an example, see
http://www.lyx.org/trac/ticket/6634 where TEXFONTS was not explicitly
requested but would have solved that problem.

I know, but by the same argument nothing's worth fixing before we can
fix EVERYTHING. biblatex support won't be possible until it's total, no
one wants partial solutions - hope it's not that what you're saying.
Anway... some of the developers here assumed TEXINPUTS covers even bib
files. (see the posts on \input@path) I wouldn't mind if BIBINPUTS were
not even configurable, make them . and the current document directory.
I don't see why this is such a big deal. It's even standard latex
behavior, it always searches in the current dir. The trouble with LyX is
that it compiles in a temp dir, but does not copy any files it does not
know of.

Points to be discussed are:

- Should those variables simply replicate the setting for TEXINPUTS?
· Consider that