Re: Primes and superscripts in mathed
Personally, I just don't use the ' in LyX at all, especially as it doesn't
display correctly, and as you show, doesn't combine properly with other
superscripts/subscripts.
Instead, I always do ^\prime which looks much nicer, and lets you control
things better.
So perhaps the code would work better if it just made ' autocorrect to
^\prime ?
(In fact I've defined my own \pri command which alters the LaTeX height of the
\prime to one I like more; and ones that use the unicode-math multi-prime
commands \dprime, \tprime, and \qprime).
— Isaac Oscar Gariano
From: lyx-devel on behalf of Andrew Parsloe
Sent: Monday, 27 November 2023 10:10 AM
To: LyX Developers
Subject: Primes and superscripts in mathed
TeX accepts S'^{2} (between $ delimiters) as a valid construction (TeXbook,
p.130, line above Ex. 16.5) but mathed in LyX converts this to S'{}^{2}. In
this simple case that is not a problem (in fact the interpolated {} gives
better spacing) but it becomes a problem with expressions like (real-life
example)
S'^{\,-1}_{0i} or S_{0i}'^{\,-1}
These compile fine in TeX and display as desired but mathed turns them into
S'{}_{0i}^{\,-1} and S_{0i}'{}^{\,-1}
which give very different and clearly wrong results in the pdf.
The combination of a prime followed by a superscript seems a sufficiently basic
sequence to me that I think mathed should handle it with more finesse than
immediately and always inserting an empty brace pair between ' and ^.
[[Speculation: I don't know the code but perhaps the problem is that mathed
insists on subscript preceding superscript when both are involved in a symbol?
R^{ij}_{kl} in mathed becomes R_{kl}^{ij}, and inserting a prime as in
R'_{kl}^{ij} then produces the double superscript error. In contrast,
R_{kl}'^{ij} does not. TeX accepts the '^ combination and I think mathed should
do so too.]]
Andrew
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX features/biginset] Reduce metrics updates from 4 to 1 when loading file
On 11/26/23 16:07, Jean-Marc Lasgouttes wrote: Le 24/11/2023 à 21:03, Scott Kostyshak a écrit : Since such changes can lead to nasty bugs, my plan was to backport only part of the biginset branch (or maybe by bit in different 2.4 releases). But if we feel brave, we can put it all in the 2.4.x branch and see what works or not before release. We have time for that any way, but everything that touches events is very brittle. Do I understand correctly that this patch is pretty small? And that it would be easy to revert? If so, it might indeed be nice to put it in 2.4.x so that it gets tested. Note first that this change is much less jaw-dropping that the change that makes SinglePar update work in insets. I have been disappointed not to notice the difference in practice. Some patches in the biginset branch make computation more efficient, and I am confident about them (or at least that bugs will be easy to fix). Patches that avoid full metrics computation are different : these extra metrics computation steps have often been used as an easy (and robust but inefficient) way to fix real issues. Before removing these extra calls, one has to understand what bug they fix, and whether we can be convinced that the new code is immune to the bug. For the patch above, it might happen that it does not work on Qt6 on macOS (random example), because the events are triggered in a slightly different way. So each removal of a full metrics computation (Update::Force) is a risk. On my current TODO list I have currently: * when the cursor enters a math equation, a math toolbar is toggled and create a resize event for the workarea => solution is to do a metrics computation only if the width has changed (DONE, seems to work) * when the cursor enters a math equation, metrics may change if there was a preview, so that an unconditional metrics computation is done => solution is to do this only when there was actually a preview, and then only do a SinglePar update (TODO) * when the cursor leaves the math equation, same as above * when the cursor leaves the math equation and there is an error with the preview snippet, there is still a full metrics update => solution is to avoid the metrics update if the preview has not been loaded (to investigate) * when clicking in a nested inset, there is a full metrics update (to investigate) As you see there are tons of such situations, and it will not be possible to backport all the fixes for those to 2.4.x Indeed, and understood. What we can borrow, though, will be welcome. Obviously, you know this code better than anyone, so it'll largely be your call. Commits early in a cycle will give us the best chance to test. I tend to use current stable for my day to day work, and that often does involve math insets. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Primes and superscripts in mathed
TeX accepts S'^{2} (between $ delimiters) as a valid construction
(TeXbook, p.130, line above Ex. 16.5) but mathed in LyX converts this to
S'{}^{2}. In this simple case that is not a problem (in fact the
interpolated {} gives better spacing) but it becomes a problem with
expressions like (real-life example)
S'^{\,-1}_{0i} or S_{0i}'^{\,-1}
These compile fine in TeX and display as desired but mathed turns them into
S'{}_{0i}^{\,-1} and S_{0i}'{}^{\,-1}
which give very different and clearly wrong results in the pdf.
The combination of a prime followed by a superscript seems a
sufficiently basic sequence to me that I think mathed should handle it
with more finesse than immediately and always inserting an empty brace
pair between ' and ^.
[[Speculation: I don't know the code but perhaps the problem is that
mathed insists on subscript preceding superscript when both are involved
in a symbol? R^{ij}_{kl} in mathed becomes R_{kl}^{ij}, and inserting a
prime as in R'_{kl}^{ij} then produces the double superscript error. In
contrast, R_{kl}'^{ij} does not. TeX accepts the '^ combination and I
think mathed should do so too.]]
Andrew
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX features/biginset] Reduce metrics updates from 4 to 1 when loading file
Le 24/11/2023 à 21:03, Scott Kostyshak a écrit : Since such changes can lead to nasty bugs, my plan was to backport only part of the biginset branch (or maybe by bit in different 2.4 releases). But if we feel brave, we can put it all in the 2.4.x branch and see what works or not before release. We have time for that any way, but everything that touches events is very brittle. Do I understand correctly that this patch is pretty small? And that it would be easy to revert? If so, it might indeed be nice to put it in 2.4.x so that it gets tested. Note first that this change is much less jaw-dropping that the change that makes SinglePar update work in insets. I have been disappointed not to notice the difference in practice. Some patches in the biginset branch make computation more efficient, and I am confident about them (or at least that bugs will be easy to fix). Patches that avoid full metrics computation are different : these extra metrics computation steps have often been used as an easy (and robust but inefficient) way to fix real issues. Before removing these extra calls, one has to understand what bug they fix, and whether we can be convinced that the new code is immune to the bug. For the patch above, it might happen that it does not work on Qt6 on macOS (random example), because the events are triggered in a slightly different way. So each removal of a full metrics computation (Update::Force) is a risk. On my current TODO list I have currently: * when the cursor enters a math equation, a math toolbar is toggled and create a resize event for the workarea => solution is to do a metrics computation only if the width has changed (DONE, seems to work) * when the cursor enters a math equation, metrics may change if there was a preview, so that an unconditional metrics computation is done => solution is to do this only when there was actually a preview, and then only do a SinglePar update (TODO) * when the cursor leaves the math equation, same as above * when the cursor leaves the math equation and there is an error with the preview snippet, there is still a full metrics update => solution is to avoid the metrics update if the preview has not been loaded (to investigate) * when clicking in a nested inset, there is a full metrics update (to investigate) As you see there are tons of such situations, and it will not be possible to backport all the fixes for those to 2.4.x JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: flatpak
Op 26-11-2023 om 05:48 schreef Richard Kimberly Heck: It's fine to edit lyxrc.defaults, I think. This is basically a normal thing for distributions to do, though there may be some better way to do it. Perhaps someone else will know. I use lyxrc.dist for distribution specific settings. Cor -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: flatpak
In fact, I am doing a more exhaustive search, but I think one of the problems is that the configuration avoids making system calls to open a file because in the system scan it did not find a program that could manage it. El sáb, 25 nov 2023 a la(s) 23:48, Richard Kimberly Heck (rikih...@gmail.com) escribió: > On 11/25/23 23:03, T Rex wrote: > > I have sent the add request to flathub. The compilations I have made have > been successful, however I have had to make some unexpected maneuvers to > allow the program to function correctly, such as editing lyxrc.defaults. I > don't know if there is a better way. Without the modification the buttons > to build and view are blocked. > Here you can find the manifest and other files: > https://github.com/bztd/flathub/tree/org.lyx.LyX > I remain attentive to any ideas, suggestions or opinions. > > It's fine to edit lyxrc.defaults, I think. This is basically a normal > thing for distributions to do, though there may be some better way to do > it. Perhaps someone else will know. > > What changes did you make, out of curiosity? > > Riki > > > > El vie, 24 nov 2023 a la(s) 13:33, T Rex (sixpa...@gmail.com) escribió: > >> Ready, thank you very much for the prompt response, when I have a >> functional version I will submit the request and I will send the links if I >> am successful. >> >> El vie, 24 nov 2023 a la(s) 13:27, Richard Kimberly Heck ( >> rikih...@gmail.com) escribió: >> >>> On 11/24/23 11:15, T Rex wrote: >>> >>> good day everyone, my apologies in advance if this is not the correct >>> channel to do the following: as Lyx is not available on flathub, I would >>> like to create the manifest so that it is available there, in any case the >>> original sources are used, is there any Problem with performing that >>> action? >>> >>> First, the GPL license surely allows it, so long as you make the source >>> code available (which is obviously not a problem). Second, I can't imagine >>> that any of us would object. Indeed, if you do go ahead, please send us the >>> link, so we can add it to the download section of our website. >>> >>> Perhaps we should even include the manifest in our git codebase >>> somewhere? That would need a bit more discussion. >>> >>> Riki >>> >>> > -- > > Richard Kimberly (Riki) Heck > Professor of Philosophy > Brown University > > Pronouns: they/them/their > Website: http://rkheck.frege.org/ > > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
