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
On Wed, Oct 18, 2023 at 02:05:51AM +, Isaac Oscar Gariano wrote:
> I've attached three example lyx files that try and redefine the \section
> command; the only difference between def.lyx and new.lyx is whether the
> checkbox is checked or not; renew.lyx shows how to suecesfully do the
>
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've added a checkbox at the bottom of Document Settings -> Math Options t
=\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 any math macros
you'll always nee
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 any math macros you'll
always need the xargs package (but it's a small package release all
they w
this gives a helpful
error message if the command is already defined. (if you really do
want to override the 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
n 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 any math macros you'll always
> need the xargs package (but it's a small package release a
command is already
defined. (if you really do want to override the 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
Thanks for looking at my patch!
I'm happy to add a simple "Refresh" button to the "Document Settings -> Module"
window if you think this would be a good idea?
— Isaac Oscar Gariano
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Wed, Oct 11, 2023 at 04:17:30PM +0200, Thibaut Cuvelier wrote:
> On Wed, 11 Oct 2023 at 11:03, Pavel Sanda wrote:
>
> > On Tue, Oct 10, 2023 at 02:38:01PM +0200, Jürgen Spitzmüller wrote:
> > >> 4) *lot* of latex packages
> > > All we query is needed for something for sure.
> >
> > Let's stick
On Wed, 11 Oct 2023 at 11:03, Pavel Sanda wrote:
> On Tue, Oct 10, 2023 at 02:38:01PM +0200, Jürgen Spitzmüller wrote:
> >> 4) *lot* of latex packages
> > All we query is needed for something for sure.
>
> Let's stick with point 4.
>
> By *needed* you mean that we have e.g. some specific feature
On Tue, Oct 10, 2023 at 02:38:01PM +0200, Jürgen Spitzmüller wrote:
>> 4) *lot* of latex packages
> All we query is needed for something for sure.
Let's stick with point 4.
By *needed* you mean that we have e.g. some specific feature requiring it for
proper typesetting (I agree with that) or that
Am Dienstag, dem 10.10.2023 um 14:27 +0200 schrieb Pavel Sanda:
> As I see we do:
> 2) Indexing cls/sty/bst/bib/bbx/cbx (do we need those for something?)
Yes, (bib)latex settings for bst/bib/bbx/cbx. Package/class
availability for the others.
> 6) checking fonts (do we actually use those for sett
On Tue, Oct 10, 2023 at 10:31:12AM +0100, José Matos wrote:
> OTHO IMHO (I am missing other acronyms to add) this does not need to be
> accessible through the GUI. Most of the time you want the default
> procedure, it is slow but it does what you want.
We might take this thread as an oportunity to
Am Dienstag, dem 10.10.2023 um 10:31 +0100 schrieb José Matos:
> The use of these options inside LyX should depend on the actual
> context. That would mean that in your particular case the option to
> only rebuild the modules part should be in the modules related
> interface.
Yes, and ideally it s
On Mon, 2023-10-09 at 07:36 +, Isaac Oscar Gariano wrote:
> > It would be nice to be able to select these options from the GUI
> > when
> > you click the reconfigure button, so if someone familiar with the
> > GUI
> > code can do that, it would be very helpfull!
> >
> >
> > — Isaac Oscar Gari
Hey,
So it was annoying me that I every time I added a new module or layout file, I
have to reconfigure lyx, but this is quite slow. On my (admittedly slow) system
it takes about 40 seconds. I noticed the configure.py script itself has some
command line options to make it faster, so when I run
On Sat, 22 Jul 2023 at 00:00, Jean-Marc Lasgouttes
wrote:
> Le 18/07/2023 à 15:11, Jean-Marc Lasgouttes a écrit :
> > Hello,
> >
> > In the attached patch, I am able to support the mod/bmod/pmod/pod macros
> > by just defining them in lib/symbols with an argument.
&
Le 23/07/2023 à 02:40, Richard Kimberly Heck a écrit :
I was hoping to go to RC1 pretty soon, so it might not be the right time
for that.
We might go ahead and branch 2.5.0dev once RC1 is out.
Fine with me.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman
On 7/22/23 18:01, Jean-Marc Lasgouttes wrote:
Le 18/07/2023 à 20:50, Jean-Marc Lasgouttes a écrit :
Le 17/07/2023 à 23:19, Jean-Marc Lasgouttes a écrit :
It worked well until one tries to use mathed %-] Updated patch below
is better in this respect.
Err, I posted the same patch twice! Here
Le 18/07/2023 à 20:50, Jean-Marc Lasgouttes a écrit :
Le 17/07/2023 à 23:19, Jean-Marc Lasgouttes a écrit :
It worked well until one tries to use mathed %-] Updated patch below
is better in this respect.
Err, I posted the same patch twice! Here is the updated one.
The patch is now attached
1 - 100 of 1032 matches
Mail list logo
