Re: Gnuplot format & converter script
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?
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)
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
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
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)
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
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
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
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
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 /BUILD/BUILDMint17/BuildLyxGitQt5.7main-gcc7.1/autotests/out-home/AbC_73xRo
Re: 2.3.0alpha1-1 round 2
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
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
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)
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
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
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?
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
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
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
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_>',
str='x^_x_<(a)_x_>+\frac
Re: [LyX/master] findadv: hide word-findadv verb from the mini-buffer
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"
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
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
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
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?
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
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?
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?
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?
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?
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?
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
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&q=20161014155132.wo3authr3zkbe7hy%40steph signature.asc Description: PGP signature
Re: LyX 2.3.0alpha1-1
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
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
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/192/
Re: [patch] support for document class option leqno
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
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?
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
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
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
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
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
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
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
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.
