line-end in math

[Alfredo Braunstein]

Inside a math inset (denoted here by [ ]):

[one(two)t|hree]

( and ) are matched parenthesis (inserted with "Alt-M (") and | is the
cursor. If I press 'End' the cursor goes as expected to the end of the
inset, inside of it:

[one(two)three|]

Now if the situation is

[one(two|)three]

then pressing 'End' goes outside of the inset:

[one(two)three]|

This is driving me crazy! It's hard enough to navigate inside complex
formulae without this funny behaviour. The thing is particularly bad on
multi-line equations, where it exits everything (jumping over a lot of
positions that would have been visited if the cursor were outside of the
parenthesis in the first place).

I've found out that the attached patch restores my sanity of mind in this
particular case. Does anyone has an idea why the request was declared
undispatched (after being handled by the inner insets?) and what are the
potential problems of eliminating that line?

A/

[Jürgen Spitzmüller]

Post by Alfredo Braunstein
I've found out that the attached patch restores my sanity of mind in this
particular case. Does anyone has an idea why the request was declared
undispatched (after being handled by the inner insets?) and what are the
potential problems of eliminating that line?

I cannot answer why it was inserted, but I suppose you already found the
commit that introduces it?
http://www.lyx.org/trac/changeset/f70191cc/lyxgit

Welcome back!

JÃŒrgen

Post by Alfredo Braunstein
A/

[Alfredo Braunstein]

Post by Jürgen Spitzmüller

Post by Alfredo Braunstein
I've found out that the attached patch restores my sanity of mind in this
particular case. Does anyone has an idea why the request was declared
undispatched (after being handled by the inner insets?) and what are the
potential problems of eliminating that line?

I cannot answer why it was inserted, but I suppose you already found the
commit that introduces it?
http://www.lyx.org/trac/changeset/f70191cc/lyxgit

As a matter of fact, I didn't went into the forensics yet (thanks Jürgen!).
Wait, is that commit only 9 years old? I was hoping in a painless solution
by one of you guys ;-)

Post by Jürgen Spitzmüller
Welcome back!

I never left, I just had nothing to say! ;-)

A/

[Alfredo Braunstein]

Post by Alfredo Braunstein
Now if the situation is
[one(two|)three]
[one(two)three]|

By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without mouse
hover", now closed/fixed), as when the cursor escapes wrongly the math
inset, purple corners are not cleared. The patch fixes also this. Though as
before, I don't know if it has other ill effects...

A/

[Jean-Marc Lasgouttes]

Post by Alfredo Braunstein
By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without mouse
hover", now closed/fixed), as when the cursor escapes wrongly the math
inset, purple corners are not cleared. The patch fixes also this. Though as
before, I don't know if it has other ill effects...

Hi Alfredo,

The problem is to understand how this LFUN_FINISHED_LEFT thingy works. I
suspect that only André knows...

JMarc

[Alfredo Braunstein]

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein
By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
mouse hover", now closed/fixed), as when the cursor escapes wrongly the
math inset, purple corners are not cleared. The patch fixes also this.
Though as before, I don't know if it has other ill effects...

Hi Alfredo,
The problem is to understand how this LFUN_FINISHED_LEFT thingy works. I
suspect that only André knows...
JMarc

Well, that's just mean... Is he around? I'm not supposed to investigate this
by myself, right? I'd rather just wait until Friday and ask less nicely...
;-)

A/

[Jean-Marc Lasgouttes]

Post by Alfredo Braunstein

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein
By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
mouse hover", now closed/fixed), as when the cursor escapes wrongly the
math inset, purple corners are not cleared. The patch fixes also this.
Though as before, I don't know if it has other ill effects...

Hi Alfredo,
The problem is to understand how this LFUN_FINISHED_LEFT thingy works. I
suspect that only André knows...
JMarc

Well, that's just mean... Is he around? I'm not supposed to investigate this
by myself, right? I'd rather just wait until Friday and ask less nicely...
;-)
A/

Does this help?

JMarc

/*!
* \var lyx::FuncCode lyx::LFUN_FINISHED_FORWARD
* \li Action: Moves the cursor out of the current slice, going forward.
* \li Notion: Cursor movement within an inset may be different than cursor
movement in the surrounding text. This action should be
called
automatically by the cursor movement within the inset, when
movement within the inset has ceased (reached the end of the
last paragraph, for example), in order to move correctly
back into the surrounding text.
* \endvar
*/
{ LFUN_FINISHED_FORWARD, "", ReadOnly, Hidden },
{ LFUN_FINISHED_RIGHT, "", ReadOnly, Hidden },

/*!
* \var lyx::FuncCode lyx::LFUN_FINISHED_LEFT
* \li Action: Moves the cursor out of the current slice, going left.
* \li Notion: See also #LFUN_FINISHED_FORWARD.
* \endvar
*/
{ LFUN_FINISHED_LEFT, "", ReadOnly, Hidden },

[Alfredo Braunstein]

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein
By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
mouse hover", now closed/fixed), as when the cursor escapes wrongly the
math inset, purple corners are not cleared. The patch fixes also this.
Though as before, I don't know if it has other ill effects...

Hi Alfredo,
The problem is to understand how this LFUN_FINISHED_LEFT thingy works. I
suspect that only André knows...
JMarc

Well, that's just mean... Is he around? I'm not supposed to investigate
this by myself, right? I'd rather just wait until Friday and ask less
nicely... ;-)
A/

Does this help?

Sort of... Let me try to show what I understand about what is happening in
this example, and why I think that that line should go:

[aaa(bbb|)ccc]

As I see it, the situation is as follows. The outer inset is an InsetHull
(derived from InsetGrid), the inner one is an InsetNest.

1) On line-end, LFUN_LINE_END gets first dispatched by Cursor to the inner
InsetNest

2) The InsetNest doesn't do anything by itself (because the cursor is
already in its last position) but changes the lfun to LFUN_FINISHED_RIGHT,
flagged undispatched.

3) Then Cursor tries to dispatch (on the same cycle) the new lfun to the
next guy in the chain, which is the containing InsetHull (the dispatch
Cursor loses his last slice)

4) InsetHull just forwards the call to his ancestor InsetGrid and *then*
flags the lfun undispatched (this is the line I commented)

5) InsetGrid forward the call to his ancestor InsetNest.

6) InsetNest moves finally the cursor position one forward, to the
following: [aaa(bbb)|ccc]. The lfun is flagged as dispatched. The End! The
good guys win! But wait...!

7) As the flag is now reflagged as undispatched in 4), Cursor next tries to
dispatch it to the containing Text (the dispatch cursor loses another
slice).

8) Text moves it to the right once more (bad)...

So, the reflagging in 4) looks buggy to me... as it makes the same lfun to
be dealt with (successfully) twice. Of course it is possible that I
misunderstood something. Also, other code could "depend" on this "feature"
somehow...

Thoughts?

A/

[Alfredo Braunstein]

Post by Alfredo Braunstein

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein
By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
mouse hover", now closed/fixed), as when the cursor escapes wrongly
the math inset, purple corners are not cleared. The patch fixes also
this. Though as before, I don't know if it has other ill effects...

Hi Alfredo,
The problem is to understand how this LFUN_FINISHED_LEFT thingy works.
I suspect that only André knows...
JMarc

Well, that's just mean... Is he around? I'm not supposed to investigate
this by myself, right? I'd rather just wait until Friday and ask less
nicely... ;-)
A/

Does this help?

Sort of... Let me try to show what I understand about what is happening in
[aaa(bbb|)ccc]
As I see it, the situation is as follows. The outer inset is an InsetHull
(derived from InsetGrid), the inner one is an InsetNest.
1) On line-end, LFUN_LINE_END gets first dispatched by Cursor to the inner
InsetNest
2) The InsetNest doesn't do anything by itself (because the cursor is
already in its last position) but changes the lfun to LFUN_FINISHED_RIGHT,
flagged undispatched.
3) Then Cursor tries to dispatch (on the same cycle) the new lfun to the
next guy in the chain, which is the containing InsetHull (the dispatch
Cursor loses his last slice)
4) InsetHull just forwards the call to his ancestor InsetGrid and *then*
flags the lfun undispatched (this is the line I commented)
5) InsetGrid forward the call to his ancestor InsetNest.
6) InsetNest moves finally the cursor position one forward, to the
following: [aaa(bbb)|ccc]. The lfun is flagged as dispatched. The End!
The good guys win! But wait...!
7) As the flag is now reflagged as undispatched in 4), Cursor next tries
to dispatch it to the containing Text (the dispatch cursor loses another
slice).
8) Text moves it to the right once more (bad)...
So, the reflagging in 4) looks buggy to me... as it makes the same lfun to
be dealt with (successfully) twice. Of course it is possible that I
misunderstood something. Also, other code could "depend" on this "feature"
somehow...
Thoughts?

Some indirect evidence: explicit calls to doDispatch are never followed by
declaring the cmd undispatched, except for this case (InsetMathHull below).
It just doesn't make much sense IMO...

Should I add a bug to the tracker and attach the patch?


$ egrep -A1 'doDispa.*;$' *.cpp
InsetMathCases.cpp: InsetMathGrid::doDispatch(cur, cmd);
InsetMathCases.cpp-}
--
InsetMathGrid.cpp: InsetMathNest::doDispatch(cur, cmd);
InsetMathGrid.cpp- return;
--
InsetMathGrid.cpp: InsetMathNest::doDispatch(cur, cmd);
InsetMathGrid.cpp- }
--
InsetMathHull.cpp: InsetMathGrid::doDispatch(cur, cmd);
InsetMathHull.cpp- cur.undispatched();
--
InsetMathHull.cpp: InsetMathGrid::doDispatch(cur, cmd);
InsetMathHull.cpp- break;
--
InsetMathHull.cpp:
InsetMathGrid::doDispatch(cur, cmd);
InsetMathHull.cpp- return;
--
InsetMathHull.cpp: InsetMathGrid::doDispatch(cur, cmd);
InsetMathHull.cpp- return;
--
InsetMathHull.cpp: InsetMathGrid::doDispatch(cur, cmd);
InsetMathHull.cpp- return;
--
InsetMathHull.cpp: InsetMathGrid::doDispatch(cur, cmd);
InsetMathHull.cpp- break;
--
InsetMathNest.cpp: doDispatch(cur, fr);
InsetMathNest.cpp- break;
--
InsetMathNest.cpp: doDispatch(cur, fr);
InsetMathNest.cpp- break;
--
InsetMathNest.cpp: InsetMath::doDispatch(cur, cmd);
InsetMathNest.cpp- break;
--
InsetMathNest.cpp: doDispatch(bv.cursor(), cmd);
InsetMathNest.cpp- } else {
--
InsetMathRef.cpp: CommandInset::doDispatch(cur, cmd);
InsetMathRef.cpp- break;
--
InsetMathScript.cpp: InsetMathNest::doDispatch(cur, cmd);
InsetMathScript.cpp-}
--
InsetMathSpace.cpp: InsetMath::doDispatch(cur, cmd);
InsetMathSpace.cpp- break;
--
MathMacroTemplate.cpp: InsetMathNest::doDispatch(cur, cmd);
MathMacroTemplate.cpp- break;

[Richard Heck]

Post by Alfredo Braunstein

Post by Alfredo Braunstein

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein

Post by Jean-Marc Lasgouttes

Post by Alfredo Braunstein
By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
mouse hover", now closed/fixed), as when the cursor escapes wrongly
the math inset, purple corners are not cleared. The patch fixes also
this. Though as before, I don't know if it has other ill effects...

Hi Alfredo,
The problem is to understand how this LFUN_FINISHED_LEFT thingy works.
I suspect that only André knows...
JMarc

Well, that's just mean... Is he around? I'm not supposed to investigate
this by myself, right? I'd rather just wait until Friday and ask less
nicely... ;-)
A/

Does this help?

Sort of... Let me try to show what I understand about what is happening in
[aaa(bbb|)ccc]
As I see it, the situation is as follows. The outer inset is an InsetHull
(derived from InsetGrid), the inner one is an InsetNest.
1) On line-end, LFUN_LINE_END gets first dispatched by Cursor to the inner
InsetNest
2) The InsetNest doesn't do anything by itself (because the cursor is
already in its last position) but changes the lfun to LFUN_FINISHED_RIGHT,
flagged undispatched.
3) Then Cursor tries to dispatch (on the same cycle) the new lfun to the
next guy in the chain, which is the containing InsetHull (the dispatch
Cursor loses his last slice)
4) InsetHull just forwards the call to his ancestor InsetGrid and *then*
flags the lfun undispatched (this is the line I commented)
5) InsetGrid forward the call to his ancestor InsetNest.
6) InsetNest moves finally the cursor position one forward, to the
following: [aaa(bbb)|ccc]. The lfun is flagged as dispatched. The End!
The good guys win! But wait...!
7) As the flag is now reflagged as undispatched in 4), Cursor next tries
to dispatch it to the containing Text (the dispatch cursor loses another
slice).
8) Text moves it to the right once more (bad)...
So, the reflagging in 4) looks buggy to me... as it makes the same lfun to
be dealt with (successfully) twice. Of course it is possible that I
misunderstood something. Also, other code could "depend" on this "feature"
somehow...
Thoughts?

Some indirect evidence: explicit calls to doDispatch are never followed by
declaring the cmd undispatched, except for this case (InsetMathHull below).
It just doesn't make much sense IMO...
Should I add a bug to the tracker and attach the patch?

Do you have commit rights still? If so, I'd suggest you go ahead and
commit to master. Then create the bug and mark it fixedinmaster so we
can remember to add this to 2.1.x at some point.

If there are backend things we need to do to make this work, I suppose
we can do that.

Richard

[Alfredo Braunstein]

Post by Richard Heck
Do you have commit rights still? If so, I'd suggest you go ahead and
commit to master. Then create the bug and mark it fixedinmaster so we
can remember to add this to 2.1.x at some point.

I have no idea, my last commit was around 2008 against svn... Should I have
login access to git.lyx.org? I don't thnk I have it now, who can set it up?
However, I'd feel better if someone besides myself reviewed the change or
at least tested it before committing. That particular line is 9 years old
and my last lyx activity is around six... I *could* be a little rusty ;-)

Post by Richard Heck
If there are backend things we need to do to make this work, I suppose
we can do that.

Sorry, what do you mean by "backend things"?

A/

[Alfredo Braunstein]

Post by Richard Heck
Do you have commit rights still? If so, I'd suggest you go ahead and
commit to master. Then create the bug and mark it fixedinmaster so we
can remember to add this to 2.1.x at some point.

Done.

A/

[Scott Kostyshak]

Post by Alfredo Braunstein

Post by Alfredo Braunstein
Now if the situation is
[one(two|)three]
[one(two)three]|

By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without mouse
hover", now closed/fixed), as when the cursor escapes wrongly the math
inset, purple corners are not cleared. The patch fixes also this. Though as
before, I don't know if it has other ill effects...

I am guessing I'm wrong but wanted to check anyway. Is this bug at all related?
http://www.lyx.org/trac/ticket/2542

Scott

[Alfredo Braunstein]

Post by Scott Kostyshak

Post by Alfredo Braunstein

Post by Alfredo Braunstein
Now if the situation is
[one(two|)three]
[one(two)three]|

By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
mouse hover", now closed/fixed), as when the cursor escapes wrongly the
math inset, purple corners are not cleared. The patch fixes also this.
Though as before, I don't know if it has other ill effects...

I am guessing I'm wrong but wanted to check anyway. Is this bug at all
related? http://www.lyx.org/trac/ticket/2542
Scott

Seems indeed unrelated.

A/

[Alfredo Braunstein]

Post by Alfredo Braunstein

Post by Scott Kostyshak

Post by Alfredo Braunstein

Post by Alfredo Braunstein
Now if the situation is
[one(two|)three]
[one(two)three]|

By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
mouse hover", now closed/fixed), as when the cursor escapes wrongly the
math inset, purple corners are not cleared. The patch fixes also this.
Though as before, I don't know if it has other ill effects...

I am guessing I'm wrong but wanted to check anyway. Is this bug at all
related? http://www.lyx.org/trac/ticket/2542
Scott

Seems indeed unrelated.

I did a quick investigation on this, and there is kind of a design flaw. On
a mouse event, the external Text starts a chain of recursive editXY calls to
find the deepest inset (and the closest position within) containing the
click point inside nested structures to create a Cursor.

Then the lfun is dispatched to that Cursor; and the usual lfun catching game
in which the cursor is iteratively chopped and the lfun is proposed to all
insets in the path, starting from the deepest one. For a mouse click, the
deepest editable inset will typically catch the lfun.

For mouse click+motion event (i.e. selection), insets deeper than the anchor
ignore the lfun; so the lfun is catch by the one on the same level than the
anchor, where the cursor should be positioned. But there is a problem: even
if the tip of the Cursor points to the closest position to the click point,
intermediate slices will always point to the position *before* the
corresponding inset (otherwise the cursor will be invalid).

An fix is in attachment (minimal, but not very pretty), where the position
"corrected" on this last dispatch. But I think we should really find a
better fix. Ideas?

A/