Le 21/01/2016 11:05, Enrico Forestieri a écrit :
On Thu, Jan 21, 2016 at 02:18:33AM -0500, Guillaume Munch wrote:
Le 20/01/2016 14:57, Enrico Forestieri a écrit :
On Wed, Jan 20, 2016 at 02:05:31AM -0500, Guillaume Munch wrote:
Le 19/01/2016 18:42, Enrico Forestieri a écrit :
On Tue, Jan 19, 2016 at 05:19:24PM -0500, Scott Kostyshak wrote:
On Sat, Jan 16, 2016 at 04:41:26PM +0100, Enrico Forestieri wrote:
commit 55b3374f3e3047a0aa7584e0737d1fcd40fe6809
Author: Enrico Forestieri <for...@lyx.org>
Date: Sat Jan 16 16:41:04 2016 +0100
Always place the cursor before a separator inset when clicking
Note that this commit might have triggered the assertion #9936.
Thanks. The attached patch fixes it for me.
You have added similar lines at several other places recently, after my
remarks. Should they be amended similarly?
No, the cursor is already in texted there.
Also, would it be better if you
factored the shared code in a new function?
They are only 2 lines of code, after all.
I think factoring the code is preferable in this situation. It
makes the code easier to understand and maintain. Also, it would check
for texted in all cases so it would depend on less assumptions. But I
also understand that you are very busy currently. I trust that you are
confident that no additional check for texted is required.
The check for texted (or equivalent check) is already done earlier
in the code, so there is no point in repeating it. However, I have
an updated patch that moves this code to a centralized place,
accounting for all mouse click events (single, double, etc.).
The same bug seems to arise in lyx::Cursor::upDownInText.
I had this issue four times in a short time span, every time I was
formatting math insets. I was in a rush, so I did not think about
recording a backtrace (I thought it was a known bug already reported).
Upon examination of the gdb session however I found the automatic backtrace:
( 1) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xc8c12f]
( 2) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xc8c44f]
( 3) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x5592d3]
( 4) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x543da3]
( 5) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x6be3bd]
( 6) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9ac200]
( 7) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x8b699d]
( 8) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x8d114e]
( 9) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x886c3b]
( 10) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x544e37]
( 11) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa0c08a]
( 12) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa23938]
( 13) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9ef2b2]
( 14) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9df1fd]
( 15) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x5f3876]
( 16) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0x9e17dd]
( 17) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa39619]
( 18) /usr/local/bin/lyx-gm: /usr/local/bin/lyx-gm() [0xa3c06c]
( 19) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*)
( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
QAbstractScrollArea::event(QEvent*)
Then using gdb I tried to check whether it was the one I thought:
(gdb) list *0xc8c12f
0xc8c12f is in lyx::doAssertWithCallstack(bool)
(/usr/include/c++/4.9/bits/basic_string.h:293).
288 // Data Members (private):
289 mutable _Alloc_hider _M_dataplus;
290
291 _CharT*
292 _M_data() const _GLIBCXX_NOEXCEPT
293 { return _M_dataplus._M_p; }
294
295 _CharT*
296 _M_data(_CharT* __p) _GLIBCXX_NOEXCEPT
297 { return (_M_dataplus._M_p = __p); }
(gdb) list *0x5592d3
0x5592d3 is in lyx::DocIterator::paragraph() const
(../../src/DocIterator.h:87).
82 // access to slice at tip
83 //
84 /// access to tip
85 CursorSlice & top() { return slices_.back(); }
86 /// access to tip
87 CursorSlice const & top() const { return slices_.back(); }
88 /// access to outermost slice
89 CursorSlice & bottom() { return slices_.front(); }
90 /// access to outermost slice
91 CursorSlice const & bottom() const { return slices_.front(); }
(gdb) list *0x543da3
0x543da3 is in lyx::Cursor::upDownInText(bool, bool&)
(../../src/Cursor.cpp:1950).
1945 if (bv().checkDepm(dummy, old)) {
1946 updateNeeded = true;
1947 // Make sure that cur gets back whatever
happened to dummy (Lgb)
1948 operator=(dummy);
1949 }
1950 if (pos() && paragraph().isEnvSeparator(pos() - 1))
1951 posBackward();
1952 } else {
1953 // if there is a selection, we stay out of any inset,
1954 // and just jump to the right position:
so apparently this is a new one. The other three backtraces similarly
point to 0x543da3.
As far as I understand, in release mode, this bug results in an
exception and emergency save, so I think it is best to solve this issue
before beta.
