Re: Hyperref-preview conflict
On 4/11/2020 9:07 am, Yu Jin wrote: Am Di., 3. Nov. 2020 um 20:33 Uhr schrieb Andrew Parsloe mailto:ajpars...@gmail.com>>: On 4/11/2020 7:03 am, Yu Jin wrote: Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe mailto:ajpars...@gmail.com>>: LyX 2.4.0 testing, windows 10 Checking Use Hyperref Support stalls display of previews on my system. I've attached two simple documents showing the effect. In 2.3.5.2 the formation of previews is not stalled, but it is slowed. My (no doubt naive ) notion is that hyperref and preview should have nothing to do with each other. Looking at what's going on in the Temp directory, with hyperref ON a pdf is formed of all previews in the document. After a while in 2.3.5.2 the individual png-s are then formed of each preview and which then get displayed. In 2.4.0 the pdf of all previews is formed but not the individual png-s. In both cases the log shows entries like Preview: Snippet 1 44 225995 2313809 [1 Non-PDF special ignored! ps::clippath fill for each preview. With hyperref OFF no pdf is formed and each preview generates a log entry like Preview: Snippet 1 4634698 235932 22609920 Can you try following: Tolls -> Preferences -> Paths -> PATH prefix: find $LyXDir\ghostscript and change to $LyXDir\ghostscript\bin report if the outcome. Yes, the preview now forms (in 2.4.0 testing), although it still takes the 'long' route of creating a pdf in the Temp directory before creating the png. The preview log shows Strange, I have tested your both files and for me it creates not .pdf but .dvi files in both cases, I see no difference between the two files. What do you mean with the long route, what would be the short route? Hyperref off behaves differently for you? How? Preview: Snippet 1 44 225995 2313809 [1 Non-PDF special ignored! ps::clippath fill -- Eugene I've attached the contents of the temp directory in the two cases. A pdf is formed in the hyperref ON case, but not in the OFF case. The hyperrefON.lyx file has the entries \use_hyperref true \pdf_bookmarks true; the hyperrefOFF.lyx file has the entry \use_hyperref false. By the long route I meant that a pdf of the preview snippet is formed before the png. The short route doesn't involve forming the pdf (goes directly from dvi to png). Would the preview log files be of interest? Andrew -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Hyperref-preview conflict
Am Di., 3. Nov. 2020 um 20:33 Uhr schrieb Andrew Parsloe < ajpars...@gmail.com>: > > On 4/11/2020 7:03 am, Yu Jin wrote: > > Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe < > ajpars...@gmail.com>: > >> LyX 2.4.0 testing, windows 10 >> >> Checking Use Hyperref Support stalls display of previews on my system. >> I've attached two simple documents showing the effect. In 2.3.5.2 the >> formation of previews is not stalled, but it is slowed. My (no doubt >> naive ) notion is that hyperref and preview should have nothing to do >> with each other. >> >> Looking at what's going on in the Temp directory, with hyperref ON a pdf >> is formed of all previews in the document. After a while in 2.3.5.2 the >> individual png-s are then formed of each preview and which then get >> displayed. In 2.4.0 the pdf of all previews is formed but not the >> individual png-s. In both cases the log shows entries like >> >> Preview: Snippet 1 44 225995 2313809 >> [1 >> Non-PDF special ignored! >> ps::clippath fill >> >> for each preview. With hyperref OFF no pdf is formed and each preview >> generates a log entry like >> >> Preview: Snippet 1 4634698 235932 22609920 >> > > Can you try following: > Tolls -> Preferences -> Paths -> PATH prefix: find > $LyXDir\ghostscript and change to > $LyXDir\ghostscript\bin > > report if the outcome. > > Yes, the preview now forms (in 2.4.0 testing), although it still takes the > 'long' route of creating a pdf in the Temp directory before creating the > png. The preview log shows > Strange, I have tested your both files and for me it creates not .pdf but .dvi files in both cases, I see no difference between the two files. What do you mean with the long route, what would be the short route? Hyperref off behaves differently for you? How? > Preview: Snippet 1 44 225995 2313809 > [1 > Non-PDF special ignored! > ps::clippath fill > -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Hyperref-preview conflict
On 4/11/2020 7:03 am, Yu Jin wrote: Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe mailto:ajpars...@gmail.com>>: LyX 2.4.0 testing, windows 10 Checking Use Hyperref Support stalls display of previews on my system. I've attached two simple documents showing the effect. In 2.3.5.2 the formation of previews is not stalled, but it is slowed. My (no doubt naive ) notion is that hyperref and preview should have nothing to do with each other. Looking at what's going on in the Temp directory, with hyperref ON a pdf is formed of all previews in the document. After a while in 2.3.5.2 the individual png-s are then formed of each preview and which then get displayed. In 2.4.0 the pdf of all previews is formed but not the individual png-s. In both cases the log shows entries like Preview: Snippet 1 44 225995 2313809 [1 Non-PDF special ignored! ps::clippath fill for each preview. With hyperref OFF no pdf is formed and each preview generates a log entry like Preview: Snippet 1 4634698 235932 22609920 Can you try following: Tolls -> Preferences -> Paths -> PATH prefix: find $LyXDir\ghostscript and change to $LyXDir\ghostscript\bin report if the outcome. -- Eugene Yes, the preview now forms (in 2.4.0 testing), although it still takes the 'long' route of creating a pdf in the Temp directory before creating the png. The preview log shows Preview: Snippet 1 44 225995 2313809 [1 Non-PDF special ignored! ps::clippath fill Andrew -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Hyperref-preview conflict
Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe < ajpars...@gmail.com>: > LyX 2.4.0 testing, windows 10 > > Checking Use Hyperref Support stalls display of previews on my system. > I've attached two simple documents showing the effect. In 2.3.5.2 the > formation of previews is not stalled, but it is slowed. My (no doubt > naive ) notion is that hyperref and preview should have nothing to do > with each other. > > Looking at what's going on in the Temp directory, with hyperref ON a pdf > is formed of all previews in the document. After a while in 2.3.5.2 the > individual png-s are then formed of each preview and which then get > displayed. In 2.4.0 the pdf of all previews is formed but not the > individual png-s. In both cases the log shows entries like > > Preview: Snippet 1 44 225995 2313809 > [1 > Non-PDF special ignored! > ps::clippath fill > > for each preview. With hyperref OFF no pdf is formed and each preview > generates a log entry like > > Preview: Snippet 1 4634698 235932 22609920 > Can you try following: Tolls -> Preferences -> Paths -> PATH prefix: find $LyXDir\ghostscript and change to $LyXDir\ghostscript\bin report if the outcome. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches
On 11/2/20 7:05 PM, Jean-Marc Lasgouttes wrote:
> Le 02/11/2020 à 22:56, Richard Kimberly Heck a écrit :
>> I have been thinking just a bit about this and wonder how plausible
>> it is to separate out those elements of the Counter class that are
>> per-Buffer (or, at least, document set) and those that are not.
>> Basically: ALL of the members of Counter are per-Buffer. The ones
>> associated with values obviously are. But so are e.g. labelstring_
>> and prettyformat_, since these can be over-ridden by local layouts,
>> modules, etc. So I'm not sure there will be anything left if we
>> factor out the non-per-Buffer stuff.
>
> It is not a matter of per-bufferbut of separating layout from value.
> This means that we could avoid copying the whole counters definitions
> in InsetText::updateBuffer and whatever strange xhtml thing you have
> been doing. Basically every inset or paragraph could cache its counter
> values in a reasonably compact way. I am sure we can find uses for that.
Here's a slightly different idea. Not tested yet.
Riki
>From 1773caeefc5523a10bde2615ab6060134759514e Mon Sep 17 00:00:00 2001
From: Richard Kimberly Heck
Date: Tue, 3 Nov 2020 12:45:47 -0500
Subject: [PATCH] Idea to save and restore counters without copying them all
---
src/Counters.cpp | 40 ++--
src/Counters.h | 18 +-
src/insets/InsetText.cpp | 12 +++-
3 files changed, 58 insertions(+), 12 deletions(-)
diff --git a/src/Counters.cpp b/src/Counters.cpp
index 8477d5283a..7613d4a74e 100644
--- a/src/Counters.cpp
+++ b/src/Counters.cpp
@@ -164,6 +164,20 @@ void Counter::restoreValue()
}
+void Counter::rememberState() const
+{
+ state_memory_.push({value_, saved_value_});
+}
+
+
+void Counter::restoreState()
+{
+ value_ = state_memory_.top().first;
+ saved_value_ = state_memory_.top().second;
+ state_memory_.pop();
+}
+
+
void Counter::step()
{
++value_;
@@ -315,6 +329,22 @@ void Counters::restoreValue(docstring const & ctr) const
}
+void Counters::saveCounterState()
+{
+ for (auto & c : counterList_)
+ c.second.rememberState();
+ clearLastLayout();
+}
+
+
+void Counters::restoreCounterState()
+{
+ for (auto & c : counterList_)
+ c.second.restoreState();
+ restoreLastLayout();
+}
+
+
void Counters::resetChildren(docstring const & count)
{
for (auto & ctr : counterList_) {
@@ -379,8 +409,7 @@ void Counters::reset()
appendix_ = false;
subfloat_ = false;
current_float_.erase();
- for (auto & ctr : counterList_)
- ctr.second.reset();
+ resetCounterValues();
counter_stack_.clear();
counter_stack_.push_back(from_ascii(""));
layout_stack_.clear();
@@ -399,6 +428,13 @@ void Counters::reset(docstring const & match)
}
+void Counters::resetCounterValues()
+{
+ for (auto & ctr : counterList_)
+ ctr.second.reset();
+}
+
+
bool Counters::remove(docstring const & cnt)
{
bool retval = counterList_.erase(cnt);
diff --git a/src/Counters.h b/src/Counters.h
index 4708f5a331..aa6efd431b 100644
--- a/src/Counters.h
+++ b/src/Counters.h
@@ -20,6 +20,7 @@
#include "support/docstring.h"
#include
+#include
#include
@@ -44,10 +45,17 @@ public:
void addto(int v);
///
int value() const;
- ///
+ /// This should be called when one just wants to save the value of this
+ /// counter for later restoration, via restoreValue.
void saveValue();
///
void restoreValue();
+ /// This should be called if one wants to remember the complete state of
+ /// this counter (value and saved value), e.g., when doing updateBuffer for
+ /// an inset that does not produce output.
+ void rememberState() const;
+ ///
+ void restoreState();
///
void step();
///
@@ -107,6 +115,8 @@ private:
/// Cache of the appendix labelstring with \\the expressions expanded,
/// indexed by language
mutable StringMap flatlabelstringappendix_;
+ ///
+ mutable std::stack > state_memory_;
};
@@ -143,6 +153,10 @@ public:
void saveValue(docstring const & ctr) const;
///
void restoreValue(docstring const & ctr) const;
+ ///
+ void saveCounterState();
+ ///
+ void restoreCounterState();
/// Reset recursively all the counters that are children of the one named by \c ctr.
void resetChildren(docstring const & ctr);
/// Increment by one the parent of counter named by \c ctr.
@@ -158,6 +172,8 @@ public:
void reset();
/// Reset counters matched by match string.
void reset(docstring const & match);
+ ///
+ void resetCounterValues();
/// Remove counter \p cnt.
bool remove(docstring const & cnt);
/// Copy counters whose name matches match from the to
diff --git a/src/insets/InsetText.cpp b/src/insets/InsetText.cpp
index f72b9a6396..ae11dcb1d0 100644
--- a/src/insets/InsetText.cpp
+++ b/src/insets/InsetText.cpp
@@ -885,16 +885,10 @@ void InsetText::updateBuffer(ParIterator const & it, UpdateType utype, bool cons
}
} else {
DocumentClass const & tclass = buffer().masterBuffer()->params().documentClass();
- // Note that we
Re: Continuous Spellchecker Default Behavior (and Voting?)
On Tue, Nov 03, 2020 at 07:14:48AM -0700, Joel Kulesza wrote: > On Mon, Nov 2, 2020 at 11:06 PM Stephan Witt wrote: > > > Am 02.11.2020 um 19:10 schrieb Joel Kulesza : > > > > > > On Sun, Nov 1, 2020 at 4:19 PM Richard Kimberly Heck > > wrote: > > > On 11/1/20 4:54 PM, Richard Kimberly Heck wrote: > > > > > > Attached is the patch. > > > > > > Riki > > > > > > I seem to never be able to successfully apply patches. This is no > > exception (I'm on master at e8a28c33c), so I cannot test it (complaints > > follow my signature for those interested). Regardless, after reading > > through the changes, they all seem reasonable. Thank you, Riki, for taking > > this upon yourself! I hope that we can move forward from here. Please let > > me know what I can do to help. > > > > > > Thank you again, > > > Joel > > > > Perhaps it is a difference in CR/LF of patch and work area? > > > > The patch has Unix line endings. > > > > Stephan > > > > See here: > > https://stackoverflow.com/questions/6308625/how-to-avoid-git-apply-changing-line-endings > > > That doesn't seem to be it (note: I'm on macOS, so I expect Unix line > endings to be OK). > > I've tried `unix2dos`, `dos2unix`, and --whitespace=fix on the git apply, > and they all fail. Have you tried with "git am"? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
String Freeze for 2.3.6 Wednesday
Hi, all, I intend to write translators regarding 2.3.6 on Wednesday, so if there's anything that needs to go into 2.3.x before then... Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
On Tue, Nov 03, 2020 at 04:30:38PM +0100, Jean-Marc Lasgouttes wrote: > Le 03/11/2020 ?? 16:16, Pavel Sanda a écrit : > >>checking for a good C++ mode... none > >>configure: error: Cannot find suitable mode for compiler g++ > >>make: *** [Makefile:502: config.status] Error 1 > > > >looking at the log I see: > >g++: error: unrecognized command line option '-std=gnu++14,11' > >Seems like wrong argument? > > Embarrassing last minute change. Better now? Yes, fixed. Thanks, Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
Le 03/11/2020 à 16:16, Pavel Sanda a écrit : checking for a good C++ mode... none configure: error: Cannot find suitable mode for compiler g++ make: *** [Makefile:502: config.status] Error 1 looking at the log I see: g++: error: unrecognized command line option '-std=gnu++14,11' Seems like wrong argument? Embarrassing last minute change. Better now? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
Le 03/11/2020 à 16:16, Pavel Sanda a écrit :
On Tue, Nov 03, 2020 at 04:12:16PM +0100, Pavel Sanda wrote:
On Tue, Nov 03, 2020 at 02:44:43PM +0100, Jean-Marc Lasgouttes wrote:
commit ce526607ff4ae33834dabe64e0072530eca16183
Author: Jean-Marc Lasgouttes
Date: Mon Nov 2 17:40:29 2020 +0100
Make it possible to select C++ standard with autoconf
Introduce new configure option --enable-cxx-mode=MODE, which allows to
force a C++ version. The default is {14,11}, which means that C++14 is
chosen if it is supported, and C++11 will be selected as a fallback.
Using --enable-cxx-mode=11 ensures that LyX compiles correctly
with an older C++11 compiler.
Is this supposed to work by default on old compilers or do I need to
pass cxx-mode now?
checking for a good C++ mode... none
configure: error: Cannot find suitable mode for compiler g++
make: *** [Makefile:502: config.status] Error 1
looking at the log I see:
g++: error: unrecognized command line option '-std=gnu++14,11'
Seems like wrong argument?
Definitely. I'll look at it asap.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
Le 03/11/2020 à 16:12, Pavel Sanda a écrit : Is this supposed to work by default on old compilers or do I need to pass cxx-mode now? It is supposed to work magically. checking for a good C++ mode... none configure: error: Cannot find suitable mode for compiler g++ make: *** [Makefile:502: config.status] Error 1 Can I see your config.log file? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
Le 03/11/2020 à 15:54, José Abílio Matos a écrit : As you probably know the default for gcc 11 will be C++17. Is this taking that into account? Yes. We enforce C++14 in this case. This is bound to change with time, of course. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
On Tue, Nov 03, 2020 at 04:12:16PM +0100, Pavel Sanda wrote:
> On Tue, Nov 03, 2020 at 02:44:43PM +0100, Jean-Marc Lasgouttes wrote:
> > commit ce526607ff4ae33834dabe64e0072530eca16183
> > Author: Jean-Marc Lasgouttes
> > Date: Mon Nov 2 17:40:29 2020 +0100
> >
> > Make it possible to select C++ standard with autoconf
> >
> > Introduce new configure option --enable-cxx-mode=MODE, which allows to
> > force a C++ version. The default is {14,11}, which means that C++14 is
> > chosen if it is supported, and C++11 will be selected as a fallback.
> >
> > Using --enable-cxx-mode=11 ensures that LyX compiles correctly
> > with an older C++11 compiler.
>
> Is this supposed to work by default on old compilers or do I need to
> pass cxx-mode now?
>
> checking for a good C++ mode... none
> configure: error: Cannot find suitable mode for compiler g++
> make: *** [Makefile:502: config.status] Error 1
looking at the log I see:
g++: error: unrecognized command line option '-std=gnu++14,11'
Seems like wrong argument?
> Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
On Tue, Nov 03, 2020 at 02:44:43PM +0100, Jean-Marc Lasgouttes wrote:
> commit ce526607ff4ae33834dabe64e0072530eca16183
> Author: Jean-Marc Lasgouttes
> Date: Mon Nov 2 17:40:29 2020 +0100
>
> Make it possible to select C++ standard with autoconf
>
> Introduce new configure option --enable-cxx-mode=MODE, which allows to
> force a C++ version. The default is {14,11}, which means that C++14 is
> chosen if it is supported, and C++11 will be selected as a fallback.
>
> Using --enable-cxx-mode=11 ensures that LyX compiles correctly
> with an older C++11 compiler.
Is this supposed to work by default on old compilers or do I need to
pass cxx-mode now?
checking for a good C++ mode... none
configure: error: Cannot find suitable mode for compiler g++
make: *** [Makefile:502: config.status] Error 1
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make it possible to select C++ standard with autoconf
On Tuesday, November 3, 2020 1:44:43 PM WET Jean-Marc Lasgouttes wrote:
> commit ce526607ff4ae33834dabe64e0072530eca16183
> Author: Jean-Marc Lasgouttes
> Date: Mon Nov 2 17:40:29 2020 +0100
>
> Make it possible to select C++ standard with autoconf
>
> Introduce new configure option --enable-cxx-mode=MODE, which allows to
> force a C++ version. The default is {14,11}, which means that C++14 is
> chosen if it is supported, and C++11 will be selected as a fallback.
>
> Using --enable-cxx-mode=11 ensures that LyX compiles correctly
> with an older C++11 compiler.
As you probably know the default for gcc 11 will be C++17. Is this taking that
into account?
I am just curious. :-)
Best regards,
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Continuous Spellchecker Default Behavior (and Voting?)
On Mon, Nov 2, 2020 at 11:06 PM Stephan Witt wrote: > Am 02.11.2020 um 19:10 schrieb Joel Kulesza : > > > > On Sun, Nov 1, 2020 at 4:19 PM Richard Kimberly Heck > wrote: > > On 11/1/20 4:54 PM, Richard Kimberly Heck wrote: > > > > Attached is the patch. > > > > Riki > > > > I seem to never be able to successfully apply patches. This is no > exception (I'm on master at e8a28c33c), so I cannot test it (complaints > follow my signature for those interested). Regardless, after reading > through the changes, they all seem reasonable. Thank you, Riki, for taking > this upon yourself! I hope that we can move forward from here. Please let > me know what I can do to help. > > > > Thank you again, > > Joel > > Perhaps it is a difference in CR/LF of patch and work area? > > The patch has Unix line endings. > > Stephan > > See here: > https://stackoverflow.com/questions/6308625/how-to-avoid-git-apply-changing-line-endings That doesn't seem to be it (note: I'm on macOS, so I expect Unix line endings to be OK). I've tried `unix2dos`, `dos2unix`, and --whitespace=fix on the git apply, and they all fail. Thanks, Joel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
