Re: Behavior of overset inset creation on selection
On 08/11/2018 04:42, Scott Kostyshak wrote: On Wed, Nov 07, 2018 at 04:53:16PM -1000, Jean-Marc Lasgouttes wrote: Indeed, it seems to me that adding the subscript automatically is a bit too much. Not everybody wants it, after all. For some reason it doesn't work like overset. I am not sure that we should hide these differences in LyX. Makes sense. I take it that in the vast majority of cases you want underbrace with subscript. And it took me a while at the beginning to figure out how it works in LyX. I played around with underset etc. before realising that the subscript works. Knowing that from the start is tricky. And removing the subsript is very[1] simple: just move the cursor out of it. So I am still in favor of adding the subscript by default and moving the cursor into it. [1] I am wondering why a subscript is not just "unsubscripted" when backspace is pressed at the beginning of it. Maybe this is by design but I fail to see its virtues. However, one thing I noticed is that the cursor does not move to the end of a base but to its beginning when moving to the left from the beginning of a superscript. I am not sure why that is intuitive either so I suggest to change this which makes the previous suggestion consistent. Daniel
Re: Behavior of overset inset creation on selection
On Wed, Nov 07, 2018 at 04:53:16PM -1000, Jean-Marc Lasgouttes wrote: > Indeed, it seems to me that adding the subscript automatically is a bit too > much. Not everybody wants it, after all. For some reason it doesn't work like > overset. I am not sure that we should hide these differences in LyX. Makes sense. Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 7 novembre 2018 16:23:41 GMT-10:00, Scott Kostyshak a écrit : >Nice. I don't know if the following is a good idea, but why not put the >cursor into the inset of the underbrace automatically? > >For example, if I select "x" and then click on "underbrace", I have to >press "_" to be able to write text in the underbrace position. I would >personally prefer to be put directly into the text inset undert the >underbrace. > >I guess the idea of not doing that would be that some users don't >always >put text in the underbrace, so we should not assume that they want to >put text in it? Indeed, it seems to me that adding the subscript automatically is a bit too much. Not everybody wants it, after all. For some reason it doesn't work like overset. I am not sure that we should hide these differences in LyX. JMarc
Re: Behavior of overset inset creation on selection
On Tue, Nov 06, 2018 at 11:55:42PM -1000, Jean-Marc Lasgouttes wrote: > Le 06/11/2018 à 23:34, Daniel a écrit : > > Haven't followed the thread, but does this solve > > > > https://www.lyx.org/trac/ticket/10077 > > > > ? > > It looks like it does. Nice. I don't know if the following is a good idea, but why not put the cursor into the inset of the underbrace automatically? For example, if I select "x" and then click on "underbrace", I have to press "_" to be able to write text in the underbrace position. I would personally prefer to be put directly into the text inset undert the underbrace. I guess the idea of not doing that would be that some users don't always put text in the underbrace, so we should not assume that they want to put text in it? Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
On Tue, Nov 06, 2018 at 11:13:41PM -1000, Jean-Marc Lasgouttes wrote: > Le 06/11/2018 à 07:37, Scott Kostyshak a écrit : > > On Tue, Nov 06, 2018 at 07:23:19AM -1000, Jean-Marc Lasgouttes wrote: > > > Le 06/11/2018 à 07:19, Scott Kostyshak a écrit : > > > > Tested and it works well! I tested a few different "Frame decorations". > > > > I also tested writing "x" in math mode, selecting it and then writing > > > > "\cases". Now the cursor is put in the second box of cases, and I think > > > > that is nice. I like it! > > > > > > I've got to finish it, then. > > > > OK, let me know if there's anything you want me to test. > > I pushed a version that also works correctly with \stackrel (even version > with 3 arguments). > > Tell me how it fares. Tested and looks good! > I am not sure that it is 2.3 material because it moves > code around and there is potential for mistakes. Makes sense. Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 06/11/2018 à 23:34, Daniel a écrit : Haven't followed the thread, but does this solve https://www.lyx.org/trac/ticket/10077 ? It looks like it does. JMarc
Re: Behavior of overset inset creation on selection
On 30/10/2018 17:39, Scott Kostyshak wrote: On Wed, Apr 04, 2018 at 06:36:26PM +0200, Jean-Marc Lasgouttes wrote: Le 31/03/2018 à 19:49, Scott Kostyshak a écrit : To see an issue that has long annoyed me, do the following: 1. In math mode, type "=". 2. Select the "=" you just typed. 3. Choose "Overset" from the math toolbar (alternatively, just type "\overset"). The "=" is put in the "above" box, because that is the first LaTeX argument. From the user perspective, I think that putting "=" in the primary box is usually expected. For example, I think that this would be more consistent with when the user selects something and chooses "subscript". The thing selected is in the main box (it is not placed into the subscript). This patch tries to fix this. The issue is now fixed in master. I have another feature request: I think the cursor should be put in the newly created box (just like with superscript, for example). Should I make a trac ticket for this enhancement? Haven't followed the thread, but does this solve https://www.lyx.org/trac/ticket/10077 ? Daniel
Re: Behavior of overset inset creation on selection
Le 06/11/2018 à 07:37, Scott Kostyshak a écrit : On Tue, Nov 06, 2018 at 07:23:19AM -1000, Jean-Marc Lasgouttes wrote: Le 06/11/2018 à 07:19, Scott Kostyshak a écrit : Tested and it works well! I tested a few different "Frame decorations". I also tested writing "x" in math mode, selecting it and then writing "\cases". Now the cursor is put in the second box of cases, and I think that is nice. I like it! I've got to finish it, then. OK, let me know if there's anything you want me to test. I pushed a version that also works correctly with \stackrel (even version with 3 arguments). Tell me how it fares. I am not sure that it is 2.3 material because it moves code around and there is potential for mistakes. JMarc
Re: Behavior of overset inset creation on selection
On Tue, Nov 06, 2018 at 07:23:19AM -1000, Jean-Marc Lasgouttes wrote: > Le 06/11/2018 à 07:19, Scott Kostyshak a écrit : > > Tested and it works well! I tested a few different "Frame decorations". > > I also tested writing "x" in math mode, selecting it and then writing > > "\cases". Now the cursor is put in the second box of cases, and I think > > that is nice. I like it! > > I've got to finish it, then. OK, let me know if there's anything you want me to test. > Another feature: when one inserts \hat over "x", the cursor will be outside > of the newly created inset. Nice! I like that. Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 06/11/2018 à 07:19, Scott Kostyshak a écrit : Tested and it works well! I tested a few different "Frame decorations". I also tested writing "x" in math mode, selecting it and then writing "\cases". Now the cursor is put in the second box of cases, and I think that is nice. I like it! I've got to finish it, then. Another feature: when one inserts \hat over "x", the cursor will be outside of the newly created inset. JMarc
Re: Behavior of overset inset creation on selection
On Mon, Nov 05, 2018 at 09:59:04PM -1000, Jean-Marc Lasgouttes wrote: > Le 05/11/2018 à 05:43, Scott Kostyshak a écrit : > > > Please try the attached and tell me if you like it. > > > > For me it doesn't make much of a difference for the use case I > > mentioned. I now get the attached screenshot with those steps. Either > > with this patch or without this patch, I need to click (or move with > > cursor) on the box above "=" to enter "def" to get my desired output. > > I indeed forget to test the initial use case. It was not working as > intended. > > Try this pair of patch instead. The first one changes several classes so > that cell 0 is he 'main' cell. This makes many things simpler IMO. > > The second patch is the one which does the requested change. Tested and it works well! I tested a few different "Frame decorations". I also tested writing "x" in math mode, selecting it and then writing "\cases". Now the cursor is put in the second box of cases, and I think that is nice. I like it! Thanks, Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 05/11/2018 à 05:43, Scott Kostyshak a écrit : Please try the attached and tell me if you like it. For me it doesn't make much of a difference for the use case I mentioned. I now get the attached screenshot with those steps. Either with this patch or without this patch, I need to click (or move with cursor) on the box above "=" to enter "def" to get my desired output. I indeed forget to test the initial use case. It was not working as intended. Try this pair of patch instead. The first one changes several classes so that cell 0 is he 'main' cell. This makes many things simpler IMO. The second patch is the one which does the requested change. JMarc >From 61addb872c6945af4206d8bbfbd1ff6d5339fb11 Mon Sep 17 00:00:00 2001 From: Jean-Marc Lasgouttes Date: Mon, 5 Nov 2018 21:29:47 -1000 Subject: [PATCH 1/2] Change cell numbers so that 0 is the main cell This leads to code simplification in overset, root and underset. Further simplification is possible. --- src/mathed/InsetMathOverset.cpp | 43 +--- src/mathed/InsetMathOverset.h| 4 +-- src/mathed/InsetMathRoot.cpp | 23 + src/mathed/InsetMathRoot.h | 5 +--- src/mathed/InsetMathUnderset.cpp | 41 +++--- src/mathed/InsetMathUnderset.h | 6 - 6 files changed, 57 insertions(+), 65 deletions(-) diff --git a/src/mathed/InsetMathOverset.cpp b/src/mathed/InsetMathOverset.cpp index 1295685d78..b659a9eab4 100644 --- a/src/mathed/InsetMathOverset.cpp +++ b/src/mathed/InsetMathOverset.cpp @@ -19,6 +19,8 @@ #include "LaTeXFeatures.h" #include "MetricsInfo.h" +#include "support/lassert.h" + using namespace std; namespace lyx { @@ -32,14 +34,14 @@ Inset * InsetMathOverset::clone() const void InsetMathOverset::metrics(MetricsInfo & mi, Dimension & dim) const { Changer dummy2 = mi.base.changeEnsureMath(); - Dimension dim1; - cell(1).metrics(mi, dim1); - Changer dummy = mi.base.changeFrac(); Dimension dim0; cell(0).metrics(mi, dim0); - dim.wid = max(dim0.width(), dim1.wid) + 4; - dim.asc = dim1.asc + dim0.height() + 4; - dim.des = dim1.des; + Changer dummy = mi.base.changeFrac(); + Dimension dim1; + cell(1).metrics(mi, dim1); + dim.wid = max(dim1.width(), dim0.wid) + 4; + dim.asc = dim0.asc + dim1.height() + 4; + dim.des = dim0.des; } @@ -47,13 +49,24 @@ void InsetMathOverset::draw(PainterInfo & pi, int x, int y) const { Changer dummy2 = pi.base.changeEnsureMath(); Dimension const dim = dimension(*pi.base.bv); - Dimension const & dim0 = cell(0).dimension(*pi.base.bv); Dimension const & dim1 = cell(1).dimension(*pi.base.bv); + Dimension const & dim0 = cell(0).dimension(*pi.base.bv); int m = x + dim.wid / 2; - int yo = y - dim1.asc - dim0.des - 1; - cell(1).draw(pi, m - dim1.wid / 2, y); + int yo = y - dim0.asc - dim1.des - 1; + cell(0).draw(pi, m - dim0.wid / 2, y); Changer dummy = pi.base.changeFrac(); - cell(0).draw(pi, m - dim0.width() / 2, yo); + cell(1).draw(pi, m - dim1.width() / 2, yo); +} + + +bool InsetMathOverset::idxUpDown(Cursor & cur, bool up) const +{ + idx_type target = up; // up ? 1 : 0, since upper cell has idx 1 + if (cur.idx() == target) + return false; + cur.idx() = target; + cur.pos() = cur.cell().x2pos((), cur.x_target()); + return true; } @@ -62,27 +75,27 @@ void InsetMathOverset::write(WriteStream & os) const MathEnsurer ensurer(os); if (os.fragile()) os << "\\protect"; - os << "\\overset{" << cell(0) << "}{" << cell(1) << '}'; + os << "\\overset{" << cell(1) << "}{" << cell(0) << '}'; } void InsetMathOverset::normalize(NormalStream & os) const { - os << "[overset " << cell(0) << ' ' << cell(1) << ']'; + os << "[overset " << cell(1) << ' ' << cell(0) << ']'; } void InsetMathOverset::mathmlize(MathStream & ms) const { - ms << "" << cell(1) << cell(0) << ""; + ms << "" << cell(0) << cell(1) << ""; } void InsetMathOverset::htmlize(HtmlStream & os) const { os << MTag("span", "class='overset'") - << MTag("span", "class='top'") << cell(0) << ETag("span") - << MTag("span") << cell(1) << ETag("span") + << MTag("span", "class='top'") << cell(1) << ETag("span") + << MTag("span") << cell(0) << ETag("span") << ETag("span"); } diff --git a/src/mathed/InsetMathOverset.h b/src/mathed/InsetMathOverset.h index 1202bbcfd4..eb6b86b798 100644 --- a/src/mathed/InsetMathOverset.h +++ b/src/mathed/InsetMathOverset.h @@ -28,9 +28,7 @@ public: /// void draw(PainterInfo & pi, int x, int y) const; /// - idx_type firstIdx() const { return 1; } - /// - idx_type lastIdx() const { return 1; } + bool idxUpDown(Cursor & cur, bool up) const; /// void write(WriteStream & os) const; /// diff --git a/src/mathed/InsetMathRoot.cpp b/src/mathed/InsetMathRoot.cpp index 3cc8e2e1d7..b3723faca8 100644 --- a/src/mathed/InsetMathRoot.cpp +++ b/src/mathed/InsetMathRoot.cpp @@ -22,6 +22,7 @@ #include "frontends/Painter.h" +#include "support/lassert.h" using namespace std; @@ -84,7 +85,7 @@
Re: Behavior of overset inset creation on selection
On Sun, Nov 04, 2018 at 09:32:49PM -1000, Jean-Marc Lasgouttes wrote: > Le 04/11/2018 à 11:16, Scott Kostyshak a écrit : > > I see, sounds tricky. Perhaps we should leave things untouched? Would it > > be complicated to allow for the multi-cell inset to decide what the > > behavior is? I'm guessing this would be too complicated and is not the > > best use of your time, but in case I'm wrong, if you implement the > > general framework, I could take care of auditing all of the individual > > insets and also poll lyx-users to see what is the most natural to all. > > Please try the attached and tell me if you like it. For me it doesn't make much of a difference for the use case I mentioned. I now get the attached screenshot with those steps. Either with this patch or without this patch, I need to click (or move with cursor) on the box above "=" to enter "def" to get my desired output. > I think personally that it makes sense. I trust whatever you think is best. I know nothing about the inner workings of this. Thanks for your work on it. Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 04/11/2018 à 11:16, Scott Kostyshak a écrit : I see, sounds tricky. Perhaps we should leave things untouched? Would it be complicated to allow for the multi-cell inset to decide what the behavior is? I'm guessing this would be too complicated and is not the best use of your time, but in case I'm wrong, if you implement the general framework, I could take care of auditing all of the individual insets and also poll lyx-users to see what is the most natural to all. Please try the attached and tell me if you like it. I think personally that it makes sense. JMarc >From cb33b1e381d61f7373f24d825c6d9120f97c0760 Mon Sep 17 00:00:00 2001 From: Jean-Marc Lasgouttes Date: Sun, 4 Nov 2018 21:27:02 -1000 Subject: [PATCH] When inserting math inset over selection, place cursr better This is a follow up to 503c7c16. The new argument for placing cursor after insertion of inset is: * if inset has no cell, do nothing * otherwise, place inset in entry cell. + if entry cell is not empty (we pasted a selection), go to next cell + if this next cell does not exit, stay after the inset. --- src/Cursor.cpp | 52 +++- src/Cursor.h | 8 +++--- src/mathed/InsetMathNest.cpp | 12 +++-- src/mathed/InsetMathRoot.cpp | 25 + src/mathed/InsetMathRoot.h | 5 5 files changed, 71 insertions(+), 31 deletions(-) diff --git a/src/Cursor.cpp b/src/Cursor.cpp index fd43dd74eb..a6d799ec9c 100644 --- a/src/Cursor.cpp +++ b/src/Cursor.cpp @@ -901,6 +901,31 @@ void Cursor::pushBackward(Inset & p) } +void Cursor::editInsertedInset() +{ + LASSERT(!empty(), return); + if (pos() == 0) + return; + + InsetMath = prevMath(); + if (!p.isActive()) + return; + + posBackward(); + push(p); + p.idxFirst(*this); + // this could be a while() loop, but only one cell is not empty in + // cases we are interested in. The cell is not empty because we + // have inserted the selection in there. + if (!cell().empty()) { + // if it is not empty, move to the next one. + if (!inset().idxNext(*this)) + // If there is no next one, exit the inset. + popForward(); + } +} + + bool Cursor::popBackward() { LASSERT(!empty(), return false); @@ -1521,14 +1546,9 @@ void Cursor::niceInsert(MathAtom const & t) plainInsert(t); // If possible, enter the new inset and move the contents of the selection if (t->isActive()) { - posBackward(); - // be careful here: don't use 'pushBackward(t)' as this we need to - // push the clone, not the original - pushBackward(*nextInset()); - // We may not use niceInsert here (recursion) - MathData ar(buffer()); - asArray(safe, ar); - insert(ar); + idx_type const idx = prevMath().asNestInset()->firstIdx(); + asArray(safe, prevMath().cell(idx)); + editInsertedInset(); } else if (t->asMacro() && !safe.empty()) { MathData ar(buffer()); asArray(safe, ar); @@ -1665,20 +1685,14 @@ bool Cursor::down() } -void Cursor::handleNest(MathAtom const & a, int c) +void Cursor::handleNest(MathAtom const & a) { - //lyxerr << "Cursor::handleNest: " << c << endl; + idx_type const idx = a.nucleus()->asNestInset()->firstIdx(); + //lyxerr << "Cursor::handleNest: " << idx << endl; MathAtom t = a; - asArray(cap::grabAndEraseSelection(*this), t.nucleus()->cell(c)); + asArray(cap::grabAndEraseSelection(*this), t.nucleus()->cell(idx)); insert(t); - posBackward(); - pushBackward(*nextInset()); -} - - -void Cursor::handleNest(MathAtom const & a) -{ - handleNest(a, a.nucleus()->asNestInset()->firstIdx()); + editInsertedInset(); } diff --git a/src/Cursor.h b/src/Cursor.h index 2985543a44..f3acd9909f 100644 --- a/src/Cursor.h +++ b/src/Cursor.h @@ -259,6 +259,10 @@ public: void push(Inset & inset); /// add a new cursor slice, place cursor at front (move backwards) void pushBackward(Inset & inset); + /// try to put cursor in inset before it in entry cell, or next one + /// if it is not empty, or exit the slice if there is no next one. + void editInsertedInset(); + /// pop one level off the cursor void pop(); /// pop one slice off the cursor stack and go backwards @@ -517,13 +521,9 @@ public: /// the name of the macro we are currently inputting docstring macroName(); - /// replace selected stuff with at, placing the former // selection in entry cell of atom void handleNest(MathAtom const & at); - /// replace selected stuff with at, placing the former - // selection in given cell of atom - void handleNest(MathAtom const & at, int cell); /// make sure cursor position is valid /// FIXME: It does a subset of fixIfBroken. Maybe merge them? diff --git a/src/mathed/InsetMathNest.cpp b/src/mathed/InsetMathNest.cpp index 35f28e95c0..857fd7f87e 100644 --- a/src/mathed/InsetMathNest.cpp +++ b/src/mathed/InsetMathNest.cpp @@ -873,14 +873,10 @@ void InsetMathNest::doDispatch(Cursor & cur, FuncRequest & cmd) // via macro mode, we want to put the cursor inside it // if relevant. Think typing "\frac".
Re: Behavior of overset inset creation on selection
On Sun, Nov 04, 2018 at 08:42:42AM -1000, Jean-Marc Lasgouttes wrote: > Le 04/11/2018 à 18:38, Scott Kostyshak a écrit : > > > OK, so you would like to put the selection contents to the first cell, but > > > the cursor in the next one. Is that right? > > > > Yes, that is the most natural to me as a user. From the technical > > perspective (in the way you describe), it does appear unintuitive. From > > the user perspective, to me it is the same as starting a super-script > > and naturally wanting to fill in the super-script after creating it. > > Note that, if I do that, it will not only be for overset, but all multi-cell > insets. And for 1-cell inset, the cursor will be after the inset (as now > when we create a Note inset from a selection). I see, sounds tricky. Perhaps we should leave things untouched? Would it be complicated to allow for the multi-cell inset to decide what the behavior is? I'm guessing this would be too complicated and is not the best use of your time, but in case I'm wrong, if you implement the general framework, I could take care of auditing all of the individual insets and also poll lyx-users to see what is the most natural to all. I'm open to whatever you suggest, but I have a feeling it might be best to mark my request as "wontfix". Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 04/11/2018 à 18:38, Scott Kostyshak a écrit : OK, so you would like to put the selection contents to the first cell, but the cursor in the next one. Is that right? Yes, that is the most natural to me as a user. From the technical perspective (in the way you describe), it does appear unintuitive. From the user perspective, to me it is the same as starting a super-script and naturally wanting to fill in the super-script after creating it. Note that, if I do that, it will not only be for overset, but all multi-cell insets. And for 1-cell inset, the cursor will be after the inset (as now when we create a Note inset from a selection). JMarc
Re: Behavior of overset inset creation on selection
On Sun, Nov 04, 2018 at 08:07:51AM -1000, Jean-Marc Lasgouttes wrote: > Le 04/11/2018 à 17:58, Scott Kostyshak a écrit : > > If I do the following steps: > > > > 1. In math mode, type "=". > > 2. Select the "=" you just typed. > > 3. Choose "Overset" from the math toolbar (alternatively, just type > > "\overset"). > > 4. Type "def". > > > > OK, so you would like to put the selection contents to the first cell, but > the cursor in the next one. Is that right? Yes, that is the most natural to me as a user. From the technical perspective (in the way you describe), it does appear unintuitive. From the user perspective, to me it is the same as starting a super-script and naturally wanting to fill in the super-script after creating it. I wonder what others think? Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 04/11/2018 à 17:58, Scott Kostyshak a écrit : If I do the following steps: 1. In math mode, type "=". 2. Select the "=" you just typed. 3. Choose "Overset" from the math toolbar (alternatively, just type "\overset"). 4. Type "def". OK, so you would like to put the selection contents to the first cell, but the cursor in the next one. Is that right? JMarc
Re: Behavior of overset inset creation on selection
Le 30/10/2018 à 16:39, Scott Kostyshak a écrit : The issue is now fixed in master. I have another feature request: I think the cursor should be put in the newly created box (just like with superscript, for example). Should I make a trac ticket for this enhancement? I am not sure of what you mean. The cursor goes into the inset, doesn't it? Is it a metter of being at the end of the cell? JMarc
Re: Behavior of overset inset creation on selection
On Wed, Apr 04, 2018 at 06:36:26PM +0200, Jean-Marc Lasgouttes wrote: > Le 31/03/2018 à 19:49, Scott Kostyshak a écrit : > > To see an issue that has long annoyed me, do the following: > > > > 1. In math mode, type "=". > > 2. Select the "=" you just typed. > > 3. Choose "Overset" from the math toolbar (alternatively, just type > > "\overset"). > > > > The "=" is put in the "above" box, because that is the first LaTeX > > argument. From the user perspective, I think that putting "=" in the > > primary box is usually expected. For example, I think that this would be > > more consistent with when the user selects something and chooses > > "subscript". The thing selected is in the main box (it is not placed > > into the subscript). > This patch tries to fix this. The issue is now fixed in master. I have another feature request: I think the cursor should be put in the newly created box (just like with superscript, for example). Should I make a trac ticket for this enhancement? Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Am Montag, 9. April 2018 17:38:37 CEST schrieb Jean-Marc Lasgouttes: > Le 09/04/2018 à 17:10, Kornel Benko a écrit : > > Instead of searching for the biggest char in an inset, we could always use > > 'f'. Am I missing something? > > I am not really searching for the biigest char. The fact is, that for > example $\sqrt{a}$ does not have the same height as $\sqrt{f}$. I do not > know yet what are the cases where the height of a formula can be smaller > than the full height. > > See for example the attached file. For the first formula, LyX does the > right thing. This means that for the first fraction, the top cell has a > null descent, and therefore the blinking cursor should do the same. > > Note that in the second formula LyX is wrong. The ascent of the bottom > cell in the first fraction should be the same as with the other bottom > cells. I have to fix it one day. I see. > What I mean here is that the height of a cell is not always the height > of $f$. I have to see whether I adapt the cursor height to this case. > > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: Behavior of overset inset creation on selection
Le 09/04/2018 à 17:10, Kornel Benko a écrit : Instead of searching for the biggest char in an inset, we could always use 'f'. Am I missing something? I am not really searching for the biigest char. The fact is, that for example $\sqrt{a}$ does not have the same height as $\sqrt{f}$. I do not know yet what are the cases where the height of a formula can be smaller than the full height. See for example the attached file. For the first formula, LyX does the right thing. This means that for the first fraction, the top cell has a null descent, and therefore the blinking cursor should do the same. Note that in the second formula LyX is wrong. The ascent of the bottom cell in the first fraction should be the same as with the other bottom cells. I have to fix it one day. What I mean here is that the height of a cell is not always the height of $f$. I have to see whether I adapt the cursor height to this case. JMarc newfile1.lyx Description: application/lyx
Re: Behavior of overset inset creation on selection
Am Montag, 9. April 2018 16:39:19 CEST schrieb Jean-Marc Lasgouttes: > Le 09/04/2018 à 16:17, Pavel Sanda a écrit : > > The current master situation seems indeed the best from all the patches > > I've been testing so far. > > But shouldn't $a$ have the same cursor as $f$? > > JMarc Instead of searching for the biggest char in an inset, we could always use 'f'. Am I missing something? Kornel signature.asc Description: This is a digitally signed message part.
Re: Behavior of overset inset creation on selection
Jean-Marc Lasgouttes wrote: > Le 09/04/2018 ?? 16:17, Pavel Sanda a écrit : >> The current master situation seems indeed the best from all the patches >> I've >> been testing so far. > > But shouldn't $a$ have the same cursor as $f$? I do not see why cursor must have the same height for all of these. We could set 'b' or even 'f' as the min height instead of 'x', but any of these would be better than current 2.3 default. I do not have strong opinion, when I set 'b' instead of 'x' it looked to me somewhat better than 'x' in few cases I have tried. Pavel
Re: Behavior of overset inset creation on selection
Le 09/04/2018 à 16:17, Pavel Sanda a écrit : The current master situation seems indeed the best from all the patches I've been testing so far. But shouldn't $a$ have the same cursor as $f$? JMarc
Re: Behavior of overset inset creation on selection
Jean-Marc Lasgouttes wrote: > Le 07/04/2018 ?? 12:18, Enrico Forestieri a écrit : >> They seem to be fine, but time will tell. I am rather concerned with the >> cursor height in mathed. Seemingly, it is proportional to the height of the >> tallest character in a cell, so that the cursor almost disappears when only >> a minus sign is present. This is very ugly. For example, after typing "a^" >> the cursor is in the superscript cell and its height equals the cell height. >> However, after typing "-" the cursor height shrinks. I think it should stay >> the same height it had when the cell was empty, unless a taller character is >> entered. In this case, its height should be accordingly increased. > > The situation should be a bit better now. The current master situation seems indeed the best from all the patches I've been testing so far. Pavel
Re: Behavior of overset inset creation on selection
Le 07/04/2018 à 12:18, Enrico Forestieri a écrit : They seem to be fine, but time will tell. I am rather concerned with the cursor height in mathed. Seemingly, it is proportional to the height of the tallest character in a cell, so that the cursor almost disappears when only a minus sign is present. This is very ugly. For example, after typing "a^" the cursor is in the superscript cell and its height equals the cell height. However, after typing "-" the cursor height shrinks. I think it should stay the same height it had when the cell was empty, unless a taller character is entered. In this case, its height should be accordingly increased. The situation should be a bit better now. Riki, can I backport 6df8c42e59 to 2.3.X? This sets a minimal height equal to the x-height of the font for math cells. However right now the cursor has a size equal to the height of current row, so that it will be smaller inside $a$ than inside $f$. I will try to fix that and basically revert the cursor size code to replace it with a better one. JMarc
Re: Behavior of overset inset creation on selection
Enrico Forestieri wrote: > They seem to be fine, but time will tell. I am rather concerned with the > cursor height in mathed. Seemingly, it is proportional to the height of > the tallest character in a cell, so that the cursor almost disappears when > only a minus sign is present. This is very ugly. For example, after typing > "a^" the cursor is in the superscript cell and its height equals the cell > height. However, after typing "-" the cursor height shrinks. I think it > should stay the same height it had when the cell was empty, unless a taller > character is entered. In this case, its height should be accordingly > increased. https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg204612.html Pavel
Re: Behavior of overset inset creation on selection
On Thu, Apr 05, 2018 at 11:27:17AM +0200, Jean-Marc Lasgouttes wrote: > > Enrico, I would appreciate if you could take a quick look at the changes in > Cursor.cpp. I change the defaults for some important macros, and I do not > want to break something unrelated to what I was trying to change. They seem to be fine, but time will tell. I am rather concerned with the cursor height in mathed. Seemingly, it is proportional to the height of the tallest character in a cell, so that the cursor almost disappears when only a minus sign is present. This is very ugly. For example, after typing "a^" the cursor is in the superscript cell and its height equals the cell height. However, after typing "-" the cursor height shrinks. I think it should stay the same height it had when the cell was empty, unless a taller character is entered. In this case, its height should be accordingly increased. -- Enrico
Re: Behavior of overset inset creation on selection
Le 05/04/2018 à 04:51, Scott Kostyshak a écrit : On Wed, Apr 04, 2018 at 04:36:26PM +, Jean-Marc Lasgouttes wrote: Comments welcome. Tested and works well! I actually wasn't very hopeful that someone would make a patch when I posted this issue. I am glad to be surprised. Thank you for your work on it, I pushed to master a version with more refactoring that also takes into account \stackrel and \sqrt[]{}. Enrico, I would appreciate if you could take a quick look at the changes in Cursor.cpp. I change the defaults for some important macros, and I do not want to break something unrelated to what I was trying to change. Note that navigation in things like non-square root is now different. Please tell me whether it is still OK. JMarc
Re: Behavior of overset inset creation on selection
On Wed, Apr 04, 2018 at 04:36:26PM +, Jean-Marc Lasgouttes wrote: > Comments welcome. Tested and works well! I actually wasn't very hopeful that someone would make a patch when I posted this issue. I am glad to be surprised. Thank you for your work on it, Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 31/03/2018 à 19:49, Scott Kostyshak a écrit : To see an issue that has long annoyed me, do the following: 1. In math mode, type "=". 2. Select the "=" you just typed. 3. Choose "Overset" from the math toolbar (alternatively, just type "\overset"). The "=" is put in the "above" box, because that is the first LaTeX argument. From the user perspective, I think that putting "=" in the primary box is usually expected. For example, I think that this would be more consistent with when the user selects something and chooses "subscript". The thing selected is in the main box (it is not placed into the subscript). This patch tries to fix this. This touches several commonly used methods, so there is a real risk to introduce a regression. Let's see what happens. If the result is satisfactory, I will have to finish the patch (more refactoring needs to be done). Note that some insets other than Overset are touched: Script, Sideset, Underset. I did not really test them. Comments welcome. JMarc From 988ffb35975aeaad173d9dea665aaccff620b300 Mon Sep 17 00:00:00 2001 From: Jean-Marc LasgouttesDate: Wed, 4 Apr 2018 18:24:14 +0200 Subject: [PATCH] (WIP) When inserting math inset, put cursor selection in the correct cell The original use case for this bug is entering an overset inset when there is a selection. The expected result was to have the selection pasted in main text, but the result was to have it in the cell. Insets already have idxFirst() that is able to set cursor to the "entry" cell of an inset. This patch introduces firstIdx(), which is the index of this cell and useit in idxFirst() (idem for lastIdx/idxLast). As a consequence, several instances of idxFirst/idxLast can be removed. Now for the real fix: the two places where the cell in which selection is inserted seem to be: * Cursor::macroModeClose * Cursor::handleNest These two methods are changed to insert material in the entry cell instead of cell 0. Finallly, fix a typo in InsetMathNest::edit() where enter_front computation was wrong. --- src/Cursor.cpp | 11 +-- src/Cursor.h | 5 - src/mathed/InsetMathHull.cpp | 2 +- src/mathed/InsetMathNest.cpp | 12 ++-- src/mathed/InsetMathNest.h | 5 + src/mathed/InsetMathOverset.cpp | 16 src/mathed/InsetMathOverset.h| 4 ++-- src/mathed/InsetMathScript.cpp | 16 src/mathed/InsetMathScript.h | 6 ++ src/mathed/InsetMathSideset.cpp | 16 src/mathed/InsetMathSideset.h| 6 ++ src/mathed/InsetMathUnderset.cpp | 16 src/mathed/InsetMathUnderset.h | 4 ++-- 13 files changed, 33 insertions(+), 86 deletions(-) diff --git a/src/Cursor.cpp b/src/Cursor.cpp index eb8c501..f3fccfa 100644 --- a/src/Cursor.cpp +++ b/src/Cursor.cpp @@ -1646,6 +1646,12 @@ void Cursor::handleNest(MathAtom const & a, int c) } +void Cursor::handleNest(MathAtom const & a) +{ + handleNest(a, a.nucleus()->asNestInset()->firstIdx()); +} + + int Cursor::targetX() const { if (x_target() != -1) @@ -1703,6 +1709,7 @@ bool Cursor::macroModeClose(bool cancel) // try to put argument into macro, if we just inserted a macro bool macroArg = false; InsetMathMacro * atomAsMacro = atom.nucleus()->asMacro(); + InsetMathNest * atomAsNest = atom.nucleus()->asNestInset(); if (atomAsMacro) { // macros here are still unfolded (in init mode in fact). So // we have to resolve the macro here manually and check its arity @@ -1717,8 +1724,8 @@ bool Cursor::macroModeClose(bool cancel) } // insert remembered selection into first argument of a non-macro - else if (atom.nucleus()->nargs() > 0) - atom.nucleus()->cell(0).append(selection); + else if (atomAsNest && atomAsNest->nargs() > 0) + atomAsNest->cell(atomAsNest->firstIdx()).append(selection); MathWordList const & words = mathedWordList(); MathWordList::const_iterator it = words.find(name); diff --git a/src/Cursor.h b/src/Cursor.h index 5ca98cb..08309fa 100644 --- a/src/Cursor.h +++ b/src/Cursor.h @@ -515,8 +515,11 @@ public: /// replace selected stuff with at, placing the former + // selection in entry cell of atom + void handleNest(MathAtom const & at); + /// replace selected stuff with at, placing the former // selection in given cell of atom - void handleNest(MathAtom const & at, int cell = 0); + void handleNest(MathAtom const & at, int cell); /// make sure cursor position is valid /// FIXME: It does a subset of fixIfBroken. Maybe merge them? diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp index 8f40d2c..c132997 100644 --- a/src/mathed/InsetMathHull.cpp +++ b/src/mathed/InsetMathHull.cpp @@ -2253,7 +2253,7 @@ void InsetMathHull::handleFont2(Cursor & cur, docstring const & arg) font.fromString(to_utf8(arg), b); if (font.fontInfo().color() != Color_inherit) { MathAtom at = MathAtom(new InsetMathColor(buffer_, true,
Re: Behavior of overset inset creation on selection
On Sat, Mar 31, 2018 at 11:49 AM, Scott Kostyshakwrote: > To see an issue that has long annoyed me, do the following: > > 1. In math mode, type "=". > 2. Select the "=" you just typed. > 3. Choose "Overset" from the math toolbar (alternatively, just type > "\overset"). > > The "=" is put in the "above" box, because that is the first LaTeX > argument. From the user perspective, I think that putting "=" in the > primary box is usually expected. For example, I think that this would be > more consistent with when the user selects something and chooses > "subscript". The thing selected is in the main box (it is not placed > into the subscript). > > What are your thoughts? > I've never used this math feature; however, my expectation is consistent with yours (and counter to the behavior you describe).
Behavior of overset inset creation on selection
To see an issue that has long annoyed me, do the following: 1. In math mode, type "=". 2. Select the "=" you just typed. 3. Choose "Overset" from the math toolbar (alternatively, just type "\overset"). The "=" is put in the "above" box, because that is the first LaTeX argument. From the user perspective, I think that putting "=" in the primary box is usually expected. For example, I think that this would be more consistent with when the user selects something and chooses "subscript". The thing selected is in the main box (it is not placed into the subscript). What are your thoughts? Thanks, Scott signature.asc Description: PGP signature