On 10/09/2014 03:08 PM, Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Jean-Marc Lasgouttes wrote:
Le 07/10/2014 17:21, Alfredo Braunstein a écrit :
Jean-Marc Lasgouttes wrote:
Le 07/10/2014 16:18, Alfredo Braunstein a écrit :
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?
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
