On Thu, Jun 15, 2023 at 08:07:33AM +0200, Daniel wrote:
>
> On 2023-06-14 12:33, Scott Kostyshak wrote:
> > On Wed, Jun 14, 2023 at 07:15:27AM +0200, Daniel wrote:
> > >
> > > Dear developers,
> > >
> > > I have decided to try to make fewer
On 2023-06-14 12:33, Scott Kostyshak wrote:
On Wed, Jun 14, 2023 at 07:15:27AM +0200, Daniel wrote:
Dear developers,
I have decided to try to make fewer (if any) patches and rather only suggest
improvements at least for now.
This is driven by a number of personal factors. But also that I
On Wed, Jun 14, 2023 at 07:15:27AM +0200, Daniel wrote:
>
> Dear developers,
>
> I have decided to try to make fewer (if any) patches and rather only suggest
> improvements at least for now.
>
> This is driven by a number of personal factors. But also that I have made
>
Dear developers,
I have decided to try to make fewer (if any) patches and rather only
suggest improvements at least for now.
This is driven by a number of personal factors. But also that I have
made the experience that most of the patches most important to me depend
highly on whether some
On Mon, 1 Feb 2021 at 15:31, José Abílio Matos wrote:
> On Monday, February 1, 2021 2:42:43 AM WET Thibaut Cuvelier wrote:
>
> > More generally, what about the other patches? Are formatting changes
>
> > considered risky? What about Joel's suggestions?
>
> My issue
On Monday, February 1, 2021 2:42:43 AM WET Thibaut Cuvelier wrote:
> More generally, what about the other patches? Are formatting changes
> considered risky? What about Joel's suggestions?
My issue is not about the formatting changes, I can live with them even if in
some cases I
ell. Thanks!
...
checking for a java interpreter...
+checking for "java"... not in path
+checking for java: found in Windows registry, C:\Program Files (x86)\Java\jre1.
8.0_281\bin\java.exe
...
> More generally, what about the other patches? Are formatting changes
> considered r
? I first look for
> a
> > > > 64-bit version before a 32-bit, just to favour newer things, but
> there is
> > > > no other reason to do so.
> > >
> > > The patch does not apply neither to current master nor to current
> stable
> > > (most probably it depends on previous
r reason to do so.
> >
> > The patch does not apply neither to current master nor to current stable
> > (most probably it depends on previous patches):
> >
> > $ patch --dry-run -p1 <
> > 0013-Configure-look-for-Java-in-the-registry-on-Windows.patch
> > ch
>
> > Indeed. Would the attached patch solve the problem? I first look for a
> > 64-bit version before a 32-bit, just to favour newer things, but there is
> > no other reason to do so.
>
> The patch does not apply neither to current master nor to current stable
> (m
> 64-bit version before a 32-bit, just to favour newer things, but there is
> no other reason to do so.
The patch does not apply neither to current master nor to current stable
(most probably it depends on previous patches):
$ patch --dry-run -p1 <
0013-Configure-look-for-Java-in-the-r
On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri wrote:
> On Fri, Jan 29, 2021 at 11:40:29PM +0100, Thibaut Cuvelier wrote:
>
> Hi Thibaut,
>
> > - This way to find Java is quite common on Windows platforms (actually,
> > it's a lot like a port of JavaCall.jl's relevant portion of code:
> >
On Fri, Jan 29, 2021 at 3:40 PM Thibaut Cuvelier wrote:
> - The cosmetic changes are based on PEP8, which is the only style guide
> for Python. Highly similar patches already went into the code base less
> than a year ago (
> http://lists.lyx.org/pipermail/lyx-devel/2020-May/001464.
On Fri, Jan 29, 2021 at 11:40:29PM +0100, Thibaut Cuvelier wrote:
Hi Thibaut,
> - This way to find Java is quite common on Windows platforms (actually,
> it's a lot like a port of JavaCall.jl's relevant portion of code:
> https://github.com/JuliaInterop/JavaCall.jl). It looks like Oracle's JVM
>
On 1/29/21 7:39 AM, Pavel Sanda wrote:
> On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote:
>> With the extent of the patches I fear that there could be bugs (unintended
>> changes) lurking specially in relation to python 2.
> Riki's call, but I don't think thi
for
Python. Highly similar patches already went into the code base less than a
year ago (http://lists.lyx.org/pipermail/lyx-devel/2020-May/001464.html).
Other style guides for Python are just more precise than PEP8 (e.g.,
Google: https://stackoverflow.com/a/2815311/1066843). I have yet to see an
important
Am Fri, 29 Jan 2021 13:39:19 +0100
schrieb Pavel Sanda :
> On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote:
> > With the extent of the patches I fear that there could be bugs (unintended
> > changes) lurking specially in relation to python 2.
>
> Rik
On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote:
> With the extent of the patches I fear that there could be bugs (unintended
> changes) lurking specially in relation to python 2.
Riki's call, but I don't think this is the best time for python scripts
overhaul.
On Friday, January 29, 2021 11:48:40 AM WET Kornel Benko wrote:
> Right, the last one should be escaped.
> Given the line
> # \DeclareLaTeXClass[revtex,revtex.sty]{REVTeX (Obsolete Version)}
> and the original regex
>
>
not the right one. What do other, more
> knowledgeable about the black magic of regular expressions think?
>
> The are other issues like mistakes in the documentation strings. For the
> moment those are harmless, I am referring to e.g. "\c" since \c it is not an
> escape
On Friday, January 29, 2021 3:51:12 AM WET Thibaut Cuvelier wrote:
> Dear list,
>
> While working on the ePub output, I ran through many Python scripts. I
> corrected a few bgs and a lot of formatting, plus one feature (find Java in
> the Windows registry in configure.py), here
her, more
knowledgeable about the black magic of regular expressions think?
The are other issues like mistakes in the documentation strings. For the
moment those are harmless, I am referring to e.g. "\c" since \c it is not an
escape sequence it gets transformed to "\\c".
Wit
the Windows registry in configure.py), here are the patches. May I push
>> them on the master branch?
> As regarda java, I have it installed but it is not found. I don't have the
> registry keys that are searched for. A key containing a usable path is
> \HKEY_CLASSES_ROOT\Installer\Produ
On Fri, Jan 29, 2021 at 04:51:12AM +0100, Thibaut Cuvelier wrote:
>
> While working on the ePub output, I ran through many Python scripts. I
> corrected a few bgs and a lot of formatting, plus one feature (find Java in
> the Windows registry in configure.py), here are the patches
On 1/28/21 10:51 PM, Thibaut Cuvelier wrote:
> Dear list,
>
> While working on the ePub output, I ran through many Python scripts. I
> corrected a few bgs and a lot of formatting, plus one feature (find
> Java in the Windows registry in configure.py), here are the patches.
&g
On 1/28/21 10:51 PM, Thibaut Cuvelier wrote:
> Dear list,
>
> While working on the ePub output, I ran through many Python scripts. I
> corrected a few bgs and a lot of formatting, plus one feature (find
> Java in the Windows registry in configure.py), here are the patches.
&g
Thanks for all for reviewing the patches!
Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
Patch 4 also looks good. I thought it could break Qt 4.8 compilation but that's
not the case [1, 2].
Sorry that I don't know enough to look at the others.
Scott
Yes
On 1/21/21 10:10 AM, Pavel Sanda wrote:
On Thu, Jan 21, 2021 at 09:51:46AM -0500, Scott Kostyshak wrote:
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
Please review my recent patches for LyX.
Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
Patch
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
> diff --git a/src/frontends/qt/DockView.h b/src/frontends/qt/DockView.h
> index 9c3a9e7460..1e7bd5f2db 100644
> --- a/src/frontends/qt/DockView.h
> +++ b/src/frontends/qt/DockView.h
> @@ -36,7 +36,7 @@ public:
>
On Thu, Jan 21, 2021 at 09:51:46AM -0500, Scott Kostyshak wrote:
> On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
> > Please review my recent patches for LyX.
>
> Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
>
> Patch 4 also
Le 21/01/2021 à 08:38, Yuriy Skalko a écrit :
Please review my recent patches for LyX.
Concerning patch 1 and 5: what guideline do you use for using vector vs
list. The patches look good, I am just wondering.
Concerning patch 4: what does the replacement of 0 or nullptr by {} bring?
JMarc
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
> Please review my recent patches for LyX.
Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
Patch 4 also looks good. I thought it could break Qt 4.8 compilation but that's
not the case [1, 2].
So
Please review my recent patches for LyX.
Yuriy
From 9c9fd209149b05d6ec879d1792b9628734ce3ed5 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sun, 10 Jan 2021 13:27:40 +0200
Subject: [PATCH 1/5] Update Development.lyx
---
lib/doc/Development.lyx | 99
On 1/3/21 11:50 PM, Richard Kimberly Heck wrote:
> Hi, all,
>
> One thing we might do on the way to 2.4.0 is look over the bugs that
> have patches. Here's a URL for that search:
>
> https://www.lyx.org/trac/query?status=accepted=assigned=new=reopened=~patch=id=summary=st
Hi, all,
One thing we might do on the way to 2.4.0 is look over the bugs that
have patches. Here's a URL for that search:
https://www.lyx.org/trac/query?status=accepted=assigned=new=reopened=~patch=id=summary=status=type=priority=milestone=component=priority
It'd be great if various people
Please review next 2 patches.
First one is fine.
In second one, can this:
@@ -1849,16 +1845,14 @@ docstring const
LaTeXFeatures::getTClassPreamble() const
-cit = usedInsetLayouts_.begin();
-end = usedInsetLayouts_.end();
+list::const_iterator cit = usedInsetLayouts_.begin
On 12/6/20 6:01 AM, Yuriy Skalko wrote:
> Please review next 2 patches.
First one is fine.
In second one, can this:
@@ -1849,16 +1845,14 @@ docstring const
LaTeXFeatures::getTClassPreamble() const
- cit = usedInsetLayouts_.begin();
- end = usedInsetLayouts_.end();
+ l
Please review next 2 patches.
Yuriy
From 9d7d04d2fc0463bd1aa41acbbe22e95548a46d22 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Wed, 2 Dec 2020 22:34:28 +0200
Subject: [PATCH 1/5] More enums & includes refactoring
---
src/Changes.cpp | 1 +
src/Chang
Le 05/12/2020 à 18:05, Richard Kimberly Heck a écrit :
I just wanted to leave types of the pair as visible. Probably this is
not really important and the code should be shortened to your variant.
I tend to agree with Yuriy here. The code is a bit longer, but you do
get an explicit indication
On 12/5/20 11:31 AM, Yuriy Skalko wrote:
>> I see they are in now, but I have a proposal (of style). I code like
>> below,
>> - for (; qq != end; ++qq) {
>> - docstring const style = from_ascii(qq->first);
>> - bool langdef = (style[0] == langqs);
>> -
I see they are in now, but I have a proposal (of style). I code like below,
- for (; qq != end; ++qq) {
- docstring const style = from_ascii(qq->first);
- bool langdef = (style[0] == langqs);
- bool globaldef = (style[0] == globalqsc);
+ map
Le 02/12/2020 à 16:32, Yuriy Skalko a écrit :
Next refactoring patches.
I see they are in now, but I have a proposal (of style). I code like below,
- for (; qq != end; ++qq) {
- docstring const style = from_ascii(qq->first);
- bool langdef = (styl
On Wed, Dec 02, 2020 at 12:01:15PM -0500, Richard Kimberly Heck wrote:
> On 12/2/20 10:32 AM, Yuriy Skalko wrote:
> > Next refactoring patches.
>
> #1 and #3 are fine. I'll leave #4 again to Pavel and others.
All patches look fine to me. Pavel
--
lyx-devel mailing list
lyx-deve
#1 and #3 are fine. I'll leave #4 again to Pavel and others.
Thanks Riki. I'll wait to commit all at once.
In #2, we have:
/// who initiated the action
-Origin origin_;
+Origin origin_ = INTERNAL;
It doesn't look as if there was a default before.
It is set as
On 12/2/20 10:32 AM, Yuriy Skalko wrote:
Next refactoring patches.
#1 and #3 are fine. I'll leave #4 again to Pavel and others.
In #2, we have:
/// who initiated the action
- Origin origin_;
+ Origin origin_ = INTERNAL;
It doesn't look as if there was a default before.
I often
Next refactoring patches.
From 884c8270bc31208d150b444140b116374e78a479 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Wed, 2 Dec 2020 00:16:55 +0200
Subject: [PATCH 1/4] Fix warnings and use range-based loop
---
src/frontends/qt/Menus.cpp | 14 ++
1 file changed, 6 insertions
They look good.
JMarc
Thanks, committed.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Le 30/11/2020 à 23:33, Yuriy Skalko a écrit :
And here are next 4 patches.
They look good.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
And here are next 4 patches.
Yuriy
From e89abcf0654343ec6090ace2bfe243809b64cabc Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Mon, 30 Nov 2020 18:06:12 +0200
Subject: [PATCH 1/4] Remove useless breaks
---
src/insets/InsetNewpage.cpp | 8
1 file changed, 8 deletions(-)
diff
Looks good to me. Pavel
Thanks, committed.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Mon, Nov 30, 2020 at 12:38:36PM +0200, Yuriy Skalko wrote:
> Next patches
Looks good to me. Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Next patches
Yuriy
From 065bbc50691b50bcc6b608fbcfb362d7f0e654ab Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Sat, 28 Nov 2020 01:13:36 +0200
Subject: [PATCH 1/4] Cleanup included headers
---
src/KeySequence.cpp | 2 --
src/frontends/qt/GuiErrorList.cpp | 1 -
src/frontends
#1, #4, and #5 are all fine.
I think #3 is fine, too, but someone who knows more about that code than I
do should have a look, too.
I suspect #2 is fine, as well, but Pavel may want to weigh in.
2 looks fine, 3 looks fine in principle :)
Pavel
Thanks for reviewing, all committed.
Yuriy
On Fri, Nov 27, 2020 at 05:53:00PM -0500, Richard Kimberly Heck wrote:
> On 11/27/20 4:43 PM, Yuriy Skalko wrote:
> >>If it really isn't used, then go ahead.
> >>
> >>Riki
> >
> >Here is patch to remove it + another patches to review.
>
> #1, #4, a
On 11/27/20 4:43 PM, Yuriy Skalko wrote:
If it really isn't used, then go ahead.
Riki
Here is patch to remove it + another patches to review.
#1, #4, and #5 are all fine.
I think #3 is fine, too, but someone who knows more about that code than
I do should have a look, too.
I suspect #2
If it really isn't used, then go ahead.
Riki
Here is patch to remove it + another patches to review.
Yuriy
From a164646e24e8271950d51ccc6d889f860cddff5b Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 27 Nov 2020 11:09:16 +0200
Subject: [PATCH 1/5] Use range-based loops
---
src
On 11/27/20 5:35 AM, Yuriy Skalko wrote:
>> All the patches are fine. I have only one remark concerning
>> Counters::copy. I do not understand why this is a Counters method
>> _and_ it receives two Counters instances as parameters. This looks
>> like a badly specifi
All the patches are fine. I have only one remark concerning Counters::copy. I
do not understand why this is a Counters method _and_ it receives two Counters
instances as parameters. This looks like a badly specified method.
OTOH, it looks like it is not used. What about removing it ?
JMarc
Le 26/11/2020 à 22:07, Yuriy Skalko a écrit :
Here are next 5 patches.
All the patches are fine. I have only one remark concerning
Counters::copy. I do not understand why this is a Counters method _and_
it receives two Counters instances as parameters. This looks like a
badly specified
Here are next 5 patches.
Yuriy
From bdf2a935f79f465e75bafdedc3e50a4a513e24ca Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 26 Nov 2020 00:17:29 +0200
Subject: [PATCH 1/5] Use to_string function
---
src/client/client.cpp | 10 +-
1 file changed, 1 insertion(+), 9 deletions
I do not like the removal of debug.h.
It's very handy to be able to simply lyxerr while debuging
without playing with includes...
Pavel
OK. I restored debug.h includes in headers and committed the patch.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
This one comes from the same place. I'll adopt the same solution there.
Riki
Thanks for fixes.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Tue, Nov 24, 2020 at 10:55:41PM +0100, Pavel Sanda wrote:
> On Tue, Nov 24, 2020 at 04:49:59PM -0500, Richard Kimberly Heck wrote:
> > On 11/24/20 4:29 PM, Yuriy Skalko wrote:
> > >As for the patch 5, these null pointer dereferences happen even on opening
> > >LyX manuals. It is undefined
On 11/24/20 4:55 PM, Pavel Sanda wrote:
On Tue, Nov 24, 2020 at 04:49:59PM -0500, Richard Kimberly Heck wrote:
On 11/24/20 4:29 PM, Yuriy Skalko wrote:
As for the patch 5, these null pointer dereferences happen even on opening
LyX manuals. It is undefined behavior even if it doesn't crash LyX.
On 11/24/20 4:59 PM, Richard Kimberly Heck wrote:
On 11/24/20 4:29 PM, Yuriy Skalko wrote:
As for the patch 5, these null pointer dereferences happen even on
opening LyX manuals. It is undefined behavior even if it doesn't
crash LyX. Most likely should be fixed somewhere instead of just
On 11/24/20 4:29 PM, Yuriy Skalko wrote:
As for the patch 5, these null pointer dereferences happen even on
opening LyX manuals. It is undefined behavior even if it doesn't crash
LyX. Most likely should be fixed somewhere instead of just checking.
From 234bfe70c1e2766d856257aebe7eaad8836f5976
On Tue, Nov 24, 2020 at 04:49:59PM -0500, Richard Kimberly Heck wrote:
> On 11/24/20 4:29 PM, Yuriy Skalko wrote:
> >As for the patch 5, these null pointer dereferences happen even on opening
> >LyX manuals. It is undefined behavior even if it doesn't crash LyX. Most
> >likely should be fixed
On 11/24/20 4:29 PM, Yuriy Skalko wrote:
As for the patch 5, these null pointer dereferences happen even on
opening LyX manuals. It is undefined behavior even if it doesn't crash
LyX. Most likely should be fixed somewhere instead of just checking.
1-4 are fine. I'll have a look at the null
As for the patch 5, these null pointer dereferences happen even on
opening LyX manuals. It is undefined behavior even if it doesn't crash
LyX. Most likely should be fixed somewhere instead of just checking.
Yuriy
From 761602ef70c60403992255ac2e3c23b112235378 Mon Sep 17 00:00:00 2001
From:
Le 20/11/2020 à 23:16, Yuriy Skalko a écrit :
And here are next 3 patches.
Yuriy
Look good to me.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
And here are next 3 patches.
Yuriy
From 83a9828c25ab2501bbaadcfe86040b076905d3c5 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 19 Nov 2020 14:51:00 +0200
Subject: [PATCH 1/4] Remove unused header
---
src/mathed/InsetMathSymbol.cpp | 1 -
src/mathed/MathSupport.cpp | 1 -
2 files
On 11/19/20 2:03 PM, José Abílio Matos wrote:
On Thursday, November 19, 2020 2:23:14 PM WET Jean-Marc Lasgouttes wrote:
> I have to say that lambdas are not my cup of tea, but the original code
> is not great either.
With variable capture lambdas can sometimes be subtle, but in this
case
On Thursday, November 19, 2020 2:23:14 PM WET Jean-Marc Lasgouttes wrote:
> I have to say that lambdas are not my cup of tea, but the original code
> is not great either.
With variable capture lambdas can sometimes be subtle, but in this case that
is not an issue and the code is a lot more
Le 19/11/2020 à 14:54, Pavel Sanda a écrit :
On Thu, Nov 19, 2020 at 02:09:08PM +0200, Yuriy Skalko wrote:
New patches for LyX.
Patch 1 looks good to go, I am not sure about the sencond, i.e.
to what extent we want to use lambdas. IIRC some people complained
about readability (OTOH constructs
On Thu, Nov 19, 2020 at 02:09:08PM +0200, Yuriy Skalko wrote:
> New patches for LyX.
Patch 1 looks good to go, I am not sure about the sencond, i.e.
to what extent we want to use lambdas. IIRC some people complained
about readability (OTOH constructs like firster are not that nice
either). Any
New patches for LyX.
Yuriy
From c083a56f9ddb2e4d5d2cc4bb0586fbb83ae598e9 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Thu, 19 Nov 2020 13:24:04 +0200
Subject: [PATCH 1/2] Simplify constructors
---
src/Dimension.h| 28 +++-
src/graphics
Concerning gprof: please note that it does not take into account the code that
is not instrumented, like Qt, the kernel and maybe parts of the c++ standard
library.
I tend to use perf on linux instead (especially through hotspot, with its
awesome flamegraph feature).
Often I only use my
Le 11/11/2020 à 19:06, Richard Kimberly Heck a écrit :
On 11/11/20 7:00 AM, Yuriy Skalko wrote:
My profiling results are in attached SVG. I've done scrolling
through some of the manuals during profiled run.
What profiler did you use?
I tried to look again at the code, but could not find
On 11/11/20 7:00 AM, Yuriy Skalko wrote:
My profiling results are in attached SVG. I've done scrolling
through some of the manuals during profiled run.
What profiler did you use?
I tried to look again at the code, but could not find the code that I
believed to create a nested loop and
I see that you've tried this, but reverted in 9e7832915f. What were the problems due to this removal?
I do not remember, sorry. Looking at the mail archive did not ring a bell
either.
I've found some info in the ticket you referenced in recent reply to
Riki:
Le 05/11/2020 à 11:43, Yuriy Skalko a écrit :
Yes, macros implementation is really tangled. Maybe at first we can try
to minimize calling updateMacros?
I see that you've tried this, but reverted in 9e7832915f. What were the
problems due to this removal?
I do not remember, sorry. Looking at
Should I commit my recent patches into this branch?
Sure.
What is the way LyX project uses for updating feature branches:
rebasing on master, merging master or cherry-picking needed commits?
When it comes time to commit, I think people usually just rebase on
master, then merge. But we
On 11/7/20 10:06 AM, Yuriy Skalko wrote:
>> Toward that end, I've created a features/cleanup/updateMacros branch
>> and committed a very small piece. The first step, for me, is to
>> figure out how this stuff works!
>>
>> Riki
>
> Should I commit my rec
Toward that end, I've created a features/cleanup/updateMacros branch and
committed a very small piece. The first step, for me, is to figure out how this
stuff works!
Riki
Should I commit my recent patches into this branch? What is the way LyX
project uses for updating feature branches
is really tangled. Maybe at first we can
try to minimize calling updateMacros?
That is definitely the goal. But, as you saw with 9e7832915f, this is
all very fragile.
Also attaching several patches with some improvements.
These all look ok to me, so go ahead with them, with the exception of
#2. I
calling updateMacros?
That is definitely the goal. But, as you saw with 9e7832915f, this is
all very fragile.
Also attaching several patches with some improvements.
These all look ok to me, so go ahead with them, with the exception of
#2. I *think* this is probably redundant---it was done
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
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
On 11/2/20 2:33 PM, Jean-Marc Lasgouttes wrote:
Le 02/11/2020 à 19:50, Yuriy Skalko a écrit :
I'll check this stuff. By the way, is it related to numbered layouts
that Daniel is now implementing on the bugtracker
(https://www.lyx.org/trac/ticket/12010)? I don't inadvertently want
to break
On Monday, November 2, 2020 7:33:41 PM WET Jean-Marc Lasgouttes wrote:
> Yes, updateMacros is a pain, it is actually a O(n^2) algorithm which
> kills performance for big documents. But it is a bit scary and I never
> dared changing it
I had a PhD student last year showing a lyx document full of
Le 02/11/2020 à 19:50, Yuriy Skalko a écrit :
I'll check this stuff. By the way, is it related to numbered layouts
that Daniel is now implementing on the bugtracker
(https://www.lyx.org/trac/ticket/12010)? I don't inadvertently want to
break his results.
Yes it is related, but it should not
I am very impressed :) If you feel like factoring more, you could have a look
at splitting Counters/Counter into 3 classes:
1/2) the definitions, which belong to the textclass, and which should basically
be accessed as const
3) the values of the counters, which can be a much more compact
Le 01/11/2020 à 17:08, Yuriy Skalko a écrit :
And the last 10 refactoring patches from me.
I am very impressed :) If you feel like factoring more, you could have a
look at splitting Counters/Counter into 3 classes:
1/2) the definitions, which belong to the textclass, and which should
On Sun, Nov 01, 2020 at 06:08:47PM +0200, Yuriy Skalko wrote:
> And the last 10 refactoring patches from me.
Apart from patches 5 & 10 these seem ok to me.
I am not sure we want to ditch that bformat version, just because its not
currently used, someone might have opinion.
I do not und
On Thu, Oct 29, 2020 at 08:47:23AM +0200, Yuriy Skalko wrote:
> Next 3 patches.
Looks good. Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Next 3 patches.
Yuriy
From 37944992bf356680f8910d384df37ac3fb998339 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Mon, 26 Oct 2020 20:16:28 +0200
Subject: [PATCH 1/5] Move HullType functions declared in InsetMath.h into
InsetMath.cpp
---
src/mathed/InsetMath.cpp | 42
Previously it happened that these headers in all clients were included after
some other headers that define these types (directly or indirectly).
Oh, I see it's just that we were always lucky to have e.g. include FileName.h
before include Clipboard.h.
Thanks,
Pavel
Yes.
C/C++ header include
On Mon, Oct 26, 2020 at 12:45:53AM +0200, Yuriy Skalko wrote:
> Previously it happened that these headers in all clients were included after
> some other headers that define these types (directly or indirectly).
Oh, I see it's just that we were always lucky to have e.g. include FileName.h
before
--- a/src/frontends/Clipboard.h
+++ b/src/frontends/Clipboard.h
@@ -14,6 +14,7 @@
#ifndef BASE_CLIPBOARD_H
#define BASE_CLIPBOARD_H
+#include "support/FileName.h"
#include "support/strfwd.h"
namespace lyx {
diff --git a/src/frontends/qt/GuiKeySymbol.h b/src/frontends/qt/GuiKeySymbol.h
On Sun, Oct 25, 2020 at 09:09:00AM +0200, Yuriy Skalko wrote:
> --- a/src/frontends/Clipboard.h
> +++ b/src/frontends/Clipboard.h
> @@ -14,6 +14,7 @@
> #ifndef BASE_CLIPBOARD_H
> #define BASE_CLIPBOARD_H
>
> +#include "support/FileName.h"
> #include "support/strfwd.h"
>
> namespace lyx {
>
1 - 100 of 2629 matches
Mail list logo
