Re: Behavior of overset inset creation on selection

2018-11-08 Thread Daniel

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

2018-11-07 Thread Scott Kostyshak
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

2018-11-07 Thread Jean-Marc Lasgouttes
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

2018-11-07 Thread Scott Kostyshak
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

2018-11-07 Thread Scott Kostyshak
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

2018-11-07 Thread Jean-Marc Lasgouttes

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

2018-11-07 Thread Daniel

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

2018-11-07 Thread Jean-Marc Lasgouttes

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

2018-11-06 Thread Scott Kostyshak
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

2018-11-06 Thread Jean-Marc Lasgouttes

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

2018-11-06 Thread Scott Kostyshak
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

2018-11-05 Thread Jean-Marc Lasgouttes

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

2018-11-05 Thread Scott Kostyshak
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

2018-11-04 Thread Jean-Marc Lasgouttes

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

2018-11-04 Thread Scott Kostyshak
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

2018-11-04 Thread Jean-Marc Lasgouttes

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

2018-11-04 Thread Scott Kostyshak
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

2018-11-04 Thread Jean-Marc Lasgouttes

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

2018-11-04 Thread Jean-Marc Lasgouttes

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

2018-10-30 Thread Scott Kostyshak
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

2018-04-09 Thread Kornel Benko
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

2018-04-09 Thread 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.


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

2018-04-09 Thread Kornel Benko
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

2018-04-09 Thread Pavel Sanda
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

2018-04-09 Thread 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


Re: Behavior of overset inset creation on selection

2018-04-09 Thread Pavel Sanda
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

2018-04-09 Thread Jean-Marc Lasgouttes

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

2018-04-07 Thread Pavel Sanda
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

2018-04-07 Thread Enrico Forestieri
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

2018-04-05 Thread Jean-Marc Lasgouttes

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

2018-04-04 Thread Scott Kostyshak
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

2018-04-04 Thread Jean-Marc Lasgouttes

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 Lasgouttes 
Date: 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

2018-03-31 Thread Joel Kulesza
On Sat, Mar 31, 2018 at 11:49 AM, Scott Kostyshak  wrote:

> 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

2018-03-31 Thread Scott Kostyshak
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