Re: configure.py: convert warnings to errors for pre-release?
Scott Kostyshak wrote: > additionally whether it would > make sense to turn this option on by default when using > --enable-build-type=pre (autotools) and -DLYX_RELEASE=OFF (CMake). I don't think this is smart, imagine you bisect and have to deal with one layer of "errors" above it. Pavel
Re: configure.py: convert warnings to errors for pre-release?
Le 10/02/2018 à 23:48, Scott Kostyshak a écrit : On Sat, Feb 10, 2018 at 09:17:04PM +, Jean-Marc Lasgouttes wrote: However warnings could go to standard error, I did not check, but in a quick look we write errors with logger.error() and I assume that goes to standard error. and this could be made available somehow. What do you mean? When I wrote this, I thought about a warnings dialog. But now I think that a separate log file (configure_errors.log) might be better. It is easier to check that the file is not empty. JMarc
Re: Basque translation
Am Sonntag, 11. Februar 2018 19:53:15 CET schrieb Iñaki Larrañaga Murgoitio : > Ouch!! Sorry, I forget to attach it!! > > Here you are! > > Thanks, > > Dooteo > > > On 11 Feb 2018, at 19:32, Kornel Benko wrote: > > > > Am Sonntag, 11. Februar 2018 18:12:25 CET schrieb Iñaki Larrañaga > > Murgoitio > > > > : > >> Hi there, > >> > >> Attached to this mail, you could find Basque translation for LyX. > >> > >> Hope it’s not too late. Could you add it to LyX? > >> > >> Thanks, > >> > >> Dooteo > > > > Without attachement? Too hard to process ... > > OK, from my POV, we should add it. Before: 1440 fuzzy messages After using 'make translations': 11 fuzzy messages. Kornel
[PATCH] Re: Plan for final steps of 2.3.0 release
Le 10/02/2018 à 22:24, Jean-Marc Lasgouttes a écrit :
I can propose something simple on Monday: remove from GUI (like we do in
Linux) and always act as if the pref is off.
Here is what I had in mind. I discovered that the checkbox was not
hidden but disabled on Linux. I added code to hide it and ignore it.
This seems simple enough, but of course should be checked by Mac/Win people.
I also removed traces of it in the English User's Guide, and added some
entries in release notes. Feel free to improve on the wording.
Comments welcome.
JMarc
PS: I do not think it is worth applying this to master. We will either
end up fixing the feature or removing it altogether.
From 49c6aad0d025867aaf1adeae56bbdfa51f7616d5 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Mon, 12 Feb 2018 11:12:50 +0100
Subject: [PATCH] Disable and hide the pixmap cache feature
---
lib/RELEASE-NOTES| 6 ++
lib/doc/UserGuide.lyx| 18 --
src/frontends/qt4/GuiPainter.cpp | 2 +-
src/frontends/qt4/GuiPrefs.cpp | 2 +-
4 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES
index dccd1f1..95485d6 100644
--- a/lib/RELEASE-NOTES
+++ b/lib/RELEASE-NOTES
@@ -20,6 +20,10 @@
See chapter 3.9.1.1 "Dashes and Line Breaks" of the User Guide and
"Caveats when upgrading from earlier versions to 2.3.x" below.
+* The preference "Tools->Preferences->Look&Feel->Screen Fonts->Use
+ pixmap cache to speed up font rendering" is not available anymore.
+ It was of dubious value and led to rendering issues.
+
* The following UI translations were dropped, because the lack of translation
maintenance: Russian, Danish, Greek, Serbian, Galician, Catalan, Romanian,
Dutch.
@@ -87,6 +91,8 @@
* \screen_zoom
This is now independent of the value set via buffer-zoom[-in|-out].
+* \use_pixmap_cache
+ The value of this variable is now ignored.
!!!The following new LyX functions have been introduced in 2.3:
diff --git a/lib/doc/UserGuide.lyx b/lib/doc/UserGuide.lyx
index 06cfd1f..fb8cac9 100644
--- a/lib/doc/UserGuide.lyx
+++ b/lib/doc/UserGuide.lyx
@@ -46198,24 +46198,6 @@ reference "subsec:Document-Font"
.
\end_layout
-\begin_layout Standard
-With the option
-\family sans
-Use pixmap cache to speed up font rendering
-\family default
- enabled, \SpecialChar LyX
- needs to redraw the screen less often.
- This results in better performance, especially on slow systems.
- On the other hand, the characters might look more fuzzy on screen.
- So whether you enable this or not depends on whether you prefer speed over
- aesthetics.
- Note that the Pixmap Cache is only available and useful under Mac
-\begin_inset space ~
-\end_inset
-
-OS and Windows.
-\end_layout
-
\begin_layout Subsection
Colors
\begin_inset Index idx
diff --git a/src/frontends/qt4/GuiPainter.cpp b/src/frontends/qt4/GuiPainter.cpp
index a3cb089..e832f23 100644
--- a/src/frontends/qt4/GuiPainter.cpp
+++ b/src/frontends/qt4/GuiPainter.cpp
@@ -50,7 +50,7 @@ const int Painter::thin_line = 1;
GuiPainter::GuiPainter(QPaintDevice * device, double pixel_ratio)
: QPainter(device), Painter(pixel_ratio),
- use_pixmap_cache_(lyxrc.use_pixmap_cache && USE_PIXMAP_CACHE)
+ use_pixmap_cache_(false)
{
// new QPainter has default QPen:
current_color_ = guiApp->colorCache().get(Color_black);
diff --git a/src/frontends/qt4/GuiPrefs.cpp b/src/frontends/qt4/GuiPrefs.cpp
index 4681dd3..dc04ec5 100644
--- a/src/frontends/qt4/GuiPrefs.cpp
+++ b/src/frontends/qt4/GuiPrefs.cpp
@@ -1137,7 +1137,7 @@ void PrefScreenFonts::updateRC(LyXRC const & rc)
#if defined(Q_WS_X11) || defined(QPA_XCB)
pixmapCacheCB->setEnabled(false);
#endif
-
+ pixmapCacheCB->hide();
}
--
2.7.4
Re: Plan for final steps of 2.3.0 release
Le 10/02/2018 à 20:28, Joel Kulesza a écrit : The only comment I have is that a crash may be causable if the preference is ignored rather than disabled (see https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg203649.html). Disabling the checkbox removes the ability to reproduce. Otherwise, I have no comment on stability concerns. Hello Joel, My approach is to remove the UI element and do as if the feature was always disabled. Could you confirm that the patch I sent is OK? In particular in a setting whzere you have the feature enabled. JMarc
Re: Plan for final steps of 2.3.0 release
Le 10/02/2018 à 23:49, Scott Kostyshak a écrit : The only other regression to my knowledge that is pending is a minor issue in LyX's painting: https://www.mail-archive.com/search?l=mid&q=20180210042849.k6trww2rmruj4jrq%40steph There is a patch pending, and we just need to decide what is best to do for 2.3.0. As far as I understand it, Enrico's patch is a revertion. THis means that it probably re-introduce the bug with displaying $\not=$. For 2.3.0 I guess you and Enrico should decide which is worse, unless someone else has a strong opinion. I am sorry, I skipped the fact that Enrico's proposal changes the definition of \not and friends to hide the \not width problems. To be frank, I'd like to avoid this if we can. I propose to keep the faulty superscript for now and take some time to determine a satisfactory solution. JMarc
Re: [patch] Chapter top spacing - regression
Le 10/02/2018 à 04:04, Richard Heck a écrit : Yes, so that is the one JMarc guessed, though the real culprit is e7827264e7e. I would guess that the simple layout solution originally proposed is correct, then. This commit just removed special handling for chapters, so what's happening now is kind of what should have happened all along. +1 JMarc
Re: [PATCH] Re: Plan for final steps of 2.3.0 release
Le 12/02/2018 à 11:18, Jean-Marc Lasgouttes a écrit : Le 10/02/2018 à 22:24, Jean-Marc Lasgouttes a écrit : I can propose something simple on Monday: remove from GUI (like we do in Linux) and always act as if the pref is off. Here is what I had in mind. I discovered that the checkbox was not hidden but disabled on Linux. I added code to hide it and ignore it. This seems simple enough, but of course should be checked by Mac/Win people. Also, can someone confirm that hiding the checkbox is harmless? JMarc
Re: [LyX/2.3.x] Remove sections 6.7 and 6.4 from Additional manual (obsolete classes egs and aguplus) Edit LaTeXConfig.lyx accordingly Move teaplates/AGUTeX.lyx to teaplates/obsolete
Le 12/02/2018 à 11:32, jpc a écrit : commit 92adecb6e04024422930e7f7b60af1149d15c669 Author: jpc Date: Mon Feb 12 11:30:18 2018 +0100 Remove sections 6.7 and 6.4 from Additional manual (obsolete classes egs and aguplus) Edit LaTeXConfig.lyx accordingly Move teaplates/AGUTeX.lyx to teaplates/obsolete Richard, should this be ported to 2.2? I guess not for section 6.4, as LyX-2.2.0 was released before aguplus was obsoleted. What about section 2.7? egs is obsolete since 2001, AFAIU. -- Jean-Pierre
Re: [LyX/2.3.x] Remove sections 6.7 and 6.4 from Additional manual (obsolete classes egs and aguplus) Edit LaTeXConfig.lyx accordingly Move teaplates/AGUTeX.lyx to teaplates/obsolete
Le 12/02/2018 à 11:48, Jean-Pierre Chrétien a écrit : Le 12/02/2018 à 11:32, jpc a écrit : commit 92adecb6e04024422930e7f7b60af1149d15c669 Author: jpc Date: Mon Feb 12 11:30:18 2018 +0100 Remove sections 6.7 and 6.4 from Additional manual (obsolete classes egs and aguplus) Edit LaTeXConfig.lyx accordingly Move teaplates/AGUTeX.lyx to teaplates/obsolete Richard, should this be ported to 2.2? I guess not for section 6.4, as LyX-2.2.0 was released before aguplus was obsoleted. What about section 2.7? egs is obsolete since 2001, AFAIU. I think that 2.2.0 release date is irrelevant here, isn't it? JMarc
Re: [LyX/master] Implement buffer-anonymize more efficiently
Le 12/02/2018 à 14:38, Jean-Marc Lasgouttes a écrit :
commit 1dba36c7cec6aeec2576e7a99e2967e867076a01
Author: Jean-Marc Lasgouttes
Date: Wed Feb 7 15:35:46 2018 +0100
Implement buffer-anonymize more efficiently
The work is done now in Paragraph::anonymize().
Move the handling of the lfun to Buffer class.
Richard, this is candidate for 2.3.2 (no hurry).
JMarc
---
src/Buffer.cpp | 18 ++
src/BufferView.cpp | 10 --
src/Paragraph.cpp |9 +
src/Paragraph.h|4
4 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index f42233f..7cabe6f 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2569,15 +2569,16 @@ bool Buffer::getStatus(FuncRequest const & cmd, FuncStatus
& flag)
flag.setOnOff(params().output_changes);
break;
- case LFUN_BUFFER_TOGGLE_COMPRESSION: {
+ case LFUN_BUFFER_TOGGLE_COMPRESSION:
flag.setOnOff(params().compressed);
break;
- }
- case LFUN_BUFFER_TOGGLE_OUTPUT_SYNC: {
+ case LFUN_BUFFER_TOGGLE_OUTPUT_SYNC:
flag.setOnOff(params().output_sync);
break;
- }
+
+ case LFUN_BUFFER_ANONYMIZE:
+ break;
default:
return false;
@@ -2849,6 +2850,15 @@ void Buffer::dispatch(FuncRequest const & func,
DispatchResult & dr)
params().output_sync = !params().output_sync;
break;
+ case LFUN_BUFFER_ANONYMIZE: {
+ undo().recordUndoFullBuffer(CursorData());
+ CursorData cur(doc_iterator_begin(this));
+ for ( ; cur ; cur.forwardPar())
+ cur.paragraph().anonymize();
+ dr.forceBufferUpdate();
+ break;
+ }
+
default:
dispatched = false;
break;
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 0f4b634..7d7dc7f 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -1134,7 +1134,6 @@ bool BufferView::getStatus(FuncRequest const & cmd,
FuncStatus & flag)
case LFUN_WORD_FIND_FORWARD:
case LFUN_WORD_FIND_BACKWARD:
case LFUN_WORD_REPLACE:
- case LFUN_BUFFER_ANONYMIZE:
case LFUN_MARK_OFF:
case LFUN_MARK_ON:
case LFUN_MARK_TOGGLE:
@@ -1622,15 +1621,6 @@ void BufferView::dispatch(FuncRequest const & cmd,
DispatchResult & dr)
break;
}
- case LFUN_BUFFER_ANONYMIZE: {
- for (char c = '0'; c <= 'Z'; c++) {
- odocstringstream ss;
- ss << "a\n" << c << "\n0 0 1 1 0";
- lyx::dispatch(FuncRequest(LFUN_WORD_REPLACE, ss.str()));
- }
- break;
- }
-
case LFUN_WORD_FINDADV: {
FindAndReplaceOptions opt;
istringstream iss(to_utf8(cmd.argument()));
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 4ee612b..bc7bbee 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -4148,6 +4148,15 @@ SpellChecker::Result Paragraph::spellCheck(pos_type & from,
pos_type & to,
}
+void Paragraph::anonymize()
+{
+ // This is a very crude anonymization for now
+ for (char_type & c : d->text_)
+ if (isLetterChar(c) || isNumber(c))
+ c = 'a';
+}
+
+
void Paragraph::Private::markMisspelledWords(
pos_type const & first, pos_type const & last,
SpellChecker::Result result,
diff --git a/src/Paragraph.h b/src/Paragraph.h
index 790c3f2..84fcf75 100644
--- a/src/Paragraph.h
+++ b/src/Paragraph.h
@@ -505,6 +505,10 @@ public:
/// presently used only in the XHTML output routines.
std::string magicLabel() const;
+ /// anonymizes the paragraph contents (but not the paragraphs
+ /// contained inside it. Does not handle undo.
+ void anonymize();
+
private:
/// Expand the counters for the labelstring of \c layout
docstring expandParagraphLabel(Layout const &, BufferParams const &,
Re: Plan for final steps of 2.3.0 release
Le 11/02/2018 à 21:59, Richard Heck a écrit : On 02/10/2018 01:51 PM, Scott Kostyshak wrote: What is your feeling on how stable our 2.3.x branch currently is? I have the feeling that it is quite stable and that we should now make plans for the next step in the release process. I propose to make the final 2.3.0 release in about two weeks. What are your thoughts? Should we make a rc3 release? Should we wait longer than two weeks? I have been using 2.3.x for regular work for a few months now, because I needed some of the new features. I've had no problems with it at all. I am also in favor of going ahead with the release. As JMarc said, we can release 2.3.1 quickly if need be. Another data point: to have a chance to get LyX 2.3.0 in ubuntu 18/04 LTS, we will need it to be in debian before March 1st. I do not know how quick the debian maintainers will be to package 2.3.0 there (they have a life too ;), so it is our interest to get this thing out. For details, see end of https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1595358 JMarc
Re: Plan for final steps of 2.3.0 release
Jean-Marc Lasgouttes wrote: > Another data point: to have a chance to get LyX 2.3.0 in ubuntu 18/04 LTS, > we will need it to be in debian before March 1st. I do not know how quick > the debian maintainers will be to package 2.3.0 there (they have a life too > ;), so it is our interest to get this thing out. I'd say no chance; rc2 is only in experimental it would need to bubble through unstable (currently 2.2.3-5) to testing (2.2.3-2) first and I strongly doubt they will just push it directly to testing within week or so. You can always ask though... Pavel
Re: Plan for final steps of 2.3.0 release
Le 12/02/2018 à 16:23, Pavel Sanda a écrit : Jean-Marc Lasgouttes wrote: Another data point: to have a chance to get LyX 2.3.0 in ubuntu 18/04 LTS, we will need it to be in debian before March 1st. I do not know how quick the debian maintainers will be to package 2.3.0 there (they have a life too ;), so it is our interest to get this thing out. I'd say no chance; rc2 is only in experimental it would need to bubble through unstable (currently 2.2.3-5) to testing (2.2.3-2) first and I strongly doubt they will just push it directly to testing within week or so. You can always ask though... I kind of suspected that... Too bad. JMarc
Re: [LyX/master] Remove template AGUTeX.lyx from Makefile
Am Montag, den 12.02.2018, 17:06 +0100 schrieb Jean-Marc Lasgouttes: > commit 24fd7d2bac4db276992de1f736ad3a3ecc1647b8 > Author: Jean-Marc Lasgouttes > Date: Mon Feb 12 17:06:19 2018 +0100 > > Remove template AGUTeX.lyx from Makefile Note that there is an obsolete/ section in the Makefile. Jürgen signature.asc Description: This is a digitally signed message part
Re: Plan for final steps of 2.3.0 release
Jean-Marc Lasgouttes wrote: > Le 12/02/2018 ?? 16:23, Pavel Sanda a écrit : >> Jean-Marc Lasgouttes wrote: >>> Another data point: to have a chance to get LyX 2.3.0 in ubuntu 18/04 LTS, >>> we will need it to be in debian before March 1st. I do not know how quick >>> the debian maintainers will be to package 2.3.0 there (they have a life too >>> ;), so it is our interest to get this thing out. >> I'd say no chance; rc2 is only in experimental it would need to bubble >> through unstable (currently 2.2.3-5) to testing (2.2.3-2) first and I >> strongly doubt they will just push it directly to testing within week or so. >> You can always ask though... > > I kind of suspected that... Too bad. I quickly checked whether we know the current maintainer from the list and this log showed as one of the changes between 2.2.3-5 x 2.2.3-5: ... Revert "Use Python 3 instead of 2", introduced in 2.2.3-3. The support of Python 3 is still too fragile and results in FTBFS bugs in packages depending on lyx conversion scripts. ... I do not think that any package maintainer in his senses will ever push 2.3 directly to testing when issues like this are involved :) Pavel
Re: Plan for final steps of 2.3.0 release
Le 12/02/2018 à 17:14, Pavel Sanda a écrit : I quickly checked whether we know the current maintainer from the list and this log showed as one of the changes between 2.2.3-5 x 2.2.3-5: ... Revert "Use Python 3 instead of 2", introduced in 2.2.3-3. The support of Python 3 is still too fragile and results in FTBFS bugs in packages depending on lyx conversion scripts. ... I do not think that any package maintainer in his senses will ever push 2.3 directly to testing when issues like this are involved :) You mean that they are more careful than us ? But this patch was not ours, was it? JMarc
Re: Basque translation
Am Sonntag, den 11.02.2018, 19:53 +0100 schrieb Iñaki Larrañaga Murgoitio: > Ouch!! Sorry, I forget to attach it!! > > Here you are! Many thanks, I committed it. Note that some new strings went in meanwhile, in case you have some more spare minutes: http://www.lyx.org/trac/export/ab2bd296296b780b29ea7755ef043b2f09ae /lyxgit/po/eu.po Jürgen signature.asc Description: This is a digitally signed message part
Re: Plan for final steps of 2.3.0 release
Jean-Marc Lasgouttes wrote: > Le 12/02/2018 ?? 17:14, Pavel Sanda a écrit : >> I do not think that any package maintainer in his senses will ever push 2.3 >> directly to testing when issues like this are involved :) > > You mean that they are more careful than us ? > > But this patch was not ours, was it? I did not dig deeper, it's not my problem after all :) I only meant that they need their own time for stabilizing stuff which is likely more than 5 days... Pavel
Re: Plan for final steps of 2.3.0 release
On Mon, Feb 12, 2018 at 10:24:53AM +, Jean-Marc Lasgouttes wrote: > I propose to keep the faulty superscript for now and take some time to > determine a satisfactory solution. Fine with me. I'll update the main thread on this issue, and take this off my 2.3.0 list unless there is disagreement. Scott signature.asc Description: PGP signature
Re: integral upper limit adjacent to integral sign
On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote: > Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for > me. Enrico, JMarc proposed [1] the following: I propose to keep the faulty superscript for now and take some time to determine a satisfactory solution. Does that seem reasonable to you (for 2.3.0)? Scott [1] https://www.mail-archive.com/search?l=mid&q=99312227-9c97-da16-797b-469f2dcee655%40lyx.org signature.asc Description: PGP signature
Re: [PATCH] Re: Plan for final steps of 2.3.0 release
On Mon, Feb 12, 2018 at 10:18:16AM +, Jean-Marc Lasgouttes wrote: > This seems simple enough, but of course should be checked by Mac/Win people. +1 > I also removed traces of it in the English User's Guide, and added some > entries in release notes. Feel free to improve on the wording. Thank you, looks good. > Comments welcome. Why do you leave in the following code? #if defined(Q_WS_X11) || defined(QPA_XCB) pixmapCacheCB->setEnabled(false); #endif I'm guessing it's because you want to make as minimal changes as possible? > PS: I do not think it is worth applying this to master. We will either end > up fixing the feature or removing it altogether. +1 Scott signature.asc Description: PGP signature
Re: configure.py: convert warnings to errors for pre-release?
On Mon, Feb 12, 2018 at 08:47:04AM +, Pavel Sanda wrote: > Scott Kostyshak wrote: > > additionally whether it would > > make sense to turn this option on by default when using > > --enable-build-type=pre (autotools) and -DLYX_RELEASE=OFF (CMake). > > I don't think this is smart, imagine you bisect and have to deal > with one layer of "errors" above it. Pavel Makes sense. Thanks for taking a look. Scott signature.asc Description: PGP signature
Re: configure.py: convert warnings to errors for pre-release?
On Mon, Feb 12, 2018 at 08:57:50AM +, Jean-Marc Lasgouttes wrote: > When I wrote this, I thought about a warnings dialog. But now I think that a > separate log file (configure_errors.log) might be better. It is easier to > check that the file is not empty. Ah I see what you mean. Yeah that could work. But it is just as easy to redirect STDERR manually and check that it's not empty. I'm not sure it is worth it. Tools such as valgrind have options for this I think, but I imagine that's because the log can be so large. With configure, the STDERR output would not commonly be large (I hope). Scott signature.asc Description: PGP signature
Re: [LyX/master] Remove template AGUTeX.lyx from Makefile
Le 12/02/2018 à 17:06, Jean-Marc Lasgouttes a écrit : commit 24fd7d2bac4db276992de1f736ad3a3ecc1647b8 Author: Jean-Marc Lasgouttes Date: Mon Feb 12 17:06:19 2018 +0100 Remove template AGUTeX.lyx from Makefile Oups, I forgot this one. As AGUTeX.lyx remains in the distribution, I guess that it is premature to remove the layouts. OTOH, as it is impossible to find the jgrga.sty and agums.sty files anymore, jgrga.layout and agums.layout are useless, so they can be removed and it is not worth eventually to keep AGUTeX.lyx at all. Unless someone having kept the obsolete aguplus.cls and jgrga.sty ot agums.sty files wants to recompile an old document with lyx-2.3.0? The layout files are needed in that case. -- Jean-Pierre
Re: integral upper limit adjacent to integral sign
Le 12/02/2018 à 17:35, Scott Kostyshak a écrit :
On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote:
Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for
me.
Enrico, JMarc proposed [1] the following:
I propose to keep the faulty superscript for now and take some time to
determine a satisfactory solution.
Does that seem reasonable to you (for 2.3.0)?
FYI, my next step is to try to understand commit 03a4b8c93281 from
Guillaume.
In particular understand why the kerning is always non-negative
int mathed_char_kerning(FontInfo const & font, char_type c)
{
frontend::FontMetrics const & fm = theFontMetrics(font);
return max(0, fm.rbearing(c) - fm.width(c));
}
but still, there are computations like
min(nker(mi.base.bv), 0)
where nker( is a kerning computed as above.
The fact that Rule 17 from the TeXbook is a pain to read does not help :)
JMarc
Re: [PATCH] Re: Plan for final steps of 2.3.0 release
Le 12/02/2018 à 17:41, Scott Kostyshak a écrit : Why do you leave in the following code? #if defined(Q_WS_X11) || defined(QPA_XCB) pixmapCacheCB->setEnabled(false); #endif I'm guessing it's because you want to make as minimal changes as possible? Yes. JMarc
Re: Plan for final steps of 2.3.0 release
Am 10.02.2018 um 19:51 schrieb Scott Kostyshak: I'm planning to be more strict now on which bug fixes go in for 2.3.0. I might prefer that even a simple bug fix not be committed, unless it fixes an important bug. Hello Scott, I agree that the 2.3. branch is stable I used it recently for a larger document. The strange, random Win-only crash is annoying but we cannot do much right now. I had today a look for potential things that should go in before LyX 2.3.0 and I think https://www.lyx.org/trac/ticket/9139 is worth it. The feature of pasting from TeX had been broken under Windows for years (maybe since ever) therefore a new major version is the right point to introduce this feature also for Windows users. I distributed now all changes in the docs and despite there are still things to document I would wait unless you say I should use the time update the docs until the last hour before the release. regards Uwe
Re: integral upper limit adjacent to integral sign
On Mon, Feb 12, 2018 at 11:35:46AM -0500, Scott Kostyshak wrote: > On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote: > > > Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for > > me. > > Enrico, JMarc proposed [1] the following: > > I propose to keep the faulty superscript for now and take some time to > determine a satisfactory solution. > > Does that seem reasonable to you (for 2.3.0)? Yes, I think so. Also because this regression will put pressure on JMarc for quickly finding a solution ;) -- Enrico
Re: [LyX/2.3.x] Remove sections 6.7 and 6.4 from Additional manual (obsolete classes egs and aguplus) Edit LaTeXConfig.lyx accordingly Move teaplates/AGUTeX.lyx to teaplates/obsolete
On 02/12/2018 05:55 AM, Jean-Marc Lasgouttes wrote: > Le 12/02/2018 à 11:48, Jean-Pierre Chrétien a écrit : >> Le 12/02/2018 à 11:32, jpc a écrit : >>> commit 92adecb6e04024422930e7f7b60af1149d15c669 >>> Author: jpc >>> Date: Mon Feb 12 11:30:18 2018 +0100 >>> >>> Remove sections 6.7 and 6.4 from Additional manual >>> (obsolete classes egs and aguplus) >>> Edit LaTeXConfig.lyx accordingly >>> Move teaplates/AGUTeX.lyx to teaplates/obsolete >> >> Richard, should this be ported to 2.2? I guess not for section 6.4, >> as LyX-2.2.0 was released before aguplus was obsoleted. What about >> section 2.7? egs is obsolete since 2001, AFAIU. >> > > I think that 2.2.0 release date is irrelevant here, isn't it? Well, if the layout file is still in 2.2.x, then I guess we want to keep that section. So, Jean-Pierre: If the layout files exist in 2.2.x, then do not remove; otherwise, do remove. Richard
Re: [patch] Chapter top spacing - regression
Jean-Marc Lasgouttes wrote: > Le 10/02/2018 ?? 04:04, Richard Heck a écrit : >> Yes, so that is the one JMarc guessed, though the real culprit is >> e7827264e7e. >> I would guess that the simple layout solution originally proposed is >> correct, then. This commit just removed special handling for chapters, >> so what's happening now is kind of what should have happened all along. > > +1 Fixed at 149f03d403. Scott, 2.3.0 or 2.3.1? Pavel
Re: Basque translation
I??aki Larra??aga Murgoitio wrote: > Hi Jürgen, and LyX devel team, > > Basque translation updated at %100 as requested :-) Not so fast! :) There is one more check we need from you - I just committed changes to lib/layouttranslations (output of some strings to pdf) (https://www.lyx.org/trac/changeset/2554a7dffb2890f4b851c60c41cfee116c56baf6/lyxgit) Please can check whether eu section of this file whether your new changes and also couple new strings(*) is as expected for pdf output? Pavel (*): "Property" "Solution" "Listing" "Listings" "List of Listings" "see equation[[nomencl]]" "page[[nomencl]]"
LyX translations in sv.po
Hi Jim,
I just committed changes to lib/layouttranslations
(https://www.lyx.org/trac/changeset/2554a7dffb2890f4b851c60c41cfee116c56baf6/lyxgit)
from your recent update of sv.po.
Can you please double check for us whether the translation of new strings in
pdf output ("List of Listings","see equation","page") is as intended?
Thanks,
Pavel
LyX translations for pdf output
Hi Yuriy, your recent changes in ru.po also included few changes for strings in pdf output (https://www.lyx.org/trac/changeset/2554a7dffb2890f4b851c60c41cfee116c56baf6/lyxgit) Can you double check that it is as intended? Thanks, Pavel
Re: [patch] Chapter top spacing - regression
On 02/12/2018 03:17 PM, Pavel Sanda wrote: > Jean-Marc Lasgouttes wrote: >> Le 10/02/2018 ?? 04:04, Richard Heck a écrit : >>> Yes, so that is the one JMarc guessed, though the real culprit is >>> e7827264e7e. >>> I would guess that the simple layout solution originally proposed is >>> correct, then. This commit just removed special handling for chapters, >>> so what's happening now is kind of what should have happened all along. >> +1 > Fixed at 149f03d403. > > Scott, 2.3.0 or 2.3.1? FWIW, I'd suggest 2.3.0. It's totally cosmetic and safe, but annoying for people with small screens. Richard
Re: [LyX/master] Fix crash when citeengine is unknown.
On 02/12/2018 04:27 PM, Richard Heck wrote: > commit 5ee3396459602e0982234cab064c5c960af7e4fc > Author: Richard Heck > Date: Mon Feb 12 16:26:27 2018 -0500 > > Fix crash when citeengine is unknown. Scott, this is also needed in 2.3.x. Trivial and completely safe crash-fix. Richard > --- > src/frontends/qt4/GuiDocument.cpp |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/src/frontends/qt4/GuiDocument.cpp > b/src/frontends/qt4/GuiDocument.cpp > index 85318bc..8149b50 100644 > --- a/src/frontends/qt4/GuiDocument.cpp > +++ b/src/frontends/qt4/GuiDocument.cpp > @@ -4007,6 +4007,12 @@ bool GuiDocument::isBiblatex() const > biblioModule->citeEngineCO->itemData( > > biblioModule->citeEngineCO->currentIndex()).toString(); > > + // this can happen if the cite engine is unknown, which can happen > + // if one is using a file that came from someone else, etc. in that > + // case, we crash if we proceed. > + if (engine.isEmpty()) > + return false; > + > return theCiteEnginesList[fromqstr(engine)]->getCiteFramework() == > "biblatex"; > } >
Re: [LyX/master] Fix crash when citeengine is unknown.
On Mon, Feb 12, 2018 at 09:31:03PM +, Richard Heck wrote: > On 02/12/2018 04:27 PM, Richard Heck wrote: > > commit 5ee3396459602e0982234cab064c5c960af7e4fc > > Author: Richard Heck > > Date: Mon Feb 12 16:26:27 2018 -0500 > > > > Fix crash when citeengine is unknown. > > Scott, this is also needed in 2.3.x. Trivial and completely safe crash-fix. Go ahead for 2.3.0. Thanks. Scott signature.asc Description: PGP signature
Re: [patch] Chapter top spacing - regression
On Mon, Feb 12, 2018 at 09:27:49PM +, Richard Heck wrote: > On 02/12/2018 03:17 PM, Pavel Sanda wrote: > > Scott, 2.3.0 or 2.3.1? > > FWIW, I'd suggest 2.3.0. It's totally cosmetic and safe, but annoying > for people with small screens. Go ahead for 2.3.0. Scott signature.asc Description: PGP signature
Re: integral upper limit adjacent to integral sign
On Mon, Feb 12, 2018 at 06:53:36PM +, Enrico Forestieri wrote: > On Mon, Feb 12, 2018 at 11:35:46AM -0500, Scott Kostyshak wrote: > > On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote: > > > > > Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for > > > me. > > > > Enrico, JMarc proposed [1] the following: > > > > I propose to keep the faulty superscript for now and take some time to > > determine a satisfactory solution. > > > > Does that seem reasonable to you (for 2.3.0)? > > Yes, I think so. Also because this regression will put pressure on > JMarc for quickly finding a solution ;) Thanks, sounds good. Scott signature.asc Description: PGP signature
Re: [patch] Chapter top spacing - regression
Scott Kostyshak wrote: > On Mon, Feb 12, 2018 at 09:27:49PM +, Richard Heck wrote: > > On 02/12/2018 03:17 PM, Pavel Sanda wrote: > > > > Scott, 2.3.0 or 2.3.1? > > > > FWIW, I'd suggest 2.3.0. It's totally cosmetic and safe, but annoying > > for people with small screens. > > Go ahead for 2.3.0. there there.p
Re: Plan for final steps of 2.3.0 release
On Mon, Feb 12, 2018 at 06:00:52PM +, Uwe Stöhr wrote: > Am 10.02.2018 um 19:51 schrieb Scott Kostyshak: > > > I'm planning to be more strict now on which bug fixes go in for 2.3.0. I > > might prefer that even a simple bug fix not be committed, unless it > > fixes an important bug. > > Hello Scott, > > I agree that the 2.3. branch is stable I used it recently for a larger > document. The strange, random Win-only crash is annoying but we cannot do > much right now. Just to make sure, the crash you're talking about also exists for 2.2.x, right? > I had today a look for potential things that should go in before LyX 2.3.0 > and I think > https://www.lyx.org/trac/ticket/9139 > is worth it. > The feature of pasting from TeX had been broken under Windows for years > (maybe since ever) therefore a new major version is the right point to > introduce this feature also for Windows users. I don't see the advantage of doing this at a major version. Even if there is an advantage, I don't think that so soon before the final release is the right time for this non-trivial patch. From what I understand, this temporary file name stuff is tricky. I know you've tested the patch and it works for you, but I'm worried there could be hidden problems. > I distributed now all changes in the docs and despite there are still things > to document I would wait unless you say I should use the time update the > docs until the last hour before the release. I think waiting makes sense. Thanks, Scott signature.asc Description: PGP signature
Re: Plan for final steps of 2.3.0 release
Am 13.02.2018 um 00:19 schrieb Scott Kostyshak: I agree that the 2.3. branch is stable I used it recently for a larger document. The strange, random Win-only crash is annoying but we cannot do much right now. Just to make sure, the crash you're talking about also exists for 2.2.x, right? Yes, but there the bug appears less often. This is of course just a feeling since it is a random crash. However, it only appears when working with documents containing Latin and non-Latin content. For pure e.g. Cyrillic content it does not occur. So only people like me might see it, not the average user. https://www.lyx.org/trac/ticket/9139 I don't see the advantage of doing this at a major version. Even if there is an advantage, I don't think that so soon before the final release is the right time for this non-trivial patch. From what I understand, this temporary file name stuff is tricky. I know you've tested the patch and it works for you, but I'm worried there could be hidden problems. In my opinion a major version should contain all major bugfixes. Here we have a menu entry for a feature that doesn't work. This is no good advertisement for LyX. We have a working fix that is well tested on Windows. If we know that it works also well on MacOS I think it is safe. Jürgen, please correct me if I am wrong. regards Uwe
Re: Plan for final steps of 2.3.0 release
On Mon, Feb 12, 2018 at 3:20 AM, Jean-Marc Lasgouttes
wrote:
> Le 10/02/2018 à 20:28, Joel Kulesza a écrit :
>
>> The only comment I have is that a crash may be causable if the preference
>> is ignored rather than disabled (see https://www.mail-archive.com/l
>> yx-de...@lists.lyx.org/msg203649.html). Disabling the checkbox removes
>> the ability to reproduce.
>>
>> Otherwise, I have no comment on stability concerns.
>>
>
> Hello Joel,
>
> My approach is to remove the UI element and do as if the feature was
> always disabled. Could you confirm that the patch I sent is OK? In
> particular in a setting whzere you have the feature enabled.
>
JMarc,
I applied your patch to master@5f1b32f8c (note: it didn't apply cleanly,
see below my signature). Regardless, it hid the checkbox and associated
label properly and the LyX interface behaved as though the setting is
disabled (i.e., math was rendered properly). I also inserted the line
enabling the preference in my .../preferences file, and that did not appear
to cause a problem.
>From my standpoint, this patch works as intended.
Thanks,
Joel
--
[Git(jmarc_patch)]
8935 jkulesza@tempest[~/GIT/lyx]> g apply
0001-Disable-and-hide-the-pixmap-cache-feature.patch
error: patch failed: lib/RELEASE-NOTES:20
error: lib/RELEASE-NOTES: patch does not apply
error: patch failed: src/frontends/qt4/GuiPainter.cpp:50
error: src/frontends/qt4/GuiPainter.cpp: patch does not apply
--
[Git(jmarc_patch)]
8937 jkulesza@tempest[~/GIT/lyx]> g apply --reject
0001-Disable-and-hide-the-pixmap-cache-feature.patch
Checking patch lib/RELEASE-NOTES...
error: while searching for:
See chapter 3.9.1.1 "Dashes and Line Breaks" of the User Guide and
"Caveats when upgrading from earlier versions to 2.3.x" below.
* The following UI translations were dropped, because the lack of
translation
maintenance: Russian, Danish, Greek, Serbian, Galician, Catalan,
Romanian,
Dutch.
error: patch failed: lib/RELEASE-NOTES:20
error: while searching for:
* \screen_zoom
This is now independent of the value set via buffer-zoom[-in|-out].
!!!The following new LyX functions have been introduced in 2.3:
error: patch failed: lib/RELEASE-NOTES:87
Checking patch lib/doc/UserGuide.lyx...
Checking patch src/frontends/qt4/GuiPainter.cpp...
error: while searching for:
GuiPainter::GuiPainter(QPaintDevice * device, double pixel_ratio)
: QPainter(device), Painter(pixel_ratio),
use_pixmap_cache_(lyxrc.use_pixmap_cache && USE_PIXMAP_CACHE)
{
// new QPainter has default QPen:
current_color_ = guiApp->colorCache().get(Color_black);
error: patch failed: src/frontends/qt4/GuiPainter.cpp:50
Checking patch src/frontends/qt4/GuiPrefs.cpp...
Applying patch lib/RELEASE-NOTES with 2 rejects...
Rejected hunk #1.
Rejected hunk #2.
Applied patch lib/doc/UserGuide.lyx cleanly.
Applying patch src/frontends/qt4/GuiPainter.cpp with 1 reject...
Rejected hunk #1.
Applied patch src/frontends/qt4/GuiPrefs.cpp cleanly.
Re: Plan for final steps of 2.3.0 release
On 02/12/2018 07:54 PM, Uwe Stöhr wrote: > Am 13.02.2018 um 00:19 schrieb Scott Kostyshak: >>> https://www.lyx.org/trac/ticket/9139 >> >> I don't see the advantage of doing this at a major version. Even if >> there is an advantage, I don't think that so soon before the final >> release is the right time for this non-trivial patch. From what I >> understand, this temporary file name stuff is tricky. I know you've >> tested the patch and it works for you, but I'm worried there could be >> hidden problems. > > In my opinion a major version should contain all major bugfixes. Here > we have a menu entry for a feature that doesn't work. This is no good > advertisement for LyX. It hasn't worked for quite a while, apparently. > We have a working fix that is well tested on Windows. If we know that > it works also well on MacOS I think it is safe. Jürgen, please correct > me if I am wrong. We're likely to have a fairly quick 2.3.1 release. How quick will depend upon the feedback, but there are a number of things lined up already for 2.3.x, so it'll be a couple months at most. Richard
Re: Plan for final steps of 2.3.0 release
Am Dienstag, den 13.02.2018, 01:54 +0100 schrieb Uwe Stöhr: > In my opinion a major version should contain all major bugfixes. Here > we > have a menu entry for a feature that doesn't work. This is no good > advertisement for LyX. > We have a working fix that is well tested on Windows. If we know that > it > works also well on MacOS I think it is safe. Jürgen, please correct > me > if I am wrong. I would be more easy if we could test the fix a bit, so I'd prefer 2.3.1. (push it immediately after 2.3.0 is out). Jürgen > > regards Uwe signature.asc Description: This is a digitally signed message part
