Re: [PATCH] Make Qt6 the default

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

Re: [PATCH] Make Qt6 the default

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 file

Re: [PATCH] Make Qt6 the default

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 else than qmake. > QMake is mostly

Re: [PATCH] Make Qt6 the default

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://lists.ly

Re: patch: make a const cast explicit

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

Re: patch: make a const cast explicit

On Tue, Jul 01, 2025 at 10:37:02AM +0200, Jean-Marc Lasgouttes wrote: > Le 30/06/2025 à 23:40, Scott Kostyshak a écrit : > > Clang gives the following warning: > > > > src/frontends/qt/GuiAlert.cpp:55:33: warning: cast from 'const char *' to > > 'char *' drops const qualifier [-Wcast-qual] > >

Re: patch: make a const cast explicit

Le 30/06/2025 à 23:40, Scott Kostyshak a écrit : Clang gives the following warning: src/frontends/qt/GuiAlert.cpp:55:33: warning: cast from 'const char *' to 'char *' drops const qualifier [-Wcast-qual] 55 | QApplication app(argc, (char**)argv); |

Re: patch: include the .h file, not the .cpp file

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-devel mailing list lyx-

Re: patch: include the .h file, not the .cpp file

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

Re: patch: have configure.py print to STDOUT, not STDERR

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

Re: patch: have configure.py print to STDOUT, not STDERR

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)

Re: patch: have configure.py print to STDOUT, not STDERR

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

Re: patch: have configure.py print to STDOUT, not STDERR

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

Re: patch: have configure.py print to STDOUT, not STDERR

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: > > 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. :-) > >

Re: patch: have configure.py print to STDOUT, not STDERR

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

Re: patch: have configure.py print to STDOUT, not STDERR

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. OK by me. > Without

Re: [PATCH] Use a while() loop instead of fighting against for()

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 looking into

Re: [PATCH] Use a while() loop instead of fighting against for()

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 removing some, while a

Re: [PATCH] Use a while() loop instead of fighting against for()

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@lists.lyx.org h

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

On Fri, Oct 04, 2024 at 12:50:59AM +0200, Enrico Forestieri wrote: > On Thu, Oct 03, 2024 at 11:33:18PM +0200, Pavel Sanda wrote: > > On Thu, Oct 03, 2024 at 11:05:03PM +0200, Enrico Forestieri wrote: > > > On Thu, Oct 03, 2024 at 10:04:04PM +0200, Enrico Forestieri wrote: > > > > > > > > On Thu, O

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

On Thu, Oct 03, 2024 at 11:33:18PM +0200, Pavel Sanda wrote: On Thu, Oct 03, 2024 at 11:05:03PM +0200, Enrico Forestieri wrote: On Thu, Oct 03, 2024 at 10:04:04PM +0200, Enrico Forestieri wrote: > > On Thu, Oct 03, 2024 at 03:57:56PM +0200, Pavel Sanda wrote: > > On Thu, Oct 03, 2024 at 01:35:55

Re: [patch] Removal of strfwd.h

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

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

On Thu, Oct 03, 2024 at 11:05:03PM +0200, Enrico Forestieri wrote: > On Thu, Oct 03, 2024 at 10:04:04PM +0200, Enrico Forestieri wrote: > > > > 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 a

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

On Thu, Oct 03, 2024 at 10:04:04PM +0200, Enrico Forestieri wrote: 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:

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

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

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

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

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

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 '

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

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' CXX tr

Re: [patch] Removal of strfwd.h (was: When to use strfwd.h)

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? > > > > > > From what I see it might do more

Re: [PATCH] WIP: rewrite statistics code

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 before > > calling > > updatemacr

Re: [PATCH] WIP: rewrite statistics code

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

Re: [PATCH] WIP: rewrite statistics code

On Wed, Jul 24, 2024 at 06:09:38PM +0200, Jean-Marc Lasgouttes wrote: > > > 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 ;)

Re: [PATCH] WIP: rewrite statistics code

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

Re: [PATCH] WIP: rewrite statistics code

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

Re: [PATCH] WIP: rewrite statistics code

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 time, the code is now in. When compili

Re: [PATCH] WIP: rewrite statistics code

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/ly

Re: [PATCH] WIP: rewrite statistics code

Le 24/07/2024 à 12:30, Jean-Marc Lasgouttes a écrit : 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. A

Re: [PATCH] WIP: rewrite statistics code

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

Re: [PATCH] WIP: rewrite statistics code

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

Re: [PATCH] WIP: rewrite statistics code

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 "only" a 3x s

Re: [PATCH] WIP: rewrite statistics code

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 this speed up was go

Re: [PATCH] WIP: rewrite statistics code

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

Re: [PATCH] use yellow background for math comments

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

Re: [PATCH] use yellow background for math comments

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

Re: [PATCH] use yellow background for math comments

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 LaTeX)

Re: [PATCH] use yellow background for math comments

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 as Notes (the output actu

Re: [PATCH] Re: New warning (or at least I only noticed it now)

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

Re: [PATCH] Re: New warning (or at least I only noticed it now)

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

Re: [PATCH] Re: New warning (or at least I only noticed it now)

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

Re: [PATCH] Re: New warning (or at least I only noticed it now)

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

Re: [PATCH] Re: New warning (or at least I only noticed it now)

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

Re: [PATCH] Re: New warning (or at least I only noticed it now)

Le 08/11/2023 à 22:50, Pavel Sanda a écrit : We have to do something for this annoying warning. What about the following? If it works why not. I stopped following that gcc bug, but last time I looked they gcc devs seemed convinced that false-positive ratio is small enough that they will not car

Re: [PATCH] Re: New warning (or at least I only noticed it now)

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 >

Re: [PATCH] Always use \newcommandx instead of \def

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've added a chec

Re: [PATCH] Always use \newcommandx instead of \def

On 10/17/23 14:50, Enrico Forestieri wrote: On Tue, Oct 17, 2023 at 08:29:12PM +0200, Enrico Forestieri wrote: On Tue, Oct 17, 2023 at 01:10:23PM -0400, Richard Kimberly Heck wrote: On 10/16/23 21:22, Isaac Oscar Gariano wrote: Currently \def is used for all math macros that have no option a

Re: [PATCH] Always use \newcommandx instead of \def

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 version > of master I had checke

Re: [PATCH] Always use \newcommandx instead of \def

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 great. I should

Re: [PATCH] Always use \newcommandx instead of \def

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 >

Re: [PATCH] Always use \newcommandx instead of \def

7;re redefining math commands defined by unicode-math. — Isaac Oscar Gariano​ From: lyx-devel on behalf of Enrico Forestieri Sent: Wednesday, 18 October 2023 7:50 AM To: lyx-devel@lists.lyx.org Subject: Re: [PATCH] Always use \newcommandx instead of \def

Re: [PATCH] Always use \newcommandx instead of \def

On Tue, Oct 17, 2023 at 08:29:12PM +0200, Enrico Forestieri wrote: On Tue, Oct 17, 2023 at 01:10:23PM -0400, Richard Kimberly Heck wrote: On 10/16/23 21:22, Isaac Oscar Gariano wrote: Currently \def is used for all math macros that have no option arguments. This has caused me hard to debug er

Re: [PATCH] Always use \newcommandx instead of \def

On Tue, Oct 17, 2023 at 01:10:23PM -0400, Richard Kimberly Heck wrote: On 10/16/23 21:22, Isaac Oscar Gariano wrote: Currently \def is used for all math macros that have no option arguments. This has caused me hard to debug errors because it silently clobbers pre-existing LaTeX commands. On th

Re: [PATCH] Always use \newcommandx instead of \def

On 10/16/23 21:22, Isaac Oscar Gariano wrote: Currently \def is used for all math macros that have no option arguments. This has caused me hard to debug errors because it silently clobbers pre-existing LaTeX commands. On the other hand, \newcommandx is used if there are optional arguments, and

Re: [PATCH] Always use \newcommandx instead of \def

On Tue, Oct 17, 2023 at 01:22:26AM +, Isaac Oscar Gariano wrote: > Currently \def is used for all math macros that have no option arguments. > This has caused me hard to debug errors because it silently clobbers > pre-existing LaTeX commands. On the other hand, \newcommandx is used if there

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

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

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

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. > > > > The result is a more ple

Re: [PATCH] Making Update::SinglePar work inside insets

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

Re: [PATCH] Making Update::SinglePar work inside insets

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 is

Re: [PATCH] Making Update::SinglePar work inside insets

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 t

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

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. The result is a more pleasing editing process (IMO) and a simplification of the documentation. It is

Re: [PATCH] Making Update::SinglePar work inside insets

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. JMarc From f17ff420bfa7c2390776023c566c4974ea612f28 Mon Sep 17 00:00:00 2001 From

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

On Tue, 18 Jul 2023 at 16:55, Jean-Marc Lasgouttes wrote: > Le 18/07/2023 à 16:47, Thibaut Cuvelier a écrit : > > On Tue, 18 Jul 2023 at 16:04, Jean-Marc Lasgouttes > > wrote: > > > > Le 18/07/2023 à 15:54, Thibaut Cuvelier a écrit : > > > Also, we already hav

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

Le 18/07/2023 à 16:47, Thibaut Cuvelier a écrit : On Tue, 18 Jul 2023 at 16:04, Jean-Marc Lasgouttes > wrote: Le 18/07/2023 à 15:54, Thibaut Cuvelier a écrit : > Also, we already have macros with parameters: > https://github.com/cburschka/lyx/blob/master/

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

On Tue, 18 Jul 2023 at 16:04, Jean-Marc Lasgouttes wrote: > Le 18/07/2023 à 15:54, Thibaut Cuvelier a écrit : > > Also, we already have macros with parameters: > > https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223 > > >

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

Le 18/07/2023 à 15:54, Thibaut Cuvelier a écrit : Also, we already have macros with parameters: https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223 Indeed. I'm the one who pushed that, but it did not impress me at the

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

On Tue, 18 Jul 2023 at 15:45, Jean-Marc Lasgouttes wrote: > Le 18/07/2023 à 15:36, Thibaut Cuvelier a écrit : > > For the symbols in your patch, yes, export is currently broken, but it's > > fixable. > > I think it would still be fixable in the future with macros, as I did in > > https://github.c

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

Le 18/07/2023 à 15:36, Thibaut Cuvelier a écrit : For the symbols in your patch, yes, export is currently broken, but it's fixable. I think it would still be fixable in the future with macros, as I did in https://github.com/cburschka/lyx/blob/master/lib/symbols#L1128

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

On Tue, 18 Jul 2023 at 15:11, Jean-Marc Lasgouttes wrote: > 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. > > The result is a more pleasing editing process (IMO) and a simplification > of the documentat

Re: [PATCH] Making Update::SinglePar work inside insets

On Mon, Jul 17, 2023 at 11:19:22PM +0200, Jean-Marc Lasgouttes wrote: > What I cannot fix easily, though is that if I insert characters just before > the branch (in same paragraph), things are ugly again because the whole > branch has to be typeset again and again. Indeed, that is still slow. In a

Re: [PATCH] Making Update::SinglePar work inside insets

Le 17/07/2023 à 18:00, Scott Kostyshak a écrit : On Mon, Jul 17, 2023 at 04:03:32PM +0200, Jean-Marc Lasgouttes wrote: Hello, This patch tries to address #12297, where typing in the big branch in the attached big-inset.23.lyx file is painfully slow. Works well! I just did some brief testing.

Re: [PATCH] Making Update::SinglePar work inside insets

On Mon, Jul 17, 2023 at 04:03:32PM +0200, Jean-Marc Lasgouttes wrote: > Hello, > > This patch tries to address #12297, where typing in the big branch in the > attached big-inset.23.lyx file is painfully slow. > > To this end, I made BufferView::singleParUpdate, and the result looks great. > Since

Re: [PATCH] "Here Applies" module

On Fri, May 05, 2023 at 12:18:32PM -0400, Richard Kimberly Heck wrote: > On 5/2/23 11:38, madmurphy wrote: > > The hereapplies LaTeX package has > > stably been part of the CTAN repository for a while now, and a LyX > > module > >

Re: [PATCH] "Here Applies" module

On 5/2/23 11:38, madmurphy wrote: The hereapplies LaTeX package has stably been part of the CTAN repository for a while now, and a LyX module is shipped with it. Will it be possible to

Re: [PATCH] "Here Applies" module

The hereapplies LaTeX package has stably been part of the CTAN repository for a while now, and a LyX module is shipped with it. Will it be possible to include the module among the modules i

Re: Patch to delete the iopart, kluwer and svjog layouts and edit Makefile.am as the relevant cls files have not been available for several years

On Wed, Jan 04, 2023 at 12:12:39PM +, John Robert Hudson wrote: > From 673a7b1786ecaea775d10ad9751a8630ab844b10 Mon Sep 17 00:00:00 2001 > From: John R Hudson > Date: Wed, 4 Jan 2023 12:08:23 + > Subject: [PATCH] Delete iopart, kluwer and svjog layouts as the relevant cls > files have no

Re: Patch to insert brief introduction to Chapter 3 Document classes and update the AMS document classes section of Additional.lyx to reflect changes in 2.4

Am Donnerstag, dem 29.12.2022 um 20:38 + schrieb John Robert Hudson: > Please note that the Fact environment has moved from the (Extended) > to the > basic module and that the Assumption and Question environments are > new to the > (Extended) module and so have no proper descriptions in the o

Re: Patch to insert entries for Hanging Paragraphs, Initials, Hyphenatable Text Markup and Logical Markup into Chapter 4 Modules of Additional.lyx

Committed. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patch to insert entries for Custom Header/Footer Text and Landscape Document Mode and to update the existing entry for Multiple Columns to reflect the new layout in Chapter 4 Modules of Additional

Committed. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Patch to insert entries for the sixteen Maths modules into Chapter 4 Modules of Additional.lyx

On Wed, Dec 28, 2022 at 11:42:14AM +, John Robert Hudson wrote: > So, after the last two sections are in, I will go through these chapter by > chapter in Additional.lyx and then propose the updates needed in the other > Manuals. > > So I will hold off until the weekend. No need to postpone,

Re: Patch to insert entries for the sixteen Maths modules into Chapter 4 Modules of Additional.lyx

On Wednesday, 28 December 2022 11:24:21 GMT you wrote: > On Wed, Dec 28, 2022 at 11:00:28AM +, John Robert Hudson wrote: > > From dbce16010232e8774e747692bbbc78fd00c7c120 Mon Sep 17 00:00:00 2001 > > From: John R Hudson > > Date: Wed, 28 Dec 2022 10:56:30 + > > Subject: [PATCH] Insert entr

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

On Sun, 2022-12-04 at 22:14 +0100, Jean-Marc Lasgouttes wrote: > > On the other hand I was concerned with encoding a text message in > > integer number that in Python is infinite precision: > > You lost me here. > > JMarc That is a way to pass a a light message (season's greetings) into a seriou

Re: Patch to insert short updated entries for Dinbrief, Elsevier, Paper and Springer in Chapter 3 Document classes of Additional.lyx

Dr Eberhard W Lisse schrieb am 14.12.2022 22:29 (GMT +01:00): > As a German Speaker I would propose to remove Dinbrief altogether as > Koma-Script's Letter (scrlttr2) is not only DIN 5008 compatible but also > offers much, much more possibilities. > > And according to Ulrike Fischer dinbrief is n

Re: Patch to insert short updated entries for Dinbrief, Elsevier, Paper and Springer in Chapter 3 Document classes of Additional.lyx

As a German Speaker I would propose to remove Dinbrief altogether as Koma-Script's Letter (scrlttr2) is not only DIN 5008 compatible but also offers much, much more possibilities. And according to Ulrike Fischer dinbrief is not compatible with current LaTeX anyway. greetings, el On 14/12/2022 20

Re: Patch to remove Kluwer from Additional.lyx

On Wed, Dec 07, 2022 at 05:42:20PM +0100, Jürgen Spitzmüller wrote: > Am Dienstag, dem 06.12.2022 um 22:25 -0500 schrieb Scott Kostyshak: > > Not sure if any better, but perhaps an alternative: could lyx2lyx > > just copy the module into the local layout? That is, the module could > > be hidden som

  1   2   3   4   5   6   7   8   9   10   >