Re: Gnuplot format & converter script

[Tommaso Cucinotta]

On 04/05/2017 01:36, Scott Kostyshak wrote:

Works well! I found what I think is unexpected behavior: if I select the
graphics inset (e.g. after I have followed your instructions and clicked
on "run" and everything looks good), and copy it, I am presented with
the authorization dialog.  [...] Can you reproduce?


yes, and it is unexpected that the converter question comes on the Copy
operation, not the Paste one!

In my stack trace I'm seeing

convert - Converter.cpp:462
prepareHTMLFile - InsetGraphics.cpp:940
...
writeLyXHTMLSource - Buffer.cpp:2239
putClipboard - CutAndPaste.cpp:574
copySelection - CutAndPaste.cpp:1042

interestingly, just above the copySelection() line, we can see:

// We do not need to produce images, etc.
runparams.dryrun = true;

as a consequence, I came up with the attached patch that solves the
annoyance for me, but I'm not expert of this area of the code, so
can please someone review?
(I just checked that I can still copy and paste the graphics as before)

Thanks,

T.

>From f3ec463a3a422dbdf98f61add03f68580ccda653 Mon Sep 17 00:00:00 2001
From: Tommaso Cucinotta 
Date: Thu, 4 May 2017 07:49:07 +0200
Subject: [PATCH] skip graphics conversion when runparams.dryrun is try

... so we avoid the "run converter ?" confirmation dialog for needauth
converters simply when copying (Ctrl+C) an InsetGraphics inset.
---
 src/insets/InsetGraphics.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/insets/InsetGraphics.cpp b/src/insets/InsetGraphics.cpp
index 04ed735f..16a482f1 100644
--- a/src/insets/InsetGraphics.cpp
+++ b/src/insets/InsetGraphics.cpp
@@ -947,7 +947,9 @@ string InsetGraphics::prepareHTMLFile(OutputParams const & runparams) const
 
 docstring InsetGraphics::xhtml(XHTMLStream & xs, OutputParams const & op) const
 {
-	string const output_file = prepareHTMLFile(op);
+	string const output_file;
+	if (!op.dryrun)
+		prepareHTMLFile(op);
 
 	if (output_file.empty()) {
 		LYXERR0("InsetGraphics::xhtml: Unable to prepare file `" 
-- 
2.9.3

Re: Default to Qt 4 or Qt 5 with our build systems?

[Richard Heck]

On 05/01/2017 05:37 AM, José Abílio Matos wrote:
> On Monday, 1 May 2017 03.46.51 WEST Richard Heck wrote:
>> On 04/30/2017 07:23 PM, Scott Kostyshak wrote:
>>> Suppose that a system has both Qt 4 and Qt 5 development libraries
>>> installed. Should our automake and CMake build systems choose to use Qt
>>> 4 or Qt 5?
>>>
>>> Uwe made a good point that Qt 4 support is ending. See, for example, the
>>>
>>> following paragraph (from [1]):
>>>   Qt 4.8.7 is planned to be the last patch release of the Qt 4 series.
>>>   Standard support is available until December 2015, after which extended
>>>   support will be available. We recommend all active projects to migrate
>>>   to Qt 5, as new operating systems and compilers with Qt 4.8 will not be
>>>   supported. If you have challenges migrating to Qt 5, please contact us
>>>   or some of our service partners for assistance.
>>>
>>> The argument to still choose Qt 4 by default is that LyX 5.6 is the
>>> minimum recommended version for LyX.
>>>
>>> If we do want to switch to Qt 5 by default for 2.3.0, perhaps we should
>>> give a warning or error for Qt less than (e.g.) 5.5 (maybe we do
>>> already?).
>> What exactly does one need to do to compile with Qt5 as it is?
>>
>> Richard
> From lyx.spec from Fedora:
>
> %if %{use_qt5}
> BuildRequires: pkgconfig(Qt5Core)
> BuildRequires: pkgconfig(Qt5Widgets)
> BuildRequires: pkgconfig(Qt5Gui)
> BuildRequires: pkgconfig(Qt5Svg)
> BuildRequires: pkgconfig(Qt5X11Extras)
> %else
> BuildRequires: qt4-devel
> %endif
>
> and then when building:
>
> %configure ... --enable-qt5 ...

Thanks for the pointer. For the record, I needed:
qt5-qtbase-devel
qt5-qtsvg-devel
qt5-qtx11extras-devel

Richard

Re: further add-ons for 2.3.0 ? (was: Re: Gnuplot format & converter script)

[Scott Kostyshak]

On Thu, May 04, 2017 at 01:06:44AM +0200, Tommaso Cucinotta wrote:
> As we're on this, a few other things I had in my tommaso/master [1], out of 
> which:
> I'd really love to have 3)...

Is it polished? Is there a trac ticket for this one? Or an archived
discussion?

> about 2) I'm stuck with recurring to Emacs-editing the first line of a .lyx 
> file every time I face that issue :-)...

If I remember correctly, this is the idea that LyX might as well try to
open files from future LyX versions, if the author accepts the
consequences. Is that right? If so, I think I will be hesitant to accept
this one at this point. I think it will need discussion and will need to
consider several possible situations. But if you feel strongly about it,
continue the discussion on lyx-devel. Who knows---maybe I'm wrong and we
could arrive at a consensus soon enough to put it in before the freeze.

> just pushed 1), needs to be tried by someone

I tried it, just found a minor unexpected behavior that I reported in
the thread.

> guess 4) might be debatable already for a 3.0 :-).

Yes probably we should hold off on that one.

Scott


signature.asc
Description: PGP signature

Re: Gnuplot format & converter script

[Scott Kostyshak]

On Thu, May 04, 2017 at 12:54:47AM +0200, Tommaso Cucinotta wrote:
> On 03/05/2017 15:00, Scott Kostyshak wrote:
> > Tommaso, I'm still curious if you are planning to implement the gnuplot
> > patch for 2.3.0? Or perhaps you already did and I missed it?
> > 
> > The reason I ask is that time is running out to get features into 2.3.0
> > before we should focus completely on bug fixes.
> 
> I had it in my own tommaso/master branch, rebased up to last summer 
> (LinuxDay@Pisa).
> 
> I thought it was late, but as you're asking, I took the chance to rebase the 
> patch (trivial), check it's still working as expected, and push [1].
> 
> I wish someone else could try it out, in case you're short of gnuplot 
> scripts, you can use the attached sample. Just run LyX, and do 
> "Insert->Graphics...", then choose the .gp file, then enjoy the plot preview 
> on screen, as well as in the PDF formatted output.

Works well! I found what I think is unexpected behavior: if I select the
graphics inset (e.g. after I have followed your instructions and clicked
on "run" and everything looks good), and copy it, I am presented with
the authorization dialog. I assume this is because of a temporary buffer
that LyX creates for the copy or something like that? In any case, the
dialog was unexpected to me. Can you reproduce?

I don't use gnuplot so I'm glad that you gave the simple example.

I tested both gnuplot and knitr together (these both require "dangerous"
converters) and everything worked smoothly.

Scott


signature.asc
Description: PGP signature

Re: 2.3.0alpha1-1 round 2

[Scott Kostyshak]

On Thu, May 04, 2017 at 12:34:32AM +0200, Kornel Benko wrote:
> Am Donnerstag, 4. Mai 2017 um 00:04:44, schrieb Uwe Stöhr 
> > El 03.05.2017 a las 12:40, Scott Kostyshak escribió:
> > 
> > > Here are the tar balls for round 2 of 2.3.0alpha1-1:
> > 
> > I tried to check the signature but get this message:
> > 
> > Signed on 2017-05-03 12:27 with unknown certificate 0xDE7A44FAC7FB382D.
> > The signature is invalid: No public certificate to verify the signature
> > 
> > How do I know if the signature is correct or not?
> 
> You need probably to import the public key of 0xDE7A44FAC7FB382D
> 
> Searching in keyservers for this key I found
>   LyX Release Manager (Signing LyX tarballs and binaries) sa...@lyx.org
> found in hkp://keyserver.ubuntu.com/
> and also in hkp://keys.gnupg.net

Thanks for checking the signatures, Uwe. To be sure, I'll send the tars
and sigs to Kornel before uploading them to the FTP.

> > > If everything goes well and the binaries build, then I will push the tag
> > > and upload the binaries and make the release.
> > 
> > Everything worked now well. Here is the new installer:
> > 
> > http://ftp.lyx.de/LyXWinInstaller/LyX2.3alpha1/

Thanks, I got them. Please note that alpha1-1 is technically considered
a completely different release from alpha1. The announce file explains
the relationship between alpha1-1 and alpha1, and that explanation will
be included in the email that announces the release. But alpha1-1 is not
alpha1. I will change the file names (just adding a "-1"). If the file
names were automatically generated, you might need to fix something in
the script that was used.

Thanks for all of your time on this,

Scott


signature.asc
Description: PGP signature

further add-ons for 2.3.0 ? (was: Re: Gnuplot format & converter script)

[Tommaso Cucinotta]

As we're on this, a few other things I had in my tommaso/master [1], out of 
which:
I'd really love to have 3)...
about 2) I'm stuck with recurring to Emacs-editing the first line of a .lyx 
file every time I face that issue :-)...
just pushed 1), needs to be tried by someone
guess 4) might be debatable already for a 3.0 :-).

... if there's interest in any of these, it may not be impossible to rebase 
over the w.e. :-)

[1]

1) commit be98c5e1
Author: Tommaso Cucinotta 
Date:   Mon Oct 17 08:44:16 2016 +0200

Enable graphics generation from external gnuplot scripts.

2) commit cb7a69b1
Author: Tommaso Cucinotta 
Date:   Wed Oct 19 11:18:10 2016 +0200

Tolerate formats that are not supported by lyx2lyx.

3) commit bf3cda7b
Author: Tommaso Cucinotta 
Date:   Sat Oct 15 01:14:02 2016 +0200

Create new graphics from within LyX choosing a sample file to copy from.

4) commit 410ce81e
Author: Tommaso Cucinotta 
Date:   Wed Oct 16 22:55:40 2013 +0100

LyX XMPP Chat

This patch enables XMPP-based chatting within LyX.

With contributions from Kornel Benko 


Thanks,

T.

On 04/05/2017 00:54, Tommaso Cucinotta wrote:

On 03/05/2017 15:00, Scott Kostyshak wrote:

Tommaso, I'm still curious if you are planning to implement the gnuplot
patch for 2.3.0? Or perhaps you already did and I missed it?

The reason I ask is that time is running out to get features into 2.3.0
before we should focus completely on bug fixes.


I had it in my own tommaso/master branch, rebased up to last summer 
(LinuxDay@Pisa).

I thought it was late, but as you're asking, I took the chance to rebase the 
patch (trivial), check it's still working as expected, and push [1].

I wish someone else could try it out, in case you're short of gnuplot scripts, you can use 
the attached sample. Just run LyX, and do "Insert->Graphics...", then choose 
the .gp file, then enjoy the plot preview on screen, as well as in the PDF formatted output.

Thx,

T.

[1]

commit b474aa5d
Author: Tommaso Cucinotta 
Date:   Thu May 4 00:49:18 2017 +0200

Add needauth option to gnuplot->PDF converter introduced in 
[066edd3c/lyxgit].

commit 066edd3c
Author: Tommaso Cucinotta 
Date:   Mon Oct 17 08:44:16 2016 +0200

Enable graphics generation from external gnuplot scripts.

Re: Gnuplot format & converter script

[Tommaso Cucinotta]

On 03/05/2017 15:00, Scott Kostyshak wrote:

Tommaso, I'm still curious if you are planning to implement the gnuplot
patch for 2.3.0? Or perhaps you already did and I missed it?

The reason I ask is that time is running out to get features into 2.3.0
before we should focus completely on bug fixes.


I had it in my own tommaso/master branch, rebased up to last summer 
(LinuxDay@Pisa).

I thought it was late, but as you're asking, I took the chance to rebase the 
patch (trivial), check it's still working as expected, and push [1].

I wish someone else could try it out, in case you're short of gnuplot scripts, you can use 
the attached sample. Just run LyX, and do "Insert->Graphics...", then choose 
the .gp file, then enjoy the plot preview on screen, as well as in the PDF formatted output.

Thx,

T.

[1]

commit b474aa5d
Author: Tommaso Cucinotta 
Date:   Thu May 4 00:49:18 2017 +0200

Add needauth option to gnuplot->PDF converter introduced in 
[066edd3c/lyxgit].

commit 066edd3c
Author: Tommaso Cucinotta 
Date:   Mon Oct 17 08:44:16 2016 +0200

Enable graphics generation from external gnuplot scripts.




sample.gp
Description: application/gnuplot

Re: 2.3.0alpha1-1 round 2

[Kornel Benko]

Am Donnerstag, 4. Mai 2017 um 00:04:44, schrieb Uwe Stöhr 
> El 03.05.2017 a las 12:40, Scott Kostyshak escribió:
> 
> > Here are the tar balls for round 2 of 2.3.0alpha1-1:
> 
> I tried to check the signature but get this message:
> 
> Signed on 2017-05-03 12:27 with unknown certificate 0xDE7A44FAC7FB382D.
> The signature is invalid: No public certificate to verify the signature
> 
> How do I know if the signature is correct or not?

You need probably to import the public key of 0xDE7A44FAC7FB382D

Searching in keyservers for this key I found
LyX Release Manager (Signing LyX tarballs and binaries) sa...@lyx.org
found in hkp://keyserver.ubuntu.com/
and also in hkp://keys.gnupg.net

> > If everything goes well and the binaries build, then I will push the tag
> > and upload the binaries and make the release.
> 
> Everything worked now well. Here is the new installer:
> 
> http://ftp.lyx.de/LyXWinInstaller/LyX2.3alpha1/
> 
> regards Uwe

Kornel

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

Re: [patch] support for document class option leqno

[Uwe Stöhr]

El 03.05.2017 a las 12:05, Jean-Marc Lasgouttes escribió:

To state it again: the number may be on the left without leqno. Do we 
want to provide a way to set it on the right in such cases?


I wrote in my last mail why I wouldn't do this. If others think 
different then fine by me if we support reqno as well.


In the 
example that I provided, the number was in Arabo-Indic.


I again missed things from you. Could you please resend the example? In 
which post have you sent it? (Maybe I need to check my list reading 
software that it doesn't swallow attachments).


So you are telling me that, when you use plain babel (TeX fonts) and 
arabic language, without any fancy leqno option, you do not see that the 
number is on the left without asking for it??? I am surprised.


I don't understand. Yes, without the option leqno I always get the 
numbers on the right side.


No, this is Arabic text at least for some Arabic support packages. I do 
not know the full list, I do not know Arabic. I am just pointing out 
that it is wrong to assume that standard classes always have numbering 
on the right.


I did not say this. I said that this is the default setting of LaTeX. I 
discussed the case when classes changes the default.


So either you have a look at it, or flat out admit that we do not care 
if Arabic users have a misleading UI.


But I did and reported that I always get it in the right side (using 
\documentclass article or scrartcl).
I still don't get your point. leqno leads to left side numbering. If the 
special document class or a package already places the number on the 
left side, then leqno does nothing.


This is half-baked, IMO. Either it is super important to have a 
click-click interface instead of writing leqno in a text field in 
Document Settings, or it is not.


This is not half-baked in my opinion. Supporting reqno requires an 
explicit call of amsmath. Moreover document classes that already don't 
use the default placement have a special reason to do so. I think we 
should distinguish between standard classes (all I know use right 
numbering as default) that can be used for texts you can design freely, 
and document classes for journals that are designed to follow publishing 
guidelines. With these journal classes the user is not allowed to format 
freely. Therefore I don't want to offer an option that would overwrite a 
setting that was most probably set to follow a submission guideline.


However, as I wrote above, I can understand if somebody has another 
opinion and thinks that my approach to distinguish document classes not 
suitable. If so I of course support to add also support for reqno.


So please fell free to ad support reqno if others agree.

thanks and regards
Uwe

p.s. I might not be able to code the next days.

Re: attic/id_UserGuide iconv errors

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 21:20:11, schrieb Guenter Milde 
> On 2017-04-30, Scott Kostyshak wrote:
>
> > [-- Type: text/plain, Encoding:  --]
>
> > On current master if I do:
>
> >   ctest -R "id_UserGuide_pdf2"
>
> > I get a failed export, and iconv errors such as:
>
> >   Error 84 returned from iconv when converting from UCS-4LE to
> >   ISO-8859-15: Invalid or incomplete multibyte or wide character
>
> > I do not get the error when exporting in the GUI or when exporting on
> > the command line.
>
> > Can anyone else reproduce the test failure or is it something specific
> > on my machine?
>
> The test fails here, too:
>
...
>
> Could be some strange CTest-script rewriting.

I am confident it is not. Attached my local
# diff /usr2/src/lyx/lyx-git/lib/doc/attic/id_UserGuide.lyx 
/BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/id_UserGuide_pdf2_defaultF.lyx

As you can see from the diff:
1.) Some comments from the preamble are removed
2.) The paths are changed

> What happens if you use command line export "per hand"?
>

You did not try?
You get the same output on the console.

> Günter

Kornel

signature.asc
Description: This is a digitally signed message part.
9d8
< % DO NOT ALTER THIS PREAMBLE!!!
11,16c10,16
< % This preamble is designed to ensure that the User's Guide prints
< % out as advertised. If you mess with this preamble,
< % parts of the User's Guide may not print out as expected.  If you
< % have problems LaTeXing this file, please contact 
< % the documentation team
< % email: lyx-d...@lists.lyx.org
---
> %
> %
> %
> %
> %
> %
> %
18c18
< % for correct jump positions whe clicking on a link to a float
---
> %
21,22c21,22
< % the pages of the TOC is numbered roman
< % and a pdf-bookmark for the TOC is added
---
> %
> %
30c30
< % define a short command for \textvisiblespace
---
> %
33c33
< % macro for italic page numbers in the index
---
> %
36,37c36,37
< % for customized page headers/footers
< % only needed because they are only used in one section of the document
---
> %
> %
39c39
< % change header rule width
---
> %
42,46c42,46
< % workaround for a makeindex bug,
< % see sec. "Index Entry Order"
< % only uncomment this when you are using makindex
< %\let\OrgIndex\index 
< %\renewcommand*{\index}[1]{\OrgIndex{#1}}
---
> %
> %
> %
> %
> %
48,49c48,49
< % the following added in Bahasa Indonesia Version
< % to follow the most common style (centered chapters) in Indonesia
---
> %
> %
4501c4501
< 	filename ../clipart/ToolbarEnvBox.png
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_ToolbarEnvBox_QTBsaCOr.png
7739c7739
< 	filename ../clipart/Abstract.pdf
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_Abstract_C32f_tHS.pdf
15171c15171
< 	filename ../../images/view-others.svgz
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_view-others_nk190YPG.svgz
16982c16982
< 	filename ../clipart/footnote.png
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_footnote_XjsjkB75.png
17344c17344
< 	filename ../clipart/mobius.eps
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_mobius_VZpy_rwk.eps
21077c21077
< 	filename ../clipart/float.png
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_float_FZ55W7tU.png
21184c21184
< 	filename ../clipart/platypus.eps
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_platypus_RudHaa4R.eps
21364c21364
< 	filename ../clipart/escher-lsd.eps
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_escher-lsd_v91jUmaY.eps
21406c21406
< 	filename ../clipart/platypus.eps
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_platypus_RudHaa4R.eps
22778c22778
< 	filename ../clipart/SpaceMarker.png
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_SpaceMarker_l_Pftmjb.png
25004c25004
< 	filename ../clipart/label.png
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_label_Y15mdxy9.png
25078c25078
< 	filename ../clipart/reference.png
---
> 	filename /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRod/attic/tmp_pdf2_id_id_UserGuide/xx_reference_NoUOFd2B.png
29458c29458
< 	filename ../clipart/ERT.png
---
> 	filename 

Re: 2.3.0alpha1-1 round 2

[Uwe Stöhr]

El 03.05.2017 a las 12:40, Scott Kostyshak escribió:


Here are the tar balls for round 2 of 2.3.0alpha1-1:


I tried to check the signature but get this message:

Signed on 2017-05-03 12:27 with unknown certificate 0xDE7A44FAC7FB382D.
The signature is invalid: No public certificate to verify the signature

How do I know if the signature is correct or not?


If everything goes well and the binaries build, then I will push the tag
and upload the binaries and make the release.


Everything worked now well. Here is the new installer:

http://ftp.lyx.de/LyXWinInstaller/LyX2.3alpha1/

regards Uwe

Re: attic/id_UserGuide iconv errors

[Guenter Milde]

On 2017-04-30, Scott Kostyshak wrote:

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

> On current master if I do:

>   ctest -R "id_UserGuide_pdf2"

> I get a failed export, and iconv errors such as:

>   Error 84 returned from iconv when converting from UCS-4LE to
>   ISO-8859-15: Invalid or incomplete multibyte or wide character

> I do not get the error when exporting in the GUI or when exporting on
> the command line.

> Can anyone else reproduce the test failure or is it something specific
> on my machine?

The test fails here, too:

-- Executing /usr/local/src/lyxtest/bin/lyx2.3  -userdir 
"/usr/local/src/lyxtest/Testing/.lyx" -E pdf2 attic/id_UserGuide_defaultF.pdf2 
"/usr/local/src/lyxtest/autotests/out-home/AbC_MTqvVZ/attic/id_UserGuide_pdf2_defaultF.lyx"
Error 84 returned from iconv when converting from UCS-4LE to ISO-8859-15: 
Invalid or incomplete multibyte or wide character
Converted input: 0x005c 0x006e 0x006f 0x006d 0x0065 0x006e 0x0063 0x006c 0x0061 
0x0074 0x0075 0x0072 0x0065 0x007b 0x0022 0x0040 0x002c 0x0020 0x0022 0x007c 
0x002c 0x0020 0x0022 0x0021 0x002c 0x0020 0x0022 0x0022 0x007d 0x007b 0x0054 
0x0068 0x0065 0x0020 0x0071 0x0075 0x006f 0x0074 0x0065 0x0020 0x0073 0x0069 
0x0067 0x006e 0x0020 0x0069 0x0073 0x0020 0x006f 0x0075 0x0074 0x0070 0x0075 
0x0074 0x0020 0x0062 0x0079 0x0020 0x0077 0x0072 0x0069 0x0074 0x0069 0x006e 
0x0067 0x0020
Stopped at: 0x2018
Unconverted input: 0x0020 0x0022 0x0022 0x0022 0x0022 0x0020 0x0027 0x007d
Converted output: 0x5c 0x6e 0x6f 0x6d 0x65 0x6e 0x63 0x6c 0x61 0x74 0x75 0x72 
0x65 0x7b 0x22 0x40 0x2c 0x20 0x22 0x7c 0x2c 0x20 0x22 0x21 0x2c 0x20 0x22 0x22 
0x7d 0x7b 0x54 0x68 0x65 0x20 0x71 0x75 0x6f 0x74 0x65 0x20 0x73 0x69 0x67 0x6e 
0x20 0x69 0x73 0x20 0x6f 0x75 0x74 0x70 0x75 0x74 0x20 0x62 0x79 0x20 0x77 0x72 
0x69 0x74 0x69 0x6e 0x67 0x20
Error 84 returned from iconv when converting from UCS-4LE to ISO-8859-15: 
Invalid or incomplete multibyte or wide character
Converted input: 0x005c 0x006e 0x006f 0x006d 0x0065 0x006e 0x0063 0x006c 0x0061 
0x0074 0x0075 0x0072 0x0065 0x007b 0x0022 0x0040 0x002c 0x0020 0x0022 0x007c 
0x002c 0x0020 0x0022 0x0021 0x002c 0x0020 0x0022 0x0022 0x007d 0x007b 0x0054 
0x0068 0x0065 0x0020 0x0071 0x0075 0x006f 0x0074 0x0065 0x0020 0x0073 0x0069 
0x0067 0x006e 0x0020 0x0069 0x0073 0x0020 0x006f 0x0075 0x0074 0x0070 0x0075 
0x0074 0x0020 0x0062 0x0079 0x0020 0x0077 0x0072 0x0069 0x0074 0x0069 0x006e 
0x0067 0x0020
Stopped at: 0x2018
Unconverted input: 0x0020 0x0022 0x0022 0x0022 0x0022 0x0020 0x0027 0x007d
Converted output: 0x5c 0x6e 0x6f 0x6d 0x65 0x6e 0x63 0x6c 0x61 0x74 0x75 0x72 
0x65 0x7b 0x22 0x40 0x2c 0x20 0x22 0x7c 0x2c 0x20 0x22 0x21 0x2c 0x20 0x22 0x22 
0x7d 0x7b 0x54 0x68 0x65 0x20 0x71 0x75 0x6f 0x74 0x65 0x20 0x73 0x69 0x67 0x6e 
0x20 0x69 0x73 0x20 0x6f 0x75 0x74 0x70 0x75 0x74 0x20 0x62 0x79 0x20 0x77 0x72 
0x69 0x74 0x69 0x6e 0x67 0x20
Error 84 returned from iconv when converting from UCS-4LE to ISO-8859-15: 
Invalid or incomplete multibyte or wide character
Converted input: 0x005c 0x006e 0x006f 0x006d 0x0065 0x006e 0x0063 0x006c 0x0061 
0x0074 0x0075 0x0072 0x0065 0x007b 0x0022 0x0040 0x002c 0x0020 0x0022 0x007c 
0x002c 0x0020 0x0022 0x0021 0x002c 0x0020 0x0022 0x0022 0x007d 0x007b 0x0054 
0x0068 0x0065 0x0020 0x0071 0x0075 0x006f 0x0074 0x0065 0x0020 0x0073 0x0069 
0x0067 0x006e 0x0020 0x0069 0x0073 0x0020 0x006f 0x0075 0x0074 0x0070 0x0075 
0x0074 0x0020 0x0062 0x0079 0x0020 0x0077 0x0072 0x0069 0x0074 0x0069 0x006e 
0x0067 0x0020
Stopped at: 0x2018
Unconverted input: 0x0020 0x0022 0x0022 0x0022 0x0022 0x0020 0x0027 0x007d
Converted output: 0x5c 0x6e 0x6f 0x6d 0x65 0x6e 0x63 0x6c 0x61 0x74 0x75 0x72 
0x65 0x7b 0x22 0x40 0x2c 0x20 0x22 0x7c 0x2c 0x20 0x22 0x21 0x2c 0x20 0x22 0x22 
0x7d 0x7b 0x54 0x68 0x65 0x20 0x71 0x75 0x6f 0x74 0x65 0x20 0x73 0x69 0x67 0x6e 
0x20 0x69 0x73 0x20 0x6f 0x75 0x74 0x70 0x75 0x74 0x20 0x62 0x79 0x20 0x77 0x72 
0x69 0x74 0x69 0x6e 0x67 0x20
File '/tmp/lyx_tmpdir.bCcocnBi6412/lyx_tmpbuf0/id_UserGuide_pdf2_defaultF.tex' 
was not closed properly.
-- Exporting attic/id_UserGuide.lyx to pdf2
CMake Error at /usr/local/src/lyx/development/autotests/export.cmake:205 
(message):
  Export failed


Could be some strange CTest-script rewriting.
What happens if you use command line export "per hand"?


Günter

Re: [LyX/master] support to indent formulas

[Guenter Milde]

Dear Uwe,

the GUI for "fleqn" still says "[ ] Indent Formulas".

However, formulas are always indented (except for documents with "fleqn"
and "mathindent=0").

> The "fleqn" option determines whether equations are *aligned* or *centered*.

> In both cases, the equations are indented: either with a fixed
> indentation or (the default) a variable one.

> This should be reflected in both, GUI label and internal variable names.

> Therefore, I propose
...
>   [*] Align Formulas:   Indentation  [Default/Custom]
>  [  ]  [em   ]

This avoids also the paradox that you currently must tick "Indent Formulas"
(and set the custom mathindent to zero) to *not* indent formulas!¹

¹This reminds me on Windows: Click the "Start" button to open the "Shutdown"
 menu.


The internal variable should use a name in line with other settings.
There is no setting starting "is_", most boolean settings start with an
action  (\use_,  \maintain_, \suppress_).

I propose \use_fleqn or \align_formulas.

Günter

Re: Re-organizing templates and examples folders (#8715)

[Guenter Milde]

Dear LyX developers,

with feature freeze nearing, I'd like to take up the discussion of templates
and examples folders:


On 2017-04-20, Helge Hafting wrote:

> ... please make [templates] go to ~/.lyx/templates and have
> tools->reconfigure create the symlink to the system template folder.
...
> Lyx should be able to make new documents based on private or std. 
> templates, without the user searching for either. And it should not be 
> necessary to tweak the paths either.

Note: the [templates] and [examples] buttons are missing under OS X and
Windows.

Nevertheless, File>New From template opens the "templates folder" (as set in
the preferences).


Suggestion:

1. easy access to local templates and standard templates:

   * set USERDIR/templates as default templates path
   
   * create a symlink USERDIR/stdtemplates -> SYSDIR/templates.
   
   * Document creation of templates in the User Guide:
   
   Any document can be used as template. 
   For easy acces with File>New from Template, save it under
   USERDIR/templates. Under Linux, you can get to this directory via
   the [templates] box in the File>Save as dialogue.


2. organize templates and examples:

   * create and use language subdirectories


3. "unhide" examples:

   * move examples to lib/doc/examples,
   
   * add a menu entry Help>Examples...

   ? create a symlink USERDIR/examples -> SYSDIR/doc/examples ?


Please comment,

Günter

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 18:57:57, schrieb Tommaso Cucinotta 

> On 03/05/2017 17:42, Tommaso Cucinotta wrote:
> > On 03/05/2017 17:37, Tommaso Cucinotta wrote:
> >> Kornel, would you mind to re-run the tests ?
> >
> > I have this one consistently failing:
> >
> > findadv-02-in.txt: FAILED
> >
> > will dig shortly (I'm going off-line a few hours).
>
> this is what I found:
>
> 1) started from re-running all the findadv-*.txt tests, and got
> all passing, EXCEPT 02, 08, 20, 21, re-04
>
> 2) I need this [1], in order to have findadv-02 and -08 pass;

I used your changes, the tests pass here too.

> the problem is that multiple [Enter] or others seem to hit LyX too fast,
> and, e.g., the second [Enter] arrives while focus was not restored yet on
> the findadv pane, so it deletes the selected found segment from the 
> previous
> [Enter] key press; guess this is related to [515ca693/lyxgit] et al.

I don't think so, because the 'fast' input is only between \Ax and \[Return]
Maybe we should wait after each \[Return] for some time.
See attached.

> 3) all others are "flickering" pass/fail, except findadv-21-in.txt that
> keeps consistently failing, because, AFAICR, this one should be the
> bug about lists matching enums and vice-versa, which is still open
> (no on-line access while writing this e-mail)

Exactly, I wanted to have a test case for this.

> AFAICS, issues just related to the autotests machinery and keytest.py, so 
> clear
> to go for the release, there's no actual problem, as these tests would all 
> pass
> if run manually by a user (except -21).

Yes.

> Thanks,
>
>T.
>

Kornel

signature.asc
Description: This is a digitally signed message part.
diff --git a/development/autotests/keytest.py b/development/autotests/keytest.py
index 7dd86a6..abb4e11 100755
--- a/development/autotests/keytest.py
+++ b/development/autotests/keytest.py
@@ -245,6 +245,7 @@ def sendKeystringLocal(keystr, LYX_PID):
 
 Axreg = re.compile(r'^(.*)\\Ax([^\\]*)(.*)$')
 returnreg = re.compile(r'\\\[Return\](.*)$')
+returnreg2 = re.compile(r'^(.*)\\\[Return\](.*)$')
 
 # recursive wrapper around sendKeystringLocal()
 def sendKeystring(line, LYX_PID):
@@ -268,15 +269,26 @@ def sendKeystring(line, LYX_PID):
 key_delay = saved_delay
 time.sleep(0.1)
 if line != "":
-sendKeystringLocal(line, LYX_PID)
+sendKeystring(line, LYX_PID)
 else:
 if content != "":
 sendKeystringLocal(content, LYX_PID)
 if rest != "":
-sendKeystringLocal(rest, LYX_PID)
+sendKeystring(rest, LYX_PID)
 else:
 if line != "":
-sendKeystringLocal(line, LYX_PID)
+m3 = returnreg2.match(line)
+if m3:
+prefix = m3.group(1)
+rest = m3.group(2)
+if prefix != "":
+sendKeystring(prefix, LYX_PID)
+sendKeystringLocal('\[Return]', LYX_PID)
+time.sleep(0.1)
+if rest != "":
+sendKeystring(rest, LYX_PID)
+else:
+sendKeystringLocal(line, LYX_PID)
 
 
 def system_retry(num_retry, cmd):

Re: [patch] support for document class option leqno

[Guenter Milde]

On 2017-05-03, Jean-Marc Lasgouttes wrote:
> Le 02/05/2017 à 23:02, Uwe Stöhr a écrit :

...

> To state it again: the number may be on the left without leqno. Do we 
> want to provide a way to set it on the right in such cases?
...
> or flat out admit that we do not care if Arabic users have a
> misleading UI.

as well as the users of the AMS article and book document classes supported
by LyX.


>> So I would like to keep it as it is:
>> - LyX supports to switch the numbering side from the default right side
>> to the left.
>> - if a user uses a special class using as default left numbering he
>> knows if overriding this makes sense or not. LyX leaves such a very
>> special case tho the user.

> This is half-baked, IMO. Either it is super important to have a 
> click-click interface instead of writing leqno in a text field in 
> Document Settings, or it is not. But I don't care that much and I will 
> do my part of the deal when the dust settles.

Without vetoing any decision: my preference is:

a) No special support for leqno and reqno. 
   Users can easily specify this in the custom document options.

b) Support both, leqno and reqno. Properly.
   With feedback in the GUI and correct LyXHTML export.

   Document>Settings>Math Options:
   ...
   Equation numbers: [default]
 [left   ]
 [right  ]

I will not veto a half-support (leaving out reqno), but expect a bug
report for full support if half-support ends in 2.3.


Regarding the naming: 

A search for "formula number" reveals hits like
  
  Formula: Number of additionals / Article with additional quantity

  Excel Formula - Number within range..
  
  The Natural Remedy Bible 
  FORMULA NUMBER 87: Stinging Nettles Freeze Dried
  
but also  
  
  How do I number my equations? - Apache OpenOffice Wiki
  
OTOH, searching for "equation number" finds

  Equation Numbering in Office 2016 
  
  Numbering Equations (Microsoft Word)
  
  Show equation number only once in align environment - TeX - LaTeX 

Also, there are 543 results for »"formula number" stackexchange« but
93.900 results for »"equation number" stackexchange«.

In LyX, the menu entry is "numbered formula". OTOH, when tagging the
default prefix is "eq:".


Günter

Re: Default to Qt 4 or Qt 5 with our build systems?

[Enrico Forestieri]

On Wed, May 03, 2017 at 11:29:30AM +0200, Jean-Marc Lasgouttes wrote:
> Le 02/05/2017 à 03:13, Scott Kostyshak a écrit :
> > On Mon, May 01, 2017 at 07:21:18PM +0200, Guillaume MM wrote:
> > > Le 01/05/2017 à 18:43, Jean-Marc Lasgouttes a écrit :
> > > > We can define a lower bound for acceptable qt5 version like we do for 
> > > > python 3 vs 2. I would not want a crappy qt 5.1 on a system with a 
> > > > perfectly valid qt4.8.
> > 
> > +1
> 
> I took a quick look at the configure code, but, considering the way the code
> works, it seems a bit difficult to get the qt4 and qt5 versions. Enrico,
> would you have an idea?

It should be possible, but I am short on time lately.

> Having Qt5 as default would be trivial, though.

In this case, I think that we should try to automatically configure
for Qt4 if Qt5 is not available or not adequate.

-- 
Enrico

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Tommaso Cucinotta]

On 03/05/2017 17:42, Tommaso Cucinotta wrote:

On 03/05/2017 17:37, Tommaso Cucinotta wrote:

Kornel, would you mind to re-run the tests ?


I have this one consistently failing:

findadv-02-in.txt: FAILED

will dig shortly (I'm going off-line a few hours).


this is what I found:

1) started from re-running all the findadv-*.txt tests, and got
   all passing, EXCEPT 02, 08, 20, 21, re-04

2) I need this [1], in order to have findadv-02 and -08 pass;
   the problem is that multiple [Enter] or others seem to hit LyX too fast,
   and, e.g., the second [Enter] arrives while focus was not restored yet on
   the findadv pane, so it deletes the selected found segment from the previous
   [Enter] key press; guess this is related to [515ca693/lyxgit] et al.

3) all others are "flickering" pass/fail, except findadv-21-in.txt that
   keeps consistently failing, because, AFAICR, this one should be the
   bug about lists matching enums and vice-versa, which is still open
   (no on-line access while writing this e-mail)

AFAICS, issues just related to the autotests machinery and keytest.py, so clear
to go for the release, there's no actual problem, as these tests would all pass
if run manually by a user (except -21).

Thanks,

  T.

[1]

$ git diff
diff --git a/development/autotests/findadv-02-in.txt 
b/development/autotests/findadv-02-in.txt
index 7fb840e6..9954b499 100644
--- a/development/autotests/findadv-02-in.txt
+++ b/development/autotests/findadv-02-in.txt
@@ -7,6 +7,7 @@ KK: x^(a) +\\frac 1+x^(a) \[Down]1-x^(a)  \C\[Home]
 KK: \CF
 KK: \Cmx^(a) \[Tab]
 KK: \Cmx_a
+KD: 100
 KK: \[Return]\[Return]\[Return]
 KD: 60
 KK: \Cs
diff --git a/development/autotests/findadv-08-in.txt 
b/development/autotests/findadv-08-in.txt
index a0f6d952..eb0699cf 100644
--- a/development/autotests/findadv-08-in.txt
+++ b/development/autotests/findadv-08-in.txt
@@ -20,6 +20,7 @@ KK: o
 KK: \Axregexp-mode\[Return]
 KK: [\\w]* a
 # select whole words
+KD: 100
 KK: \Ac\Ac
 # search next
 KK: \Al
@@ -33,7 +34,6 @@ KK: \C\[Home]\Axdialog-show findreplaceadv\[Return]
 KK: \Axregexp-mode\[Return]
 KK: .* \Ac\Ac
 KK: \Al\Al\Al
-KK: \[Tab]\[Return]
 TestEnd
 Lang C
 Assert pcregrep -M 'Putting selection at .*idx: 0 par: 0 pos: 10\n with len: 
3' lyx-log3.txt

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Tommaso Cucinotta]

On 03/05/2017 17:42, Tommaso Cucinotta wrote:

On 03/05/2017 17:37, Tommaso Cucinotta wrote:

Kornel, would you mind to re-run the tests ?


I have this one consistently failing:

findadv-02-in.txt: FAILED

will dig shortly (I'm going off-line a few hours).


this is what I found:

1) started from re-running all the findadv-*.txt tests, and got
   all passing, EXCEPT 02, 08, 20, 21, re-04

2) I need this [1], in order to have findadv-02 and -08 pass;
   the problem is that multiple [Enter] or others seem to hit LyX too fast,
   and, e.g., the second [Enter] arrives while focus was not restored yet on
   the findadv pane, so it deletes the selected found segment from the previous
   [Enter] key press; guess this is related to [515ca693/lyxgit] et al.

3) all others are "flickering" pass/fail, except findadv-21-in.txt that
   keeps consistently failing, because, AFAICR, this one should be the
   bug about lists matching enums and vice-versa, which is still open
   (no on-line access while writing this e-mail)

AFAICS, issues just related to the autotests machinery and keytest.py, so clear
to go for the release, there's no actual problem, as these tests would all pass
if run manually by a user (except -21).

Thanks,

  T.

[1]

$ git diff
diff --git a/development/autotests/findadv-02-in.txt 
b/development/autotests/findadv-02-in.txt
index 7fb840e6..9954b499 100644
--- a/development/autotests/findadv-02-in.txt
+++ b/development/autotests/findadv-02-in.txt
@@ -7,6 +7,7 @@ KK: x^(a) +\\frac 1+x^(a) \[Down]1-x^(a)  \C\[Home]
 KK: \CF
 KK: \Cmx^(a) \[Tab]
 KK: \Cmx_a
+KD: 100
 KK: \[Return]\[Return]\[Return]
 KD: 60
 KK: \Cs
diff --git a/development/autotests/findadv-08-in.txt 
b/development/autotests/findadv-08-in.txt
index a0f6d952..eb0699cf 100644
--- a/development/autotests/findadv-08-in.txt
+++ b/development/autotests/findadv-08-in.txt
@@ -20,6 +20,7 @@ KK: o
 KK: \Axregexp-mode\[Return]
 KK: [\\w]* a
 # select whole words
+KD: 100
 KK: \Ac\Ac
 # search next
 KK: \Al
@@ -33,7 +34,6 @@ KK: \C\[Home]\Axdialog-show findreplaceadv\[Return]
 KK: \Axregexp-mode\[Return]
 KK: .* \Ac\Ac
 KK: \Al\Al\Al
-KK: \[Tab]\[Return]
 TestEnd
 Lang C
 Assert pcregrep -M 'Putting selection at .*idx: 0 par: 0 pos: 10\n with len: 
3' lyx-log3.txt

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 17:42:25, schrieb Tommaso Cucinotta 

> On 03/05/2017 17:37, Tommaso Cucinotta wrote:
> > Kornel, would you mind to re-run the tests ?
>
> I have this one consistently failing:
>
>  findadv-02-in.txt: FAILED

This one passes here.

The ones which do not pass here are:
keytest/findadv-21 (expected, known bug)
keytest/findadv-re-06 (retest alone passed)

The test.tex-output  of findadv-02 is attached, together with lyx-log.txt

> will dig shortly (I'm going off-line a few hours).
>
>   T.

Kornel

signature.asc
Description: This is a digitally signed message part.
%% LyX 2.3.0dev created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[english]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{babel}
\begin{document}
$x_{a}+\frac{1+x_{a}}{1-x^{(a)}}$
\end{document}
Livello di verifica impostato a find
Sto verificando `find' (Procedura di trova e sostituisci)
frontends/qt4/FindAndReplace.cpp (557): Selecting entire find buffer
frontends/qt4/FindAndReplace.cpp (119): Focusing replace WA
frontends/qt4/FindAndReplace.cpp (121): Selecting entire replace buffer
frontends/qt4/FindAndReplace.cpp (467): FindAndReplaceOptions: 
find_buf_name=/tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.qy6884, 
casesensitiv=0, matchword=0, backwards=0, expandmacros=0, ignoreformat=1, 
repl_buf_name/tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.Yb6884, 
keep_case=0, scope=0, restr=0
lyxfind.cpp (1566): built: /tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.qy6884
EOSS
0 0 1 0 1 /tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.Yb6884
EOSS
0 0 0
frontends/qt4/FindAndReplace.cpp (347): Dispatching LFUN_WORD_FINDADV
lyxfind.cpp (1574): parsing
lyxfind.cpp (1586): file_buf_name: 
'/tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.qy6884'
lyxfind.cpp (1600): repl_buf_name: 
'/tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.Yb6884'
lyxfind.cpp (1611): parsed: 0 0 1 0 1 0 0 0
lyxfind.cpp (1574): parsing
lyxfind.cpp (1586): file_buf_name: 
'/tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.qy6884'
lyxfind.cpp (1600): repl_buf_name: 
'/tmp/lyx_tmpdir.IfdcFMzE6884/embedded.internal.Yb6884'
lyxfind.cpp (1611): parsed: 0 0 1 0 1 0 0 0
lyxfind.cpp (829): Adding to search string: 'x^{(a)}'
lyxfind.cpp (1061): Removing stale empty \emph{}, \textbf{}, \*section{} macros 
from: x^{(a)}
lyxfind.cpp (1070): After {} replacement: 'x^_x_<(a)}'
lyxfind.cpp (1070): After {} replacement: 'x^_x_<(a)_x_>'
lyxfind.cpp (859): identifyClosing(): t now is 'x^_x_<(a)_x_>'
lyxfind.cpp (859): identifyClosing(): t now is 'x^_x_<(a)_x_>'
lyxfind.cpp (905): Open braces: 0
lyxfind.cpp (906): Built MatchStringAdv object: par_as_string = 'x^_x_<(a)_x_>'
lyxfind.cpp (1441): sel_beg:  inset: 0x4729040 idx: 0 par: 0 pos: 0
, sel_end:  inset: 0x4729040 idx: 0 par: 0 pos: 0
, sel_len: 0

lyxfind.cpp (1236): findForwardAdv() cur:  inset: 0x4729040 idx: 0 par: 0 pos: 0

lyxfind.cpp (1083): Stringifying with len=-1 from cursor at pos:  inset: 
0x4729040 idx: 0 par: 0 pos: 0

lyxfind.cpp (1097): Stringifying with cur:  inset: 0x4729040 idx: 0 par: 0 pos: 0
, from pos: 0, end: 1
lyxfind.cpp (1061): Removing stale empty \emph{}, \textbf{}, \*section{} macros 
from: x^{(a)}+\frac{1+x^{(a)}}{1-x^{(a)}}
lyxfind.cpp (1070): After {} replacement: 
'x^_x_<(a)}+\frac_x_<1+x^_x_<(a)}}_x_<1-x^_x_<(a)}}'
lyxfind.cpp (1070): After {} replacement: 
'x^_x_<(a)_x_>+\frac_x_<1+x^_x_<(a)_x_>_x_>_x_<1-x^_x_<(a)_x_>_x_>'
lyxfind.cpp (958): Matching against 'x^{(a)}+\frac{1+x^{(a)}}{1-x^{(a)}}'
lyxfind.cpp (959): After normalization: 
'x^_x_<(a)_x_>+\frac_x_<1+x^_x_<(a)_x_>_x_>_x_<1-x^_x_<(a)_x_>_x_>'
lyxfind.cpp (998): Searching in normal mode: par_as_string='x^_x_<(a)_x_>', 
str='x^_x_<(a)_x_>+\frac_x_<1+x^_x_<(a)_x_>_x_>_x_<1-x^_x_<(a)_x_>_x_>'
lyxfind.cpp (1001): Searching in normal mode: lead_as_string='', 
par_as_string_nolead='x^_x_<(a)_x_>'
lyxfind.cpp (1023): res=13, at_begin=0, matchword=0, inTexted=1
lyxfind.cpp (1238): match_len: 13
lyxfind.cpp (1241): Advancing cur:  inset: 0x4729040 idx: 0 par: 0 pos: 0

lyxfind.cpp (1083): Stringifying with len=-1 from cursor at pos:  inset: 
0x4729040 idx: 0 par: 0 pos: 0

lyxfind.cpp (1097): Stringifying with cur:  inset: 0x4729040 idx: 0 par: 0 pos: 0
, from pos: 0, end: 1
lyxfind.cpp (1061): Removing stale empty \emph{}, \textbf{}, \*section{} macros 
from: x^{(a)}+\frac{1+x^{(a)}}{1-x^{(a)}}
lyxfind.cpp (1070): After {} replacement: 
'x^_x_<(a)}+\frac_x_<1+x^_x_<(a)}}_x_<1-x^_x_<(a)}}'
lyxfind.cpp (1070): After {} replacement: 
'x^_x_<(a)_x_>+\frac_x_<1+x^_x_<(a)_x_>_x_>_x_<1-x^_x_<(a)_x_>_x_>'
lyxfind.cpp (958): Matching against 'x^{(a)}+\frac{1+x^{(a)}}{1-x^{(a)}}'
lyxfind.cpp (959): After normalization: 
'x^_x_<(a)_x_>+\frac_x_<1+x^_x_<(a)_x_>_x_>_x_<1-x^_x_<(a)_x_>_x_>'
lyxfind.cpp (998): Searching in normal mode: par_as_string='x^_x_<(a)_x_>', 

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Tommaso Cucinotta]

On 03/05/2017 17:37, Tommaso Cucinotta wrote:

Kornel, would you mind to re-run the tests ?


I have this one consistently failing:

findadv-02-in.txt: FAILED

will dig shortly (I'm going off-line a few hours).

T.

Re: [LyX/master] Revert "findadv: hide word-findadv verb from the mini-buffer"

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 17:20:17, schrieb Tommaso Cucinotta 

> commit 100a7ee22ff44fd101af4e52bdb3d632244ba258
> Author: Tommaso Cucinotta 
> Date:   Wed May 3 16:37:11 2017 +0200
> 
> Revert "findadv: hide word-findadv verb from the mini-buffer"
> 
> This reverts commit 8c10182962efa643edfcfbe64fc830b5fc0d9a65.
> ---
>  src/LyXAction.cpp |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
> index 3804fad..e9f45f5 100644
> --- a/src/LyXAction.cpp
> +++ b/src/LyXAction.cpp
> @@ -4069,7 +4069,7 @@ void LyXAction::init()
>   * \li Origin: Tommaso, Nov 15 2007
>   * \endvar
>   */
> - { LFUN_WORD_FINDADV, "", ReadOnly | NoBuffer, Hidden },
> + { LFUN_WORD_FINDADV, "word-findadv", ReadOnly | NoBuffer, Edit 
> },
>  
>  /*!
>   * \var lyx::FuncCode lyx::LFUN_WORD_FIND_BACKWARD

I think, this commit was not guilty.
But the other one (e.g. 3610cdf66944dc790e2e3df666e99f33c45b1ede) is.

Kornel

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

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Jean-Marc Lasgouttes]

Le 03/05/2017 à 17:37, Tommaso Cucinotta a écrit :

As for the "word-findadv" verb, I don't have strong opinions about
hiding that, and
I don't know for sure what these "Edit" vs "Hidden" etc. flags are for
:(...


It is to know in what group the function appears when one tries to 
customize the bindings in preferences.


JMarc

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Tommaso Cucinotta]

On 03/05/2017 11:26, Jean-Marc Lasgouttes wrote:

3610cdf66944dc790e2e3df666e99f33c45b1ede


Yes, this is much less surprising than to two other commits.


this is now (correctly) fixed in

commit cf6bbe21
Author: Tommaso Cucinotta 
Date:   Wed May 3 17:32:31 2017 +0200

findadv: amend [8c101829/lyxgit] check that opt.find_buf_name is found in 
theBuffers().


and we have back a manually working findadv pane.

Kornel, would you mind to re-run the tests ?

As for the "word-findadv" verb, I don't have strong opinions about hiding that, 
and
I don't know for sure what these "Edit" vs "Hidden" etc. flags are for :(...

Similar for "word-find" which seems to suffer of a similar usability issue 
(from the mini-buf).

Thanks,

T.

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Tommaso Cucinotta]

my bad, quite blind commits without testing, I just reverted the suppression of the 
"word-findadv" lfun name,
but, as you just pointed out, it was actually the crash fix to break all tests 
:-)! (just confirmed that
reverting that as well recovers a working findadv pane)

T.

On 03/05/2017 11:26, Jean-Marc Lasgouttes wrote:

Le 03/05/2017 à 10:44, Kornel Benko a écrit :

Testing manually, I see, that replace is not working. (E.g. findadv does not 
find anything)
Hm, test passes after reverting also 3610cdf66944dc790e2e3df666e99f33c45b1ede


Yes, this is much less surprising than to two other commits.

JMarc

Re: has anyone tested master with GCC 7.1?

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 14:57:11, schrieb Jean-Marc Lasgouttes 

> Le 03/05/2017 à 14:40, Kornel Benko a écrit :
> > Just compiled. This are the logged warnings:
> > /usr/src/lyx/lyx-git/3rdparty/mythes/1.2.5/mythes.cxx:51:29: warning: 
> > comparison between signed and unsigned integer expressions [-Wsign-compare]
> > /usr/src/lyx/lyx-git/3rdparty/mythes/1.2.5/mythes.cxx:179:36: warning: 
> > comparison between signed and unsigned integer expressions [-Wsign-compare]
> 
> This is third party code, I am not sure whether we should fix it.
> 
> > /usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:34:105:
> >  warning: converting to non-pointer type ‘short unsigned int’ from NULL 
> > [-Wconversion-null]
> > /usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:101:114:
> >  warning: converting to non-pointer type ‘short unsigned int’ from NULL 
> > [-Wconversion-null]
> > /usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:34:105:
> >  warning: converting to non-pointer type ‘short unsigned int’ from NULL 
> > [-Wconversion-null]
> > /usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:101:114:
> >  warning: converting to non-pointer type ‘short unsigned int’ from NULL 
> > [-Wconversion-null]
> 
> Should we upgrade to hunspell 1.6.1 from here http://hunspell.github.io/ ?
> Do you see the same warnings when using the system hunspell?

No.

> > /usr2/src/lyx/lyx-git/src/insets/InsetIPAMacro.cpp:547:10: warning: 
> > statement will never be executed [-Wswitch-unreachable]
> 
> This one should be gone now.

Yes.
 
> JMarc

Kornel

Re: Gnuplot format & converter script

[Scott Kostyshak]

On Sun, Mar 12, 2017 at 11:28:27PM -0400, Scott Kostyshak wrote:
> On Fri, Nov 04, 2016 at 11:51:55AM +0100, Tommaso Cucinotta wrote:
> > On 04/11/2016 10:31, Jean-Marc Lasgouttes wrote:
> > > > enable the feature. Also, I guess that integration of external materials
> > > > suffers of similar security risks.
> > > Another big hole is Sweave/knitr.
> > 
> > so, guess we deserve a TT: https://www.lyx.org/trac/ticket/10481
> 
> Hi Tommaso,
> 
> Now that the ticket has been mostly addressed, is there any other
> barrier for your gnuplot patch?

Tommaso, I'm still curious if you are planning to implement the gnuplot
patch for 2.3.0? Or perhaps you already did and I missed it?

The reason I ask is that time is running out to get features into 2.3.0
before we should focus completely on bug fixes.

Scott


signature.asc
Description: PGP signature

Re: has anyone tested master with GCC 7.1?

[Jean-Marc Lasgouttes]

Le 03/05/2017 à 14:40, Kornel Benko a écrit :

Just compiled. This are the logged warnings:
/usr/src/lyx/lyx-git/3rdparty/mythes/1.2.5/mythes.cxx:51:29: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
/usr/src/lyx/lyx-git/3rdparty/mythes/1.2.5/mythes.cxx:179:36: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]


This is third party code, I am not sure whether we should fix it.


/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:34:105: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]
/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:101:114: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]
/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:34:105: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]
/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:101:114: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]


Should we upgrade to hunspell 1.6.1 from here http://hunspell.github.io/ ?
Do you see the same warnings when using the system hunspell?


/usr2/src/lyx/lyx-git/src/insets/InsetIPAMacro.cpp:547:10: warning: statement 
will never be executed [-Wswitch-unreachable]


This one should be gone now.

JMarc

Re: has anyone tested master with GCC 7.1?

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 13:54:14, schrieb Jean-Marc Lasgouttes 

> Le 03/05/2017 à 13:21, Scott Kostyshak a écrit :
> > I'm just curious, has anyone tested compiling master with GCC 7.1?
> > I'm wondering if any of the changes [1] affect LyX.
> 
> Not me. Latest ubuntu has 6.3.
> 
> We might have some new warnings, although clang++ does not show any (and 
> we use coverity now).
> 
> JMarc

Just compiled. This are the logged warnings:
/usr/src/lyx/lyx-git/3rdparty/mythes/1.2.5/mythes.cxx:51:29: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
/usr/src/lyx/lyx-git/3rdparty/mythes/1.2.5/mythes.cxx:179:36: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:34:105: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]
/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:101:114: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]
/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:34:105: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]
/usr/src/lyx/lyx-git/3rdparty/hunspell/1.3.3/src/hunspell/affentry.hxx:101:114: 
warning: converting to non-pointer type ‘short unsigned int’ from NULL 
[-Wconversion-null]
/usr2/src/lyx/lyx-git/src/insets/InsetIPAMacro.cpp:547:10: warning: statement 
will never be executed [-Wswitch-unreachable]


Kornel

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

Re: has anyone tested master with GCC 7.1?

[Jean-Marc Lasgouttes]

Le 03/05/2017 à 13:21, Scott Kostyshak a écrit :

I'm just curious, has anyone tested compiling master with GCC 7.1?
I'm wondering if any of the changes [1] affect LyX.


Not me. Latest ubuntu has 6.3.

We might have some new warnings, although clang++ does not show any (and 
we use coverity now).


JMarc

Re: should wiki uploads be https by default?

[Scott Kostyshak]

On Mon, Apr 24, 2017 at 02:01:37AM -0400, Scott Kostyshak wrote:

> I have the same comment for
> 
>   https://www.lyx.org/Download
> 
> We have e.g. the Windows icon as:
> 
>   http://www.lyx.org/images/oswin.gif
> 
> In the source, it is written as
> 
>   %lfloat% images:oswin.gif

Bump. It would be nice to at least have 

https://www.lyx.org/Download

provide a secure connection for the final release. I would normally
propose this as a release blocker, but since we've only implemented
https recently, I guess that is extreme.

Scott


signature.asc
Description: PGP signature

has anyone tested master with GCC 7.1?

[Scott Kostyshak]

I'm just curious, has anyone tested compiling master with GCC 7.1?
I'm wondering if any of the changes [1] affect LyX.

Scott

[1]
https://gcc.gnu.org/gcc-7/changes.html


signature.asc
Description: PGP signature

update on feature freeze

[Scott Kostyshak]

Dear all,

(TLDR: feature freeze is 19 May. After 10 May, patches implementing a
new feature need a +1 from another LyX developer before committing to
master)

The feature freeze is still planned for 19 May.

Starting 10 May, a +1 is needed from another LyX developer for any patch
that is implementing a new feature. The purpose of this is to make sure
that we do not rush to commit unpolished patches just because we are
trying to beat the feature freeze.

Whether a patch is a "feature" is subjective so I want to give you some
advanced notice on what my thoughts are on it.

If a patch is not clearly fixing a bug, there will be a high chance that
it will be rejected (for the purposes of 2.3.0) after 19 May. *Even if*
one or more of the following is true:

  - the patch fixes a killer feature that everyone would love to have
  - the patch is simple
  - the patch is such that if it is not accepted into 2.3.0, it would
have to wait until 2.4.0
  - everyone has tested the patch and it works great on Mac, Linux,
Windows, 3 Qt versions, 3 versions of Clang, 3 versions of GCC
  - the patch includes tests

the patch might still be rejected for not fixing a bug. The purpose of
the feature freeze is to encourage developers to work on boring but
important bugs, and to avoid introducing more code that could lead to
new bugs. 2.3.0 will surely have bugs, but we can reduce the amount of
bugs by not introducing features late in the game.

Of course, you can ask for an exception, but I will not feel the need to
give a long explanation if I do not give an exception. I must admit that
if all five of the above arguments are true for a particular case, that
would be a strong case for an exception.

I think a good example of an issue that might be considered a bug by
some or a feature by others is my work on allowing spaces in branch
names (you can see my stumbling around on this at [1]). You could view
this as a bug or a feature. I view it as a feature and thus if I don't
finish it by 19 May I will just wait until 2.4.0. On the other hand, a
minor patch that does not allow a space to be input through the GUI
would be a bug fix and thus might still be considered for 2.3.0 after 19
May.

By the way (to give more insight), another reason I might reject my
patch on allowing spaces in branches, regardless of the feature freeze,
is that I don't recall seeing any user filing a bug report or even
mentioning this behavior. Thus, I don't think it is an important patch.
Even if the patch is simple, I'm not convinced the small amount of risk
is worth the small amount of benefit.

If you have any specific questions about what I will consider to be a
patch that falls under the "feature" category, please ask now, so that
there are no surprises.

Scott

[1] 
https://www.mail-archive.com/search?l=mid=20161014155132.wo3authr3zkbe7hy%40steph



signature.asc
Description: PGP signature

Re: LyX 2.3.0alpha1-1

[Scott Kostyshak]

On Wed, May 03, 2017 at 07:32:13AM +0200, Kornel Benko wrote:
> Am Dienstag, 2. Mai 2017 um 19:19:44, schrieb Scott Kostyshak 
> 
> > On Tue, May 02, 2017 at 08:24:40AM +0200, Kornel Benko wrote:
> > > Am Montag, 1. Mai 2017 um 20:25:44, schrieb Scott Kostyshak 
> > > 
> > 
> > > > Kornel, which commits should I cherry-pick from master to
> > > > 2.3.0-alpha1-x? i.e. which commits do I need for Uwe to build from the
> > > > tar ball?
> > > 
> > > I committed it now under 0935f94
> > 
> > OK. And 0f798d6 is needed also right?
> 
> No, it is not needed. Only if one wants to add numbers different to '2.3' 
> version.
> (But it does not harm either)

OK

> > Anything (in addition to 0935f94
> > and 0f798d6) after db8069c2 that I need to cherry-pick for the Windows
> > build?
> 
> Not that I were aware of.

Thanks for checking. I cherry-picked 0935f94 to 5c7df3cc.

I made the tar balls and sent them to Stephan and Uwe. If everything
goes well, we will make the official release of alpha1-1 soon.

Scott


signature.asc
Description: PGP signature

Re: Crash with using lyx-function word-findadv

[Kornel Benko]

Am Dienstag, 2. Mai 2017 um 17:56:21, schrieb Tommaso Cucinotta 

> On 02/05/2017 11:19, Kornel Benko wrote:
> > Start lyx
> > select new file
> > type anything e.g. 'abcd'
> > Goto home position
> > in minibuffer type word-findadv a
> > Any (or no at all) parameter to this function leads to crash.
> > This is independent of active search dialog.
> 
> (would be great to have an autotest for this :-) )
> the attached patch fixes the crash for me, can you please check ?
> 
> Can we commit to master now ?

In case you had not noticed, with this committed patch many of findadv test do 
not pass.

> > For comparision, the function 'word-find' does not crash, but doesn't find 
> > anything either.
> 
> these LFUNs use a special syntax to be provided, encoding the set of 
> available search options as a string; the regular word-find can be hand-made, 
> but the one needed by the word-findadv() requires a multi-line options string 
> including the name of the search and replace internal buffers within 
> theBuffers(), which are generally things internal to LyX and not exposed to 
> the user...
> ... if we'd like to have a "word-findadv a" command to find "a" with default 
> options, that can be achieved by tweaking the
> 
>istringstream & operator>>(istringstream & is, FindAndReplaceOptions & opt)
> 
> function in lyxfind.cpp. Can't remember why this is done this way (passing 
> the names of these 2 buffers), probably at that time I couldn't find a 
> better/simpler way to find those 2 special buffers from the lyxfind.cpp 
> context :-(!
> 
>   T.

Kornel

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

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

[ci-lyx]

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

Re: [patch] support for document class option leqno

[Jean-Marc Lasgouttes]

Le 02/05/2017 à 23:02, Uwe Stöhr a écrit :

I see it a bit different:
- leqno puts the formula number ALWAYS on the left side. This is clearly
stated in the AMS manuals and also in the LaTeX companion 2nd edition.
I spent some time in testing out Farsi, Arabic and Hebrew and with leqno
I get the number on the left side.


Sure, it is in its name.


So as I wrote, I don't see a problem. I trusted you that you got it at
the right side but you have not provided such a case.


To state it again: the number may be on the left without leqno. Do we 
want to provide a way to set it on the right in such cases?In the 
example that I provided, the number was in Arabo-Indic.


So you are telling me that, when you use plain babel (TeX fonts) and 
arabic language, without any fancy leqno option, you do not see that the 
number is on the left without asking for it??? I am surprised.



Concerning reqno, this is already the default. It has only an effect for
document classes using left numbering. But these are special classes for
scientific journals.


No, this is Arabic text at least for some Arabic support packages. I do 
not know the full list, I do not know Arabic. I am just pointing out 
that it is wrong to assume that standard classes always have numbering 
on the right. I tried with Farsi and Hebrew, but it looks like I am 
missing some fonts (for plain babel version). With non TeX font, it 
looks like I have to select a font, or whatever, and seriously I do not 
want to do that.


So either you have a look at it, or flat out admit that we do not care 
if Arabic users have a misleading UI.



So I would like to keep it as it is:
- LyX supports to switch the numbering side from the default right side
to the left.
- if a user uses a special class using as default left numbering he
knows if overriding this makes sense or not. LyX leaves such a very
special case tho the user.


This is half-baked, IMO. Either it is super important to have a 
click-click interface instead of writing leqno in a text field in 
Document Settings, or it is not. But I don't care that much and I will 
do my part of the deal when the dust settles.


JMarc

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

[ci-lyx]

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

Re: Default to Qt 4 or Qt 5 with our build systems?

[Jean-Marc Lasgouttes]

Le 02/05/2017 à 03:13, Scott Kostyshak a écrit :

On Mon, May 01, 2017 at 07:21:18PM +0200, Guillaume MM wrote:

Le 01/05/2017 à 18:43, Jean-Marc Lasgouttes a écrit :

We can define a lower bound for acceptable qt5 version like we do for python 3 
vs 2. I would not want a crappy qt 5.1 on a system with a perfectly valid qt4.8.


+1


I took a quick look at the configure code, but, considering the way the 
code works, it seems a bit difficult to get the qt4 and qt5 versions. 
Enrico, would you have an idea?


Having Qt5 as default would be trivial, though.

JMarc

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Jean-Marc Lasgouttes]

Le 03/05/2017 à 10:44, Kornel Benko a écrit :

Testing manually, I see, that replace is not working. (E.g. findadv does not 
find anything)
Hm, test passes after reverting also 3610cdf66944dc790e2e3df666e99f33c45b1ede


Yes, this is much less surprising than to two other commits.

JMarc

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 10:08:40, schrieb Jean-Marc Lasgouttes 

> Le 03/05/2017 à 10:05, Kornel Benko a écrit :
> > Am Mittwoch, 3. Mai 2017 um 09:41:08, schrieb Jean-Marc Lasgouttes 
> > 
> >> Le 03/05/2017 à 07:48, Stephan Witt a écrit :
> >>> Something like the attached patch is needed!?
> >>
> >> Yes, I just did that.
> >>
> >> JMarc
> >
> > You did, but without test.
> > # ctest -R findadv
> > ...
> > 10% tests passed, 26 tests failed out of 29
> 
> Indeed, because those tests are cmake based, and I am not.
> 
> I can revert, but this gives us something the does not compile. Does it 
> compile with cmake? Why?

It did not compile.

> I would be surprised to hear that my commit did kill the tests, but I 
> learn every day!
> 
> Could you try to revert locally and see what happens?

Reverted now fa146a0ffe431ce239851fc20986e3052127f33a and 
8c10182962efa643edfcfbe64fc830b5fc0d9a65
 # ctest -R findadv-01 ==> Failed too
(crashes lyx)

Testing manually, I see, that replace is not working. (E.g. findadv does not 
find anything)
Hm, test passes after reverting also 3610cdf66944dc790e2e3df666e99f33c45b1ede

> JMarc

Kornel



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

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

[ci-lyx]

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

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Jean-Marc Lasgouttes]

Le 03/05/2017 à 10:05, Kornel Benko a écrit :

Am Mittwoch, 3. Mai 2017 um 09:41:08, schrieb Jean-Marc Lasgouttes 


Le 03/05/2017 à 07:48, Stephan Witt a écrit :

Something like the attached patch is needed!?


Yes, I just did that.

JMarc


You did, but without test.
# ctest -R findadv
...
10% tests passed, 26 tests failed out of 29


Indeed, because those tests are cmake based, and I am not.

I can revert, but this gives us something the does not compile. Does it 
compile with cmake? Why?


I would be surprised to hear that my commit did kill the tests, but I 
learn every day!


Could you try to revert locally and see what happens?

JMarc

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 09:41:08, schrieb Jean-Marc Lasgouttes 

> Le 03/05/2017 à 07:48, Stephan Witt a écrit :
> > Something like the attached patch is needed!?
> 
> Yes, I just did that.
> 
> JMarc

You did, but without test.
# ctest -R findadv
...
10% tests passed, 26 tests failed out of 29

Kornel

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

Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer

[Jean-Marc Lasgouttes]

Le 03/05/2017 à 07:48, Stephan Witt a écrit :

Something like the attached patch is needed!?


Yes, I just did that.

JMarc

Re: [LyX/master] Added testcase for crash with using function word-findadv

[Kornel Benko]

Am Mittwoch, 3. Mai 2017 um 01:42:08, schrieb Tommaso Cucinotta 

> hmm.., not sure if [8c101829/lyxgit] would need a rollback then...

I still hope that it will be possible to use this function from the minibuffer.
Someday. Sure, it feels hopelessly ...

>   T.
> 
> On 02/05/2017 12:23, Kornel Benko wrote:
> > commit c4c989b9c8d687e6f52d44fc411cf2ad14b2f8c1
> > Author: Kornel Benko 
> > Date:   Tue May 2 12:22:09 2017 +0200
> >
> > Added testcase for crash with using function word-findadv
> > ---

Kornel

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

Re: [patch] support for document class option leqno

[Guenter Milde]

Dear Uwe, dear Jean-Marc, dear LyX developers,

On 2017-05-02, Uwe Stöhr wrote:
> El 02.05.2017 a las 17:02, Jean-Marc Lasgouttes escribió:

>> 1/ understand, for the various languages and packages implementing these 
>> languages what are the cases where the default is to put the number on 
>> the left. I have identified one, there are probably others.

>> 2/ see whether LyX can have this knowledge (e.g. using a new tag in the 
>> language file).

>> 3/ when the situation is clear, I can implement on-screen visualization.

It would be an enhancement if LyX "native screen rendering" (without
instant preview) made this right for RTL languages.
We can, however, implement correct "leqno"-support without this, as ...

...
> - leqno puts the formula number ALWAYS on the left side. This is clearly 
> stated in the AMS manuals and also in the LaTeX companion 2nd edition.

I think, we can safely assume that with "leqno", there is no numbering on
the right side.

OTOH, the *default* is not always right. Left numbering is the default in
"some special classes", but also for (at least some) RTL languages.


> So I would like to keep it as it is:
> - LyX supports to switch the numbering side from the default right side 
> to the left.
> - if a user uses a special class using as default left numbering he 
> knows if overriding this makes sense or not. LyX leaves such a very 
> special case tho the user.


I can live without native "reqno" support. However, I cannot live with the
current GUI interface:

The drop-down box

  Fromula numbering  [Right]
 [Left ]

is misleading (it is "default" vs. "left"). We know its wrong for RTL
languages and some classes.

Why not:
 
  [ ] Place equation numbers left.

? (Where do we toggle equation/formula numbering and how is it called?)

Günter