Le 10/07/2025 à 22:11, Thibaut Cuvelier a écrit :
QMake is mostly deprecated: only bugfixes for Qt 6, removal for Qt 7.
CMake is the way forward: you can only build Qt 6 with CMake. (No
official or direct announcement, though. Have a look at the development
history: https://github.com/qt/qtbase
Le 10/07/2025 à 21:24, Richard Kimberly Heck a écrit :
On 7/10/25 12:16 PM, Jean-Marc Lasgouttes wrote:
Hi there,
Would that patch be OK? It makes Qt6 the default for configure-based
builds.
It does seem time to default to Qt 6.
I pushed it. There is no mail because I changed a latin1
On Thu, 10 Jul 2025, 18:16 Jean-Marc Lasgouttes, wrote:
> Hi there,
>
> Would that patch be OK? It makes Qt6 the default for configure-based
> builds.
>
> Thoughts welcome.
>
>
> Another thing that I'd like to try, is to get rid of configuration by
> any thing
On 7/10/25 12:16 PM, Jean-Marc Lasgouttes wrote:
Hi there,
Would that patch be OK? It makes Qt6 the default for configure-based
builds.
It does seem time to default to Qt 6.
I do not have any opinion about qmake, etc.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https
Hi there,
Would that patch be OK? It makes Qt6 the default for configure-based builds.
Thoughts welcome.
Another thing that I'd like to try, is to get rid of configuration by
any thing else than qmake.
Currently, we try qmake, then pkg-config, and finally the old style
detection.
Le 01/07/2025 à 10:54, Scott Kostyshak a écrit :
Thanks, JMarc! Please commit. (and also thanks for the explanation).
Done.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
ntented (e.g., otherwise the code doesn't compile).
> > The relevant code was introduced at a7b921aeeba.
> >
> > The attached patch just makes the cast explicit.
> >
> > Is this OK?
>
> I would propose the attached instead. Your patch turns a pointer to read
>
p(argc, (char**)argv);
|^
From what I can understand, the initial const was intended, and casting
away the const was intented (e.g., otherwise the code doesn't compile).
The relevant code was introduced at a7b921aeeba.
The attached patch just makes the cast explicit.
Is this
On Tue, Jul 01, 2025 at 02:39:47AM +0200, Pavel Sanda wrote:
> On Tue, Jul 01, 2025 at 12:03:20AM +0200, Scott Kostyshak wrote:
> > Is the attached patch OK?
>
> Looks ok to me. P
Thanks, it's in master at 22b35872.
Scott
signature.asc
Description: PGP signature
--
lyx-de
On Tue, Jul 01, 2025 at 12:03:20AM +0200, Scott Kostyshak wrote:
> Is the attached patch OK?
Looks ok to me. P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
I'm guessing it was a typo to include the implementation file instead of
the header, but still wanted to check.
Is the attached patch OK?
It fixes a couple of Clang warnings in the category -Wheader-hygiene.
Scott
From 4c7031632f2185b8ff334a5043fd68bb7fac5ab9 Mon Sep 17 00:00:00 2001
can understand, the initial const was intended, and casting
away the const was intented (e.g., otherwise the code doesn't compile).
The relevant code was introduced at a7b921aeeba.
The attached patch just makes the cast explicit.
Is this OK?
Scott
From eda7f4f7cd878a77c7a64e5167c770524175af0a Mon
On Fri, Jun 27, 2025 at 10:37:05AM +0200, Jean-Marc Lasgouttes wrote:
> Le 27 juin 2025 10:26:32 GMT+02:00, Scott Kostyshak a
> écrit :
> >Thanks, José for your follow-up commit. These last days I've been
> >focused mainly on compiler warnings. And also seeing if anything
> >interesting from fsan
Le 27 juin 2025 10:26:32 GMT+02:00, Scott Kostyshak a écrit :
>Thanks, José for your follow-up commit. These last days I've been
>focused mainly on compiler warnings. And also seeing if anything
>interesting from fsanitize.
>
>Scott
You may want to play with cppcheck (--enable=style, for example)
On Fri, Jun 27, 2025 at 07:59:23AM +0100, José Matos wrote:
> On Thu, 2025-06-26 at 22:17 +0200, Enrico Forestieri wrote:
> > Because we love tradition and this is lost in the mists of time? ;-)
> >
> > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg96750.html
>
> Now is the time to star
On Thu, 2025-06-26 at 22:17 +0200, Enrico Forestieri wrote:
> Because we love tradition and this is lost in the mists of time? ;-)
>
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg96750.html
Now is the time to start new traditions. :-)
I removed the last bits.
@Scott some of the work
ing default is stderr. :-)
>
> > The attached patch changes it to print to STDOUT.
>
> OK by me.
> > Without the patch, a command like the following:
> >
> > python3 -tt /home/scott/lyxbuilds/master-master/repo/lib/configure.py >
> > /dev/null
>
> Why,
On Thu, Jun 26, 2025 at 05:28:19PM +0100, José Matos wrote:
On Thu, 2025-06-26 at 00:21 +0200, Scott Kostyshak wrote:
[...]
python3 -tt /home/scott/lyxbuilds/master-master/repo/lib/configure.py
>
/dev/null
Why, on Earth, are we still using -tt? :-)
Because we love tradition and this is los
On Thu, 2025-06-26 at 00:21 +0200, Scott Kostyshak wrote:
> Currently, configure.py prints output to STDERR, even though they are
> not necessarily warnings or errors.
I can understand why the logging default is stderr. :-)
> The attached patch changes it to print to STDOUT.
Currently, configure.py prints output to STDERR, even though they are
not necessarily warnings or errors.
The attached patch changes it to print to STDOUT.
Without the patch, a command like the following:
python3 -tt /home/scott/lyxbuilds/master-master/repo/lib/configure.py >
/dev/null
e
Le 20/02/2025 à 12:14, José Matos a écrit :
On Wed, 2025-02-19 at 18:51 -0500, Richard Kimberly Heck wrote:
I don't use minted either, but the patch looks right to me.
Riki
I use minted and the patch does make sense.
The next issue is if we use this idiom elsewhere... because we lo
On Wed, 2025-02-19 at 18:51 -0500, Richard Kimberly Heck wrote:
> I don't use minted either, but the patch looks right to me.
>
> Riki
I use minted and the patch does make sense.
The next issue is if we use this idiom elsewhere... because we looking into the
parameters and removi
Hi,
Since I am not able to run or even understand a minted test, I'll like
some feedback about this (straightforward?) patch.
Does it make sense? It was spotted by Coverity Scan.
JMarc
From 2a97a951901cd5efaede2dca19b873d71910d31d Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
On 2/19/25 6:24 PM, Jean-Marc Lasgouttes wrote:
Hi,
Since I am not able to run or even understand a minted test, I'll like
some feedback about this (straightforward?) patch.
I don't use minted either, but the patch looks right to me.
Riki
--
lyx-devel mailing list
lyx-devel@lis
Am Fri, 7 Feb 2025 10:52:49 +0100
schrieb pdv :
> Herewith a small patch for the sign-install target on MacOS.
> The hard-coded "LyX2.4.app" name is replaced by "LyX${LYX_VERSION}.app".
>
> pdv
Thanks for the patch.
Committed at f10f41bf.
Kornel
Herewith a small patch for the sign-install target on MacOS.
The hard-coded "LyX2.4.app" name is replaced by "LyX${LYX_VERSION}.app".
pdvdiff --git a/development/cmake/post_install/CMakeLists.txt
b/development/cmake/post_install/CMakeLists.txt
index 56c552e4d0..fd5
Hi,
Thanks a lot for the patch! I have pushed it onto the master branch.
Thibaut Cuvelier
On Wed, 13 Nov 2024 at 15:39, Lorenzo Bertini
wrote:
> Dear devs,
> can somebody push this tiny patch for InsetMathCases::mathmlize that adds
> an mrow that makes the bracket stretch corre
Dear devs,
can somebody push this tiny patch for InsetMathCases::mathmlize that adds
an mrow that makes the bracket stretch correctly? See attached image.
Thanks,
Lorenzo
From 8c48be4b0ef1ede8b91e5e4fb20566225cddc172 Mon Sep 17 00:00:00 2001
From: Lorenzo Bertini
Date: Wed, 13 Nov 2024 12:55:59
Le 04/10/2024 à 19:18, Enrico Forestieri a écrit :
We should now either get rid of STD_STRING_USES_COW or implement the
right check for it.
I would get rid of it, since it is required by the standard to not use
COW. Our new requirement is "a C++ compiler that _really_ implements
C++11" (remem
On Fri, Oct 04, 2024 at 03:17:12PM +0200, Pavel Sanda wrote:
So are you able to compile on cygwin after these two patches applied on
top
of each other (first strfwd out, then trivstring out)?
Yep, it compiles and works fine.
We should now either get rid of STD_STRING_USES_COW or implement t
On Fri, Oct 04, 2024 at 05:28:29PM +0200, Jean-Marc Lasgouttes wrote:
> > If we are sure that the thread safety issue is gone for all reasonable
> > STL implemtations then yes (so far I saw only explicit ack for gcc5,
> > but did not googled around).
>
> This threadsafe string implementation is a
Le 04/10/2024 à 17:20, Pavel Sanda a écrit :
On Fri, Oct 04, 2024 at 04:46:01PM +0200, Jean-Marc Lasgouttes wrote:
I did not read completely your comment in docstring.h. I think we can get
rid completely of the names trvstring and trivdocstring soon after this
landed.
If we are sure that the t
On Fri, Oct 04, 2024 at 04:46:01PM +0200, Jean-Marc Lasgouttes wrote:
> I did not read completely your comment in docstring.h. I think we can get
> rid completely of the names trvstring and trivdocstring soon after this
> landed.
If we are sure that the thread safety issue is gone for all reasona
Le 04/10/2024 à 16:36, Pavel Sanda a écrit :
On Fri, Oct 04, 2024 at 04:18:54PM +0200, Jean-Marc Lasgouttes wrote:
This looks good to me. Note that this whole test program can be removed:
I was thinking about it and spared it as you can see it as a test for
docstring sanity now. But I can remo
On Fri, Oct 04, 2024 at 04:18:54PM +0200, Jean-Marc Lasgouttes wrote:
> This looks good to me. Note that this whole test program can be removed:
I was thinking about it and spared it as you can see it as a test for
docstring sanity now. But I can remove completely if you prefer.
Pavel
--
lyx-deve
that if we ditch trivstring we don't need to set
STD_STRING_USES_COW. In this case, the patch I proposed to check whether cow
is actually used or not will also not be necessary.
So are you able to compile on cygwin after these two patches applied on top
of each other (first strfwd out, then
ABI is set.
>
> I think that if we ditch trivstring we don't need to set
> STD_STRING_USES_COW. In this case, the patch I proposed to check whether cow
> is actually used or not will also not be necessary.
So are you able to compile on cygwin after these two patches applied o
ng. It was using the implementation in
src/support/trivstring.cpp simply because we wrongly decide that
std::string implementation uses cow when _GLIBCXX_USE_CXX11_ABI is set.
I think that if we ditch trivstring we don't need to set
STD_STRING_USES_COW. In this case, the patch I proposed t
; > > > > suggested, it fails in this new way:
> > > > >
> > > > > Adding "#include " makes cygwin happy?
> > > >
> > > > It helps. Compilation proceeds until the following failure:
> > >
> > > Howe
On Fri, Oct 04, 2024 at 12:28:08AM +0200, Jean-Marc Lasgouttes wrote:
> Le 03/10/2024 ?? 23:33, Pavel Sanda a écrit :
> > But I don't like it there as all trivstring stuff should imho go into
> > trivstring.h.
> > Before I was afraid what will break, but as I broke cygwin anyway, maybe
> > it's t
This is my take on this patch from yuriy, after 854c9de8 had to be
reverted. See discussion here:
https://marc.info/?t=16101843892&r=2&w=2
In the case of move constructor, instead of setting the Private
pointer of the moved FileName to nullptr, set it to a pointer to a
static
024 at 01:35:55AM +0200, Enrico Forestieri wrote:
> > > And, after adding "#include " to src/support/trivstring.h as
> > > suggested, it fails in this new way:
> >
> > Adding "#include " makes cygwin happy?
>
> It helps. Compilation proceeds u
Le 03/10/2024 à 23:33, Pavel Sanda a écrit :
But I don't like it there as all trivstring stuff should imho go into
trivstring.h.
Before I was afraid what will break, but as I broke cygwin anyway, maybe it's
time
to get rid of this from docstring?
If we decide that we want at least gcc5, we ca
rote:
> > > > And, after adding "#include " to src/support/trivstring.h as
> > > > suggested, it fails in this new way:
> > >
> > > Adding "#include " makes cygwin happy?
> >
> > It helps. Compilation proceeds until the fo
is new way:
Adding "#include " makes cygwin happy?
It helps. Compilation proceeds until the following failure:
However, applying the attached patch it compiles and works fine.
See https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg219747.html
for the reason the patch is right.
On Thu, Oct 03, 2024 at 03:57:56PM +0200, Pavel Sanda wrote:
On Thu, Oct 03, 2024 at 01:35:55AM +0200, Enrico Forestieri wrote:
And, after adding "#include " to src/support/trivstring.h as
suggested, it fails in this new way:
Adding "#include " makes cygwin happy?
It helps. Compilation proce
On Thu, Oct 03, 2024 at 01:35:55AM +0200, Enrico Forestieri wrote:
> And, after adding "#include " to src/support/trivstring.h as
> suggested, it fails in this new way:
Adding "#include " makes cygwin happy?
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/list
On Thu, Oct 03, 2024 at 01:29:18AM +0200, Enrico Forestieri wrote:
On Tue, Oct 01, 2024 at 11:01:15PM +0200, Pavel Sanda wrote:
Enrico/Eugene/Stephan can you confirm you can compile and run master
with the attached patch?
On cygwin compilation fails as follows:
make[5]: Entering directory
On Tue, Oct 01, 2024 at 11:01:15PM +0200, Pavel Sanda wrote:
Enrico/Eugene/Stephan can you confirm you can compile and run master
with the attached patch?
On cygwin compilation fails as follows:
make[5]: Entering directory
'/usr/local/src/lyx/lyx-devel/build-cygwin/src/support&#
On Tue, 1 Oct 2024 at 23:02, Pavel Sanda wrote:
> On Tue, Oct 01, 2024 at 07:09:03PM +0200, Jean-Marc Lasgouttes wrote:
> > Le 01/10/2024 ?? 18:18, Pavel Sanda a écrit :
> > > I could produce patch which ditches strfwd and let Enrico/Eugene test
> it?
> > >
>
On Tue, Oct 01, 2024 at 07:09:03PM +0200, Jean-Marc Lasgouttes wrote:
> Le 01/10/2024 ?? 18:18, Pavel Sanda a écrit :
> > I could produce patch which ditches strfwd and let Enrico/Eugene test it?
> >
> > From what I see it might do more harm than good in linux nowadys...
&
Since some time (unfortunately not documented when), nomencl uses the
rather odd % escape character (instead of " due to its activation by
babel etc.), but we haven't adapted it fully yet.
The attached patch does that.
Master uses the right escape char with its new approach.
OK?
--
J
On Wed, Jul 24, 2024 at 10:51:39PM +0200, Jean-Marc Lasgouttes wrote:
> Le 24/07/2024 ?? 22:48, Pavel Sanda a écrit :
> > I have difficulty to see any visible difference when it comes to the cursor
> > speed in UG after your last patch (detecting changes in buffer befo
Le 24/07/2024 à 22:48, Pavel Sanda a écrit :
I have difficulty to see any visible difference when it comes to the cursor
speed in UG after your last patch (detecting changes in buffer before calling
updatemacros), i.e. the difference seems to be within rounding error.
The updateMacros probably
I have to check.
>
> The answer is yes ;) But I have a patch for that (trivial to adapt for
> stats).
I have difficulty to see any visible difference when it comes to the cursor
speed in UG after your last patch (detecting changes in buffer before calling
updatemacros), i.e. the di
Le 24/07/2024 à 01:57, Pavel Sanda a écrit :
On top of that this speed up was good enough that I do not see visually
noticeable hiccups while moving with the cursor in User Guide anymore - but
that's also due to the fact that cursor moving is still somewhat slow on fast
repeat rates compared to o
Le 24/07/2024 à 19:28, Scott Kostyshak a écrit :
/home/scott/lyxbuilds/master-master/repo/src/insets/InsetTabular.h:1120:7:
error: 'updateStatistics' overrides a member function but is not marked
'override' [-Werror,-Winconsistent-missing-override]
void updateStatistics(Statistics & st
On Wed, Jul 24, 2024 at 06:10:42PM GMT, Jean-Marc Lasgouttes wrote:
> Le 24/07/2024 à 09:43, Jean-Marc Lasgouttes a écrit :
> > > All in all this patch is nice piece of work! :)
> >
> > Thanks. It needs some cleanup, so I will push it later.
>
> I found the t
Le 24/07/2024 à 09:43, Jean-Marc Lasgouttes a écrit :
All in all this patch is nice piece of work! :)
Thanks. It needs some cleanup, so I will push it later.
I found the time, the code is now in.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo
.
Are updateMacros called for each caret movement in the document?
If true this might be option how to improve the keyboard movement
speed little bit.
Possibly, I have to check.
The answer is yes ;) But I have a patch for that (trivial to adapt for
stats).
JMarc
--
lyx-devel mailing list
lyx
Le 24/07/2024 à 09:55, Pavel Sanda a écrit :
On Wed, Jul 24, 2024 at 09:43:43AM +0200, Jean-Marc Lasgouttes wrote:
Good, that was the point. The code I proposed to avoid running updateMacros on
an unchanged document can be used here too.
Are updateMacros called for each caret movement in the
On Wed, Jul 24, 2024 at 09:43:43AM +0200, Jean-Marc Lasgouttes wrote:
> Good, that was the point. The code I proposed to avoid running updateMacros
> on an unchanged document can be used here too.
Are updateMacros called for each caret movement in the document?
If true this might be option how to
Le 24 juillet 2024 01:57:01 GMT+02:00, Pavel Sanda a écrit :
>I tested and do not see any counting difference in my selected document and
>confirm that profiling gives about 3x better time with your patch.
Thanks for testing. To be frank, I have been disappointed at first to have
"
On Mon, Jul 22, 2024 at 01:37:38PM +0200, Pavel Sanda wrote:
> > Please test.
>
> I'll hopefully do in the next days.
I tested and do not see any counting difference in my selected document and
confirm that profiling gives about 3x better time with your patch.
On top of that
On Mon, Jul 22, 2024 at 12:32:28AM +0200, Jean-Marc Lasgouttes wrote:
> The statistics code is known to be very slow, because it relies on
> DocIterator to go through the buffer.
One more idea how to speedup the feedback from the discussions in trac:
trigger the update once the key/button is relea
Le 21/07/2024 à 09:49, José Matos a écrit :
Actually it was more (for me a least) import that you applied one of
the changes. Personally I prefer your first option but even the second
option would be better than not to do nothing.
I suppose that we can improve our communication skills and avoid
rom: Jean-Marc Lasgouttes
Date: Sun, 21 Jul 2024 22:09:28 +0200
Subject: [PATCH] WIP: rewrite statistics code
The statistics code is known to be very slow, because it relies on
DocIterator to go through the buffer.
This commit introduces a new Statitistics class that encapsulates the
main code, al
On Sat, 2024-07-20 at 23:44 +0200, Jean-Marc Lasgouttes wrote:
> Since nobody seems to care, I put it in.
>
> JMarc
Thanks for that.
Actually it was more (for me a least) import that you applied one of
the changes. Personally I prefer your first option but even the second
option would be better
Le 19/06/2024 à 16:23, Jean-Marc Lasgouttes a écrit :
I can't find the place where math comments appearance was discussed
recently, so here is is.
This trivial patch uses a yellow (Note) background to mark comments.
While the result is not the same as Notes (the output actually goes to
On Wed, Jun 19, 2024 at 04:23:45PM GMT, Jean-Marc Lasgouttes wrote:
> I can't find the place where math comments appearance was discussed
> recently, so here is is.
>
> This trivial patch uses a yellow (Note) background to mark comments. While
> the result is not the same
I can't find the place where math comments appearance was discussed
recently, so here is is.
This trivial patch uses a yellow (Note) background to mark comments.
While the result is not the same as Notes (the output actually goes to
LaTeX) it seems to me that this conveys the intent o
On Mon, 2024-06-17 at 22:10 +0200, Enrico Forestieri wrote:
> I don't know about Wayland, but, please, see whether it works after
> fe64db4b.
It works. Thank you. :-)
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
.
Yep, these warnings are harmless.
@Jean-Marc note that these warning, for qt6, happened before your
current patch. That is why I wrote this is slightly related to this
patch.
That warning was added in Qt6 some time ago, but nothing was changed
in the locale handling. The web is full with
warning, for qt6, happened before your
current patch. That is why I wrote this is slightly related to this
patch.
That warning was added in Qt6 some time ago, but nothing was changed in
the locale handling. The web is full with reports about it and I don't
understand to what it is due. Seemingl
On Mon, Jun 17, 2024 at 04:56:41PM +0100, José Matos wrote:
Running this on Fedora 40. FWIW I am on KDE (Wayland).
The configure stage works, without a warning, but then at the end of
the build stage I get:
CXXLDlyx
/usr/bin/ld: frontends/qt/liblyxqt.a(GuiApplication.o): undefined
referen
On Mon, Jun 17, 2024 at 04:41:18PM +0200, Jean-Marc Lasgouttes wrote:
Le 15/06/2024 à 22:59, Enrico Forestieri a écrit :
On Fri, Jun 14, 2024 at 08:09:00PM +0200, Jean-Marc Lasgouttes wrote:
This seems to work, although for some reason it does not add
x11extras here.
Actually, x11extras is
On Mon, 2024-06-17 at 17:02 +0100, José Matos wrote:
> Slightly related to your message:
>
> When configuring autools with qt6 I get these (seemingly harmless)
> warnings.
@Jean-Marc note that these warning, for qt6, happened before your
current patch. That is why I wrote this
On Mon, 2024-06-17 at 17:25 +0200, Jean-Marc Lasgouttes wrote:
> I pushed this change to master, along with a warning when the qmake
> way did not work. Please tell me when this triggers a warning, so
> that we can understand what happens and how to solve it.
>
> JMarc
Slightly related to your me
On Mon, 2024-06-17 at 17:25 +0200, Jean-Marc Lasgouttes wrote:
> I pushed this change to master, along with a warning when the qmake
> way did not work. Please tell me when this triggers a warning, so
> that we can understand what happens and how to solve it.
>
> JMarc
Running this on Fedora 40.
Le 17/06/2024 à 16:41, Jean-Marc Lasgouttes a écrit :
Le 15/06/2024 à 22:59, Enrico Forestieri a écrit :
On Fri, Jun 14, 2024 at 08:09:00PM +0200, Jean-Marc Lasgouttes wrote:
This seems to work, although for some reason it does not add
x11extras here.
Actually, x11extras is detected but you
would add a library, but it is only a header thing, right?
Applying the attached patch on top of yours does the trick.
Thanks!
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am 14.06.2024 um 20:09 schrieb Jean-Marc Lasgouttes :
>
> This patch allows autoconf to rely on qmake for configuring qt5 too. This
> relies on the great work done by Enrico. If this works, I will propose to
> remove all the other configurations macros for qt.
>
> This seems
On Fri, Jun 14, 2024 at 08:09:00PM +0200, Jean-Marc Lasgouttes wrote:
This seems to work, although for some reason it does not add x11extras
here.
Actually, x11extras is detected but you forgot about HAVE_QT5_X11_EXTRAS.
Applying the attached patch on top of yours does the trick.
--
Enrico
On Sat, Jun 15, 2024 at 01:23:52PM +0200, Enrico Forestieri wrote:
On Fri, Jun 14, 2024 at 08:09:00PM +0200, Jean-Marc Lasgouttes wrote:
Could you people have a go at it before I push it?
I tried it with native Windows and Cygwin with GDI backend instead of X11.
In both cases it detected the
On Fri, Jun 14, 2024 at 08:09:00PM +0200, Jean-Marc Lasgouttes wrote:
Could you people have a go at it before I push it?
I tried it with native Windows and Cygwin with GDI backend instead of X11.
In both cases it detected the winextras module and added appropriate
includes and libraries. How
On Fri, Jun 14, 2024 at 08:09:00PM +0200, Jean-Marc Lasgouttes wrote:
> Could you people have a go at it before I push it?
Seems to work on oldstable debian.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
This patch allows autoconf to rely on qmake for configuring qt5 too.
This relies on the great work done by Enrico. If this works, I will
propose to remove all the other configurations macros for qt.
This seems to work, although for some reason it does not add x11extras here.
Could you people
There's a patch for a nasty export bug here:
https://www.lyx.org/trac/ticket/13017
I thought it best not to commit it yet, but I'd really like to solve
this before 2.4.0. I think we'll get reports if we don't. From a testing
point of view, I'm less interested in
Le 10/11/2023 à 12:16, Pavel Sanda a écrit :
On Fri, Nov 10, 2023 at 10:55:56AM +0100, Jean-Marc Lasgouttes wrote:
PS: I have to admit that I have a kink with weird uses of preprocessor
macros: https://gitlab.inria.fr/lasgoutt/parameters
Funny, I found # and ## operators very handy for writing
On Fri, Nov 10, 2023 at 10:55:56AM +0100, Jean-Marc Lasgouttes wrote:
> PS: I have to admit that I have a kink with weird uses of preprocessor
> macros: https://gitlab.inria.fr/lasgoutt/parameters
Funny, I found # and ## operators very handy for writing commandline
parameter parsing via simple inc
Le 09/11/2023 à 21:54, José Matos a écrit :
On Thu, 2023-11-09 at 20:34 +0100, Pavel Sanda wrote:
Looks reasonable. Pavel
I agree.
After so many dark spells I fear for Jean-Marc's sanity. :-D
You mean that I should not rewrite parts of LyX in preprocessor macros
as I intended to?
JMarc
On Thu, 2023-11-09 at 20:34 +0100, Pavel Sanda wrote:
> Looks reasonable. Pavel
I agree.
After so many dark spells I fear for Jean-Marc's sanity. :-D
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Thu, Nov 09, 2023 at 06:21:03PM +0100, Jean-Marc Lasgouttes wrote:
> Thoughts?
Looks reasonable. Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
care anymore (despite of ongoing grivance from other projects).
So the most appropriate response from our side seems to be just disable this
warning...
Here is a new version of the patch that
* is more readable in the sources (+1),
* handles the three functions that cause trouble (+1),
* can be
On Wed, Nov 08, 2023 at 06:09:44PM +0100, Jean-Marc Lasgouttes wrote:
> Le 22/11/2022 ?? 03:04, Pavel Sanda a écrit :
> >On Tue, Nov 22, 2022 at 01:47:26AM +, José Matos wrote:
> >>On Mon, 2022-11-21 at 23:08 +0100, Pavel Sanda wrote:
> >>>Can you try whether the attached changes anything? P
>
: Wed, 8 Nov 2023 18:07:14 +0100
Subject: [PATCH] Avoid dangling-reference warning with theFontMetrics()
---
src/frontends/FontMetrics.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/frontends/FontMetrics.h b/src/frontends/FontMetrics.h
index f3952706ae..1647552def 100644
--- a
On Wed, Oct 18, 2023 at 02:05:51AM +, Isaac Oscar Gariano wrote:
So sorry about that, I should really have looked at the issue tracker.
But yes, it will probably break lots of pre-existing documents. So I've
uploaded a new version of my patch that is backwards compatible.
I'
command, you can just put
\let\mycommand=\undefined in your LaTeX preamble, although with
unicode-math I often have to put this in an \AtBeginDocument).
This very simple patch just makes LyX always output \newcommandx
instead of \def for math macros.
Unfortunately, this means if you want to have
On Wed, Oct 18, 2023 at 03:35:33PM +, Isaac Oscar Gariano wrote:
> The new.lyx and renew.lyx files won't load if you haven't applied my patch to
> the master branch and recompiled lyx.
>
> The def.lyx file should however not require my patch (at least on the vers
The new.lyx and renew.lyx files won't load if you haven't applied my patch to
the master branch and recompiled lyx.
The def.lyx file should however not require my patch (at least on the version
of master I had checked out)
And if you're happy to handle the tests, that would be
1 - 100 of 1052 matches
Mail list logo
