Re: [patch] update PDF viewers in configure.py

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 12:18:59AM +0200, Uwe Stöhr wrote:
> El 30.07.2017 a las 23:47, Jean-Marc Lasgouttes escribió:
> 
> > > would therefore like to support it in LyX.
> > 
> > To be frank I never heard of it before today. It seems to be some 
> > commercial program which only can be found as demo. I am not very fond of 
> > promoting such things.
> 
> It is not a demo. Only if you want to have all features like e.g. splitting
> PDF pages one has to buy another version. So it is the same as with Acrobat
> Reader, for the full feature set of Acrobat one has to pay.
> 
> There are packages for Master PDF in the Debian/Ubuntu and Arch package
> system available maybe for other package systems too.
> 
> In general I don't think we should judge programs according to their
> business model. LyX does not force to use a program he might not like. If a
> user likes a closed source program like Acrobat Reader it is very helpful
> that LyX checks for it.

I use Master PDF Editor and think it is a good program. I have never
paid for it, and have used it quite a bit, without noticing any missing
features (I'm not saying there are none, just that I haven't noticed
any). Another positive thing for me is that the developers are
responsive to feedback (they're available through direct email support).
They make frequent releases, and have a detailed change log:

https://code-industry.net/what-is-new-in-master-pdf-editor-4/

My initial reservation for including it as a viewer is that it really is
meant to be an editor, not a viewer. However, I just opened a multi-page
PDF, and I can now see how someone might want to use it as a viewer
(even though I would personally still prefer a more simple viewer): it
seems smooth and responsive, and has continuous scrolling; and I'm not
surprised by Uwe's finding that it has support for some feature that
other PDF programs on Linux do not.

One thing that annoys me is that the (major) version number of the
software is part of the binary's name: masterpdfeditor4. So if we did
include it, then when version 5 is released, we would need to add a new
entry (or have a policy of only supporting the latest).

In conclusion, I have no strong opinion. I just wanted to say that "I
have heard of the program and find it to be a respectable program,
compared to any other proprietary program I've used".

So when making a decision I would summarize it as "should we add a PDF
editor that probably not many LyX users are using as a PDF viewer?" I
really don't have a good feeling for the cost of checking for another
viewer so I don't know how to answer that question myself. I must admit
though that I did (after checking on the list) add a relatively unknown
PDF reader to configure: mupdf.

Scott


signature.asc
Description: PGP signature

Re: [patch] update PDF viewers in configure.py

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 01:22:48AM +0200, Uwe Stöhr wrote:
> El 31.07.2017 a las 01:00, Paul A. Rubin escribió:
> 
> > IIRC, the script cycles through the options and stops at the first
> > match. (This is true on all operating systems, not just Linux.) If, for
> > example, Evince precedes Xreader and the user has both installed, the
> > default will become Evince, even though Xreader is the, um, default
> > default (the one set by the system when Mint is installed).
> 
> Thanks for the explanation. So as long as the the LyX configure.py script
> cannot determine what the current default PDF viewer is on a system cases
> like yours cannot be avoided.
> 
> But maybe there is a way to determine this? Maybe our pyhtonists have an
> idea?

Search for discussions on xdg-open. There have been some discussions in
the past about it.

Scott


signature.asc
Description: PGP signature

Re: [patch] update PDF viewers in configure.py

[Scott Kostyshak]

On Sun, Jul 30, 2017 at 07:00:44PM -0400, Paul A. Rubin wrote:

> I could make an argument for putting choices not normally
> installed ahead of the ones packaged with the operating system (call that
> one the system default), on the theory that if the user installed something
> other than the system default it might indicate a preference for the
> user-installed application. I'm not sure I'd bet money on it, though.

Thinking in the same way as you reference, I think this is why I put
Okular ahead of Evince. I'm still conflicted about it though (as I sense
you are).

> There's one certainty, regardless of the OS: no matter which order you
> specify, /someone/ is going to complain. ;-)

+1

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Cmake build: Ignore boost settings if we are using std-regex

[Scott Kostyshak]

On Sun, Jul 30, 2017 at 07:41:02AM +0200, Kornel Benko wrote:
> Am Samstag, 29. Juli 2017 um 19:14:01, schrieb Scott Kostyshak 
> 
> > On Thu, Jul 27, 2017 at 11:32:06PM +0200, Kornel Benko wrote:
> > > commit 2fe59adbc89f56e7e192b57c90eb5e2a8338721c
> > > Author: Kornel Benko 
> > > Date:   Thu Jul 27 23:29:29 2017 +0200
> > > 
> > > Cmake build: Ignore boost settings if we are using std-regex
> > > 
> > > External/included boost is only used for the component regex
> > 
> > With this commit, I get the following message:
> > 
> > Unable to determine the system directory having searched
> > /home/scott/lyxbuilds/master/CMakeBuild/share/lyx/
> > Use the '-sysdir' command line parameter or set the environment variable
> > LYX_DIR_23x to the LyX system directory containing the file 
> > `chkconfig.ltx'.
> > 
> > Scott
> 
> Totally unexpected. What should boost have to do with system dir?
> Could you please test with clean build?

I tested with clean builds of 2fe59adb and 2fe59adb^, and see the same
difference.

The only difference in the output of the cmake commands is

"Using std regex"

The difference in the CMakeCache.txt files is:

$ diff CMakeCache_before.txt CMakeCache_after.txt 
639,644d638
<

boost_BINARY_DIR:STATIC=/home/scott/lyxbuilds/master/CMakeBuild/3rdparty/boost/libs
< 
< //Value Computed by CMake
<

boost_SOURCE_DIR:STATIC=/home/scott/lyxbuilds/master/repo/3rdparty/boost/libs
< 
< //Value Computed by CMake
871c865
< CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=26
---
> CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=24
$ 

Are those changes expected?

With 2fe59adb, compilcation succeeds and I get the same error under the
following three cases:
1. I omit -DLYX_EXTERNAL_BOOST
2. I set it to -DLYX_EXTERNAL_BOOST=ON
3. I set it to -DLYX_EXTERNAL_BOOST=OFF

With 2fe59adb^, if I set it to -DLYX_EXTERNAL_BOOST=ON, the CMake call
gives me:

-- Searching for boost
CMake Error at CMakeLists.txt:814 (message):
  Boost not found

Are those clues useful at all? If not, don't spend time on it. I will
take a deeper look when I have time.

Scott


signature.asc
Description: PGP signature

Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #335

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/335/

Re: [patch] update PDF viewers in configure.py

[Kornel Benko]

Am Montag, 31. Juli 2017 um 00:18:59, schrieb Uwe Stöhr 
> El 30.07.2017 a las 23:47, Jean-Marc Lasgouttes escribió:
> 
> >> would therefore like to support it in LyX.
> > 
> > To be frank I never heard of it before today. It seems to be some 
> > commercial program which only can be found as demo. I am not very fond of 
> > promoting such things.
> 
> It is not a demo. Only if you want to have all features like e.g. 
> splitting PDF pages one has to buy another version. So it is the same as 
> with Acrobat Reader, for the full feature set of Acrobat one has to pay.

Do we really try to promote commercial programs?

> There are packages for Master PDF in the Debian/Ubuntu and Arch package 
> system available maybe for other package systems too.
> 
> In general I don't think we should judge programs according to their 
> business model. LyX does not force to use a program he might not like. 
> If a user likes a closed source program like Acrobat Reader it is very 
> helpful that LyX checks for it.
> 
> regards Uwe

Kornel

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

Re: Options for resolving the minted + shell-escape issue

[Kornel Benko]

Am Sonntag, 30. Juli 2017 um 23:15:53, schrieb Enrico Forestieri 

> On Sun, Jul 30, 2017 at 02:27:02PM +0200, Kornel Benko wrote:
> > 
> > Testing the patch shell-escape-auth-5.diff, there is 1 issue from my side:
> > The session entry is totally ignored if using 'lyx -E', therefore I'd prefer
> > to save the entries in some other file (for instance "session.shellEscape"),
> > which could be loaded unconditionally.
> 
> I am wondering whether it is better this way, security wise.

Well, it is easier to use this for tests. The way I test now is to add 
-shell-escape to _all_ latex converter.

> When you
> export from command line you don't get any clue that latex is allowed
> to run external programs.

For this we have to know which lyx file will need it.
Doable, but would also need extra info somewhere else.

> Perhaps a further line command option could
> be introduced, say --shell-escape, that in this case would be an explicit
> consent. This option would be effective only for batch jobs and ignored
> in normal operation.
> 

Not in my reach ATM. I try to make the tests for existing lyx.

Kornel

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

Re: [patch] update PDF viewers in configure.py

[Uwe Stöhr]

El 31.07.2017 a las 01:00, Paul A. Rubin escribió:

IIRC, the script cycles through the options and stops at the first 
match. (This is true on all operating systems, not just Linux.) If, for 
example, Evince precedes Xreader and the user has both installed, the 
default will become Evince, even though Xreader is the, um, default 
default (the one set by the system when Mint is installed).


Thanks for the explanation. So as long as the the LyX configure.py 
script cannot determine what the current default PDF viewer is on a 
system cases like yours cannot be avoided.


But maybe there is a way to determine this? Maybe our pyhtonists have an 
idea?


There's one certainty, regardless of the OS: no matter which order you 
specify, /someone/ is going to complain. ;-)


Yes. So to avoid a discussion about it I have undone the sort order 
change in the attached updated patch.


regards Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-accb484.000.py"
 "b/D:\\LyXGit\\Master\\lib\\configure.py"
index 8e7fedbb5a..bd75f05c53 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-accb484.000.py"
+++ "b/D:\\LyXGit\\Master\\lib\\configure.py"
@@ -675,9 +675,7 @@ def checkFormatEntries(dtl_tools):
 #checkProg('a Postscript interpreter', ['gs'],
 #  rc_entry = [ r'\ps_command "%%"' ])
 checkViewer('a Postscript previewer',
-['kghostview', 'okular', 'qpdfview --unique',
- 'evince', 'xreader',
- 'gv', 'ghostview -swap', 'gsview64', 'gsview32'],
+['okular', 'qpdfview --unique', 'evince', 'xreader', 'gv', 
'gsview64', 'gsview32'],
 rc_entry = [r'''\Format epseps EPS"" 
"%%"  ""  "vector""image/x-eps"
 \Format eps2   eps"EPS (uncropped)"   "" "%%"  ""  
"vector"""
 \Format eps3   eps"EPS (cropped)" "" "%%"  ""  
"document"  ""
@@ -686,10 +684,8 @@ def checkFormatEntries(dtl_tools):
 # maybe use "bestApplication()" from 
https://github.com/jleclanche/python-mime
 # the MIME type is set for pdf6, because that one needs to be 
autodetectable by libmime
 checkViewer('a PDF previewer',
-['pdfview', 'kpdf', 'okular', 'qpdfview --unique',
- 'evince', 'xreader', 'kghostview', 'xpdf', 'SumatraPDF',
- 'acrobat', 'acroread', 'mupdf',
- 'gv', 'ghostview', 'AcroRd32', 'gsview64', 'gsview32'],
+['pdfview', 'okular', 'qpdfview --unique', 'evince', 
'xreader', 'xpdf', 'SumatraPDF', 'acrobat', 'acroread',
+ 'masterpdfeditor4', 'mupdf', 'gv', 'AcroRd32', 'gsview64', 
'gsview32'],
 rc_entry = [r'''\Format pdfpdf"PDF (ps2pdf)"  P  
"%%"  ""  "document,vector,menu=export"   ""
 \Format pdf2   pdf"PDF (pdflatex)"F  "%%"  ""  
"document,vector,menu=export"   ""
 \Format pdf3   pdf"PDF (dvipdfm)" m  "%%"  ""  
"document,vector,menu=export"   ""

Re: [patch] update PDF viewers in configure.py

[Paul A. Rubin]

On 07/30/2017 06:26 PM, Uwe Stöhr wrote:


Okular -> qpdfview -> Evince
means 2 Qt programs before the first GTK program. I noticed that on 
popular distros (Mint, Ubuntu, Fedora) Evince is the default viewer.
Still true for Fedora and Ubuntu (I think); on Mint, the default viewer 
is now Xreader.

I don#t know enough about Linux if the order is really necessary or not.
IIRC, the script cycles through the options and stops at the first 
match. (This is true on all operating systems, not just Linux.) If, for 
example, Evince precedes Xreader and the user has both installed, the 
default will become Evince, even though Xreader is the, um, default 
default (the one set by the system when Mint is installed).


The user can change it, so it's a matter of inconvenience rather than a 
crucial problem. I could make an argument for putting choices not 
normally installed ahead of the ones packaged with the operating system 
(call that one the system default), on the theory that if the user 
installed something other than the system default it might indicate a 
preference for the user-installed application. I'm not sure I'd bet 
money on it, though.


There's one certainty, regardless of the OS: no matter which order you 
specify, /someone/ is going to complain. ;-)


Paul

Re: Options for resolving the minted + shell-escape issue

[Richard Heck]

The latest version of Enrico's patches look good to me.

R


On 07/29/2017 05:57 PM, Scott Kostyshak wrote:
> On Thu, Jul 20, 2017 at 03:30:14PM -0400, Richard Heck wrote:
>> On 07/20/2017 01:21 AM, Jürgen Spitzmüller wrote:
>>> Am Mittwoch, den 19.07.2017, 16:37 +0200 schrieb Enrico Forestieri:
 The attached patch takes into account all of these ideas. As a
 disclaimer,
 note that I am providing it only because I am now familiar with this
 part
 of the code and can quickly come up with a patch. But I am not
 endorsing it.
>>> I propose to apply this patch and return to productivity.
>> I would agree with that.
> I'm concerned that since this issue has left us all exhausted, there is
> a feeling of "let's just get this over so we can move on". I encourage
> all of us to give one more cognitive spurt and give a vote.
>
> From what I understand, the three options are still what I proposed
> three weeks ago [1]:
>
> 1. Revert the recently added minted support.
>
> 2. Keep the current state of master.
>
> 3. Apply the patch at [2]. Don't forget to copy emblem-shellescape.svgz
> to lib/images. (Note that I get linker errors when I try to apply the
> latest patch, but it might be something specific to my setup.)
>
> So I ask explicitly to everyone (even if you think you have already
> voted, please give your vote again): who has given the latest patch a
> good test, has looked at the code (the patch is not so long), and votes
> in favor of one of the three options?
>
> Please also feel free to say that you have tested the patch but choose
> to abstain from voting. This way I will know that even if the vote is
> only 2 to 1, at least the rest of the developers are indifferent, rather
> than not having tested. But I ask that everyone tests the patch and says
> something. If you are lost because you had the fortune of not following
> the debate, let us know so we can tell you what to test, and can point
> you to some advantages/disadvantages of each option.
>
> Scott
>
>
> [1]
> https://www.mail-archive.com/search?l=mid=20170705045915.h4uyrsc27g54da3m%40steph
> [2]
> https://www.mail-archive.com/search?l=mid=20170728213142.GA7880%40GIOVE

Re: [patch] update PDF viewers in configure.py

[Uwe Stöhr]

El 30.07.2017 a las 22:10, Stephan Witt escribió:


You didn’t mention the change to remove xreader. Did you remove it accidentally?


Oops, sorry. Attached is the correct patch where this is not removed.


Why did you change the order of tested programs?


Okular -> qpdfview -> Evince
means 2 Qt programs before the first GTK program. I noticed that on 
popular distros (Mint, Ubuntu, Fedora) Evince is the default viewer.

I don#t know enough about Linux if the order is really necessary or not.

regards Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-97e1ce6.001.py"
 "b/D:\\LyXGit\\Master\\lib\\configure.py"
index 8e7fedbb5a..3239e6e997 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-97e1ce6.001.py"
+++ "b/D:\\LyXGit\\Master\\lib\\configure.py"
@@ -675,9 +675,7 @@ def checkFormatEntries(dtl_tools):
 #checkProg('a Postscript interpreter', ['gs'],
 #  rc_entry = [ r'\ps_command "%%"' ])
 checkViewer('a Postscript previewer',
-['kghostview', 'okular', 'qpdfview --unique',
- 'evince', 'xreader',
- 'gv', 'ghostview -swap', 'gsview64', 'gsview32'],
+['okular', 'evince', 'qpdfview --unique', 'xreader', 'gv', 
'gsview64', 'gsview32'],
 rc_entry = [r'''\Format epseps EPS"" 
"%%"  ""  "vector""image/x-eps"
 \Format eps2   eps"EPS (uncropped)"   "" "%%"  ""  
"vector"""
 \Format eps3   eps"EPS (cropped)" "" "%%"  ""  
"document"  ""
@@ -686,10 +684,8 @@ def checkFormatEntries(dtl_tools):
 # maybe use "bestApplication()" from 
https://github.com/jleclanche/python-mime
 # the MIME type is set for pdf6, because that one needs to be 
autodetectable by libmime
 checkViewer('a PDF previewer',
-['pdfview', 'kpdf', 'okular', 'qpdfview --unique',
- 'evince', 'xreader', 'kghostview', 'xpdf', 'SumatraPDF',
- 'acrobat', 'acroread', 'mupdf',
- 'gv', 'ghostview', 'AcroRd32', 'gsview64', 'gsview32'],
+['pdfview', 'okular', 'evince', 'qpdfview --unique', 
'xreader', 'xpdf', 'SumatraPDF', 'acrobat', 'acroread',
+ 'masterpdfeditor4', 'mupdf', 'gv', 'AcroRd32', 'gsview64', 
'gsview32'],
 rc_entry = [r'''\Format pdfpdf"PDF (ps2pdf)"  P  
"%%"  ""  "document,vector,menu=export"   ""
 \Format pdf2   pdf"PDF (pdflatex)"F  "%%"  ""  
"document,vector,menu=export"   ""
 \Format pdf3   pdf"PDF (dvipdfm)" m  "%%"  ""  
"document,vector,menu=export"   ""

Re: [patch] update PDF viewers in configure.py

[Uwe Stöhr]

El 30.07.2017 a las 23:47, Jean-Marc Lasgouttes escribió:


would therefore like to support it in LyX.


To be frank I never heard of it before today. It seems to be some commercial 
program which only can be found as demo. I am not very fond of promoting such 
things.


It is not a demo. Only if you want to have all features like e.g. 
splitting PDF pages one has to buy another version. So it is the same as 
with Acrobat Reader, for the full feature set of Acrobat one has to pay.


There are packages for Master PDF in the Debian/Ubuntu and Arch package 
system available maybe for other package systems too.


In general I don't think we should judge programs according to their 
business model. LyX does not force to use a program he might not like. 
If a user likes a closed source program like Acrobat Reader it is very 
helpful that LyX checks for it.


regards Uwe

Re: [patch] update PDF viewers in configure.py

[Jean-Marc Lasgouttes]

Le 30 juillet 2017 21:51:15 GMT+02:00, "Uwe Stöhr"  a écrit :
>I reviewed the PDF viewers LyX is searching for. It turned out that the
>
>last stable version of KGhostView and KPDF were released 9 years ago,
>so 
>I think we could remove their support.

Yes, that make sense, or at least put them as low as possible in the list.

>Under Linux I was looking for a PDF program with which I can properly 
>fill out and submit PDF forms. I found the Program Master PDF editor
>and 
>would therefore like to support it in LyX.

To be frank I never heard of it before today. It seems to be some commercial 
program which only can be found as demo. I am not very fond of promoting such 
things.

JMarc

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Sun, Jul 30, 2017 at 02:27:02PM +0200, Kornel Benko wrote:
> 
> Testing the patch shell-escape-auth-5.diff, there is 1 issue from my side:
> The session entry is totally ignored if using 'lyx -E', therefore I'd prefer
> to save the entries in some other file (for instance "session.shellEscape"),
> which could be loaded unconditionally.

I am wondering whether it is better this way, security wise. When you
export from command line you don't get any clue that latex is allowed
to run external programs. Perhaps a further line command option could
be introduced, say --shell-escape, that in this case would be an explicit
consent. This option would be effective only for batch jobs and ignored
in normal operation.

-- 
Enrico

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Sat, Jul 29, 2017 at 07:51:08PM -0400, Scott Kostyshak wrote:
> 
> If I remove the python-pygments module (and reconfigure) and test, I get
> the following error:
> 
> The driver command necessary to use the minted package
> (pygmentize) has not been found. Make sure you have
> the python-pygments module installed or, if the driver
> is named differently, to add the following line to the
> document preamble:
> 
> \AtBeginDocument{\renewcommand{\MintedPygmentize}{driver}}
> 
> where 'driver' is name of the driver command.
> 
> I expected to get the error, but what I was surprised by is that I get
> the error when going to Document > Settings. I expected to get an error
> immediately after compiling (before the LaTeX log errors). Is that
> expected? Note that I am using a compiled Qt 5.9.2dev so if you can't
> reproduce, it is probably a bug on my side.

No, it is not related to the Qt version. I was aware of it but further
improvements were delayed by the exhausting discussion that followed.
I am contemplating the possibility of simply not allowing minted if the
driver program is not called pygmentize, so that in this case the combo
box is simply disabled without any warning.

-- 
Enrico

Re: [LyX/master] UserGuide.lyx: accept and distribute description of inverted branches

[Jean-Pierre Chrétien]

Le 30/07/2017 à 22:20, Uwe Stöhr a écrit :

commit 5513e465893ae255f75aaecc304133ba01a89e08
Author: Uwe Stöhr 
Date:   Sun Jul 30 22:20:03 2017 +0200

UserGuide.lyx: accept and distribute description of inverted branches
---
 lib/doc/Changelog-UserGuide-LyX_23x.txt |1 +


I see that you collect changes in the Changelog files.
I had created a docUpdatesFor23.txt file.
The difference, if I understand correctly, is that the Changelog files record 
only the changes remaining after you have exported in the de|es|fr|ja files, 
while the docUpdatesFor23.txt file records what is new in the 2.3 documentation.


On my side, I have added to docUpdatesFor23.txt the corrections made by jürgen 
while translation Additional.lyx in German. So German Additional.lyx is already 
up to date. I have just finished to copy the changes in Additional to the 
Spanish version, so french and Japanese remain to be copied.


The drawback (an maybe unneccesary task) in docUpdatesFor23.txt is that I 
recorded all changes, even font changes, quote editions or sentences or 
paragraphs suppression which do not appear anymore in the localized file once 
copied. So I guess that for Additional, I will create a 
Changelog-Additional-LyX_23x.txt retaining only what is to be done once I've 
done the copy to es|fr[ja.


--
Jean-Pierre

Jenkins build is back to normal : Build branch "master" » ubuntu-latest-qt5-cmake #318

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/318/

Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #334

[ci-lyx]

https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/334/--
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Building remotely on lyx-linux1 (linux) in workspace 

[WS-CLEANUP] Deleting project workspace...
Cloning the remote Git repository
Using shallow clone
Avoid fetching tags
Honoring refspec on initial clone
Cloning repository git://git.lyx.org/lyx.git
 > git init 
 > 
 >  # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git --version # timeout=10
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git fetch --no-tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/* --depth=1
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/refs/heads/master^{commit} # timeout=10
Checking out Revision 040527f628fe6c56c871e9f6f8a84807331975fc 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 040527f628fe6c56c871e9f6f8a84807331975fc
 > git rev-list 57d3247d518607d8f77576f9cbb487befb590821 # timeout=10
First time build. Skipping changelog.
[ubuntu-xenial-qt4-autotools-extended] $ /bin/sh -xe 
/tmp/hudson2952322850398326822.sh
+ IMAGE=lyxproject/build-lyx-using-ubuntu-xenial-qt4-autotools
+ C_BUILD=/build
+ C_WS=/build/workspace
+ C_SCRIPT=/build/build_lyx_extended.sh
+ docker run --rm -v 
:/build/workspace
 lyxproject/build-lyx-using-ubuntu-xenial-qt4-autotools 
/build/build_lyx_extended.sh /build/workspace
/tmp/hudson2952322850398326822.sh: 13: /tmp/hudson2952322850398326822.sh: 
docker: not found
Build step 'Execute shell' marked build as failure

Re: [patch] update PDF viewers in configure.py

[Stephan Witt]

Am 30.07.2017 um 21:51 schrieb Uwe Stöhr :
> 
> I reviewed the PDF viewers LyX is searching for. It turned out that the last 
> stable version of KGhostView and KPDF were released 9 years ago, so I think 
> we could remove their support.
> 
> Under Linux I was looking for a PDF program with which I can properly fill 
> out and submit PDF forms. I found the Program Master PDF editor and would 
> therefore like to support it in LyX.
> 
> I also found out that "ghostview" is deprecated since years and gv, gsview64 
> and gsview32 are the replacements (which we already support).
> 
> So the attached patch removes to check for ghostview, KPDF and KGhostView and 
> adds to check for masterpdfeditor.
> 
> Could this go in or are there any reasons against this?

You didn’t mention the change to remove xreader. Did you remove it 
accidentally? 
Why did you change the order of tested programs?

Stephan

> 
> thanks and regards
> Uwe
> 

[patch] update PDF viewers in configure.py

[Uwe Stöhr]

I reviewed the PDF viewers LyX is searching for. It turned out that the 
last stable version of KGhostView and KPDF were released 9 years ago, so 
I think we could remove their support.


Under Linux I was looking for a PDF program with which I can properly 
fill out and submit PDF forms. I found the Program Master PDF editor and 
would therefore like to support it in LyX.


I also found out that "ghostview" is deprecated since years and gv, 
gsview64 and gsview32 are the replacements (which we already support).


So the attached patch removes to check for ghostview, KPDF and 
KGhostView and adds to check for masterpdfeditor.


Could this go in or are there any reasons against this?

thanks and regards
Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-189ed7d.000.py"
 "b/D:\\LyXGit\\Master\\lib\\configure.py"
index 8e7fedbb5a..f03d2e08f4 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-189ed7d.000.py"
+++ "b/D:\\LyXGit\\Master\\lib\\configure.py"
@@ -675,9 +675,7 @@ def checkFormatEntries(dtl_tools):
 #checkProg('a Postscript interpreter', ['gs'],
 #  rc_entry = [ r'\ps_command "%%"' ])
 checkViewer('a Postscript previewer',
-['kghostview', 'okular', 'qpdfview --unique',
- 'evince', 'xreader',
- 'gv', 'ghostview -swap', 'gsview64', 'gsview32'],
+['okular', 'evince', 'qpdfview --unique', 'gv', 'gsview64', 
'gsview32'],
 rc_entry = [r'''\Format epseps EPS"" 
"%%"  ""  "vector""image/x-eps"
 \Format eps2   eps"EPS (uncropped)"   "" "%%"  ""  
"vector"""
 \Format eps3   eps"EPS (cropped)" "" "%%"  ""  
"document"  ""
@@ -686,10 +684,8 @@ def checkFormatEntries(dtl_tools):
 # maybe use "bestApplication()" from 
https://github.com/jleclanche/python-mime
 # the MIME type is set for pdf6, because that one needs to be 
autodetectable by libmime
 checkViewer('a PDF previewer',
-['pdfview', 'kpdf', 'okular', 'qpdfview --unique',
- 'evince', 'xreader', 'kghostview', 'xpdf', 'SumatraPDF',
- 'acrobat', 'acroread', 'mupdf',
- 'gv', 'ghostview', 'AcroRd32', 'gsview64', 'gsview32'],
+['pdfview', 'okular', 'evince', 'qpdfview --unique', 'xpdf', 
'SumatraPDF', 'acrobat', 'acroread',
+ 'masterpdfeditor4', 'mupdf', 'gv', 'AcroRd32', 'gsview64', 
'gsview32'],
 rc_entry = [r'''\Format pdfpdf"PDF (ps2pdf)"  P  
"%%"  ""  "document,vector,menu=export"   ""
 \Format pdf2   pdf"PDF (pdflatex)"F  "%%"  ""  
"document,vector,menu=export"   ""
 \Format pdf3   pdf"PDF (dvipdfm)" m  "%%"  ""  
"document,vector,menu=export"   ""

Re: alpha beta lyx-formats and devel versions of the docs

[Uwe Stöhr]

El 26.07.2017 a las 21:41, Richard Heck escribió:


Mike makes a good point. He wants to help with testing and improving the
documentation but cannot because of the file format. What is our policy
on updating the file format? I believe we only do that when we have to
update the format because we are using a new feature. Is that right?


Yes, as best we can. But in practice, the people updating the docs are
using the latest version, and the version number gets updated. (I think
this is why it's often suggested that updates be made in stable first,
not in master.)


Yes, that is why I write so often to put all changes to the 
documentation that don't require a fileformat change to the stable 
branch. This way everybody can have a look and review it.


I try to look at these changes soon and distribute the changes to the 
different language files and port the changes to master. In the past I 
got this way feedback from our translators so that I could correct it 
for the next stable release. if it would have been only in master the 
stable branch and thus the majority of users would not benefit from doc 
corrections/updates.


My personal policy is to stop working on the stable branch docs with the 
release of the first beta of a new version. This is just to save 
manpower. We have not released a beta yet, but I already started the doc 
updating for 2.3. So unless there is a compilation failure I would not 
backport info to the 2.2 branch anymore.


regards Uwe

Re: allowing anonymous contributions to LyX's source code?

[Christian Ridderström]

On 28 June 2017 at 04:10, Joel Kulesza  wrote:

> On Tue, Jun 27, 2017 at 7:24 PM, Richard Heck  wrote:
>
>>
>> It's come up more than once, so I think it's worth writing down what
>> we've decided. Obviously, we can revisit the issue any time we like. But
>> we won't have to re-discuss it every time.
>
>
> This is why I'd like to see the approach written down as well.
>

I also thinks it makes sense to write it down as a _guideline_.

We could use a wiki page as an alternative/complement to Development.lyx.
It'd make it more open "to the world" how we deal with "unnamed
contributors" [*] that don't wish their real name published in CREDITS.
/Christian

[*] I recently read a blog or something about unnamed sources versus
anonymous sources,
which made me think it's clearer for us to refer to "venom00" as an unnamed
contributor
rather than an anonymous contributor.

Re: Obsoleted, inaccessible or wrong urls in some documents

[Kornel Benko]

Am Samstag, 29. Juli 2017 um 13:13:28, schrieb mn 
> On 29.07.17 12:20, Kornel Benko wrote:
> > Hi,
> > the url 
> > "ftp://ftp.dante.de/tex-archive/info/math/voss/mathmode/Mathmode.pdf;
> > is no longer accessible. The new one is available under
> > "https://www.tug.org/~hvoss/PDF/mathmode.pdf;
> > Affected documents are "lib/doc/(.|de|es|fr|ja)/Math.lyx"
> > 
> > Other inaccessible urls (maybe temporary)
> > http://download.gna.org/lettre_observatoire/release/20151201_v2.354/lettre.zip
> > in lib/templates/lettre.lyx
> > 
> > Urls not found:
> > http://publish.aps.org/revtex4/
> > in lib/doc/(.|de|es|fr|ja)/Additional.lyx
> >lib/doc/(.|ja)/LaTeXConfig.lyx
> > http://www.aeaweb.org/aer/authref.php
> > in lib/doc/(.|ja)/LaTeXConfig.lyx
> > http://www.cs.haifa.ac.il/~dekelts/lyx/
> > in lib/doc/he/Tutorial.lyx
> > http://www.cs.virginia.edu/~nr/noweb
> > in lib/doc/de/Additional.lyx
> > http://www.cs.virginia.edu/~nr/noweb/
> > in lib/doc/(.|es|fr|ja)/Additional.lyx   
> > http://www.eecs.harvard.edu/~nr/noweb
> > in lib/examples/listerrors.lyx
> > http://www.physik.uni-augsburg.de/theo3/Comp/hp750c/computing_hp750c_A0.de.shtml
> > in lib/templates/poster-a0poster-simple.lyx
> > http://www.stat.uni-muenchen.de/~leisch/Sweave/
> > in lib/examples/(.|ja)/sweave.lyx
> > http://www.tug.org/applications/hyperref/ftp/doc/manual.pdf
> > in lib/doc/(.|de|es|fr|ja)/Math.lyx
> > 
> > Urls blocked because of security
> > http://www.edpsciences.fr/aa/
> > in lib/doc/(.|de|es|fr|ja)/Additional.lyx
> > 
> > What should be done here?
> 
> 
> 
> # Check if they are still relevant.
> 
> http://www.cs.haifa.ac.il/~dekelts/lyx/
> Seems outdated according to
> https://web.archive.org/web/20150919234057/http://cs.haifa.ac.il/~dekelts/lyx/instructions2.html
> 
> > http://www.aeaweb.org/aer/authref.php
> seems also irrelevant now, according to:
> https://web.archive.org/web/20130518073654/http://www.aeaweb.org/aer/authref.php
> 
> 
> # Update the links if they have just moved.
> 
> > http://publish.aps.org/revtex4/
> Is probably now:
> https://journals.aps.org/revtex
> 
> > http://www.tug.org/applications/hyperref/ftp/doc/manual.pdf
> https://www.tug.org/applications/hyperref/manual.html
> http://mirrors.ctan.org/macros/latex/contrib/hyperref/doc/manual.pdf
> 
> 
> 
> Relevance has to be judged by someone with more expertise.

Yes, thanks for the input.

> greetings
> Mike

Kornel 

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

Re: Options for resolving the minted + shell-escape issue

[Kornel Benko]

Am Freitag, 28. Juli 2017 um 23:31:42, schrieb Enrico Forestieri 

> On Tue, Jul 25, 2017 at 09:16:15PM +0200, Enrico Forestieri wrote:
> 
> > I am also investigating the possibility of attaching a context menu to
> > the red icon in the status bar.
> 
> This is now done in the attached patch. Hovering with the mouse over the
> red icon a warning is shown, and right clicking shows a popup menu that
> allows to disable the shell escape option for the current document.
> 

Testing the patch shell-escape-auth-5.diff, there is 1 issue from my side:
The session entry is totally ignored if using 'lyx -E', therefore I'd prefer
to save the entries in some other file (for instance "session.shellEscape"),
which could be loaded unconditionally.

Kornel

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

Re: Options for resolving the minted + shell-escape issue

[Jürgen Spitzmüller]

Am 30.07.2017 11:54 vorm. schrieb "Jean-Marc Lasgouttes" :

FWIW, I am on vacation without a computer right now. I did not test
Enrico's patch, but I agree that this is the right direction. So applying
it cannot hurt, and will allow us to move forward, not only wrt next
release, but also on this issue.


Same here (vacation, no computer and +1 Enrico's patch.

Jürgen



JMarc

Le 29 juillet 2017 23:57:52 GMT+02:00, Scott Kostyshak  a
écrit :
>I'm concerned that since this issue has left us all exhausted, there is
>a feeling of "let's just get this over so we can move on". I encourage
>all of us to give one more cognitive spurt and give a vote.

Re: Options for resolving the minted + shell-escape issue

[Jean-Marc Lasgouttes]

FWIW, I am on vacation without a computer right now. I did not test Enrico's 
patch, but I agree that this is the right direction. So applying it cannot 
hurt, and will allow us to move forward, not only wrt next release, but also on 
this issue. 

JMarc

Le 29 juillet 2017 23:57:52 GMT+02:00, Scott Kostyshak  a 
écrit :
>I'm concerned that since this issue has left us all exhausted, there is
>a feeling of "let's just get this over so we can move on". I encourage
>all of us to give one more cognitive spurt and give a vote.

 

Re: alternatives for dashes (please vote)

[Guillaume MM]

Le 27/07/2017 à 23:27, Guenter Milde a écrit :

Dear LyX developers,

following Scotts suggestion, I prepared an overview of alternatives to
handle the problem with 2.2 breaking formatting of em- and en-dashes.
Comments and votes welcome.

Unfortunately, the topic is emotionally loaded, as we did a mistake and
there is no solution that everyone will agree with. OTOH, it is complex, but
not very important.

The Problem
===

Up to version 2.2, LyX used 2 representations for em- and en-dashes:

"literal" dashes:
literal Unicode or \textemdash rsp. \textendash macro,
"ligature" dashes:
"---" and "--" converted by the TeX font ligature mechanism.

"Ligature" and "literal" dashes can coexist in <2.2-documents,
e.g., when parts were copy-pasted from different sources.


LyX 2.2 uses only one representation and converts "ligature dashes" to
"literal dashes".

This turned out to break formatting in some documents, because

"literal" dashes suppress line breaks after the dash
   and allow hyphenation in adjacent words while
"ligature dashes" allow line breaks after the dash
   and suppress hyphenation in adjacent words.

There are use cases for both, dashes with and without optional line break
**switching the representation either way can lead to broken output**
(overfull lines or unwanted line breaks).

For details and examples see http://www.lyx.org/trac/ticket/10543#comment:3
and http://www.lyx.org/trac/attachment/ticket/10543/emdash-line-breaks.lyx


Alternatives for 2.3


a) convert ligature dashes to literal dash + allowbreak

+ keeps formatting in most cases
  - allows (possibly undesired) hyphenation in adjacent words
  - a redefinition of \text*dash would also affect former
"ligature" dashes.
+ simple
+ configurable/editable (special char can easily be deleted)
± verbose (the "allowbreak" special-char is displayed as a small blue mark)

b) convert ligature dashes to "special character" insets

+ no change to LaTeX output.
- requires "special character" inset for ordinary printable character
  - does not scale well
  + precedence cases: curly quotes, text ellipsis

c) keep 2.2 behaviour (convert ligature dashes to literal dashes)

+ simple
+ no change for 2.2 documents (the damage is already done)
- breaks formatting for <2.2 documents using ligature dashes

d) convert "ligature dashes" to ERT

+ no change to LaTeX output
+ simple
- ERT for formerly supported feature

e) re-define \textemdash

+ simple (except for LuaTeX)
+ already done by XeTeX
  
(http://tex.stackexchange.com/questions/62800/lualatex-and-line-breaks-after-em-dashes)
+ configurable
- hidden in the user preamble

f) keep the current 2.3alpha behaviour

+ configurable
- breaks formatting for <2.2 documents using literal dashes
  (these were not affected by the change in 2.2)
- new document setting for LaTeX export of Unicode characters:
  - does not scale well,
  - unprecedented
- Data loss (ZWSP following dashes are removed by lyx2lyx)
- different line breaks of the same document with LuaTeX and non-TeX fonts

g) revert to 2.1 behaviour

- regression on bugs  #3647 and #8561
- no WYSIWYM: "lyx --help" in the GUI becomes "lyx –help" in the output.


Alternatives b there are two pairs of dashes 

), c), d) and e) could also be applied to 2.2.x,

a) and f) require a fileformat change.



Open question:
   which representation to use with the -- and --- input conversion?

* The simplest way is to keep 2.2 behaviour (insert literal dashes).
   
* Maybe we can use a lyxfun with options that will be bound to the '-'-key?


* Sensible defaults would be
   allow linebreak after em-dash
   prevent linebreak after en-dash.
   
   Rationale:

 en-dash around an ellipsis is used with spaces, no line break
 allowed in ranges.


Günter





So for each dash there are two variants, one with a line break
opportunity and one without, and all have a use. Do I understand
correctly? Then, one should first decide how/whether to (ideally)
present the various combinations to the user in 2.3. The answer to the
question of converting 2.2 to 2.3 will follow from there. Do you agree
that the real question is what dashes one wants to propose to users in
2.3 and how?

About e): redefining \textemdash is not nice, instead one could define a
new \lyxemdash. What are the caveats?