On Fri, Jan 27, 2006 at 03:09:32PM +0100, Jean-Marc Lasgouttes wrote:
> > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
> Juergen> Juergen Spitzmueller wrote:
> >> Instead, we could implement a
> >> dociterator::forwardPosIgnoreCollapsed() method, which basically
> >> contain
n Fri, Jan 27, 2006 at 11:41:05AM +0100, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
> > I think I found it: bruteFind in cursor.C
>
> Attached is what I came up with. Now the cursor does not move into
> collapsed insets anymore, and the crash is fixed as well. Instead, we
> could i
On Thu, Jan 26, 2006 at 04:24:12PM +0100, Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
> > There is something I do not understand: if the code arrives there, it
> > means that the cursor is already inside the inset, isn't it? How can
> > this happen when it is collapsed? Isn't _this_ t
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
|
| Juergen> Jean-Marc Lasgouttes wrote: That would be the attached.
| Juergen> Personally, I'd prefer this one.
| >> Wouldn't it be easier to add a bool ignorecollapsed (defaul
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote: That would be the attached.
Juergen> Personally, I'd prefer this one.
>> Wouldn't it be easier to add a bool ignorecollapsed (defaulting to
>> true) to forwardPos? I know Andre' does not like
Jean-Marc Lasgouttes wrote:
> Juergen> That would be the attached. Personally, I'd prefer this one.
>
> Wouldn't it be easier to add a bool ignorecollapsed (defaulting to
> true) to forwardPos? I know Andre' does not like it in general, but it
> seems reasonable.
Yes, why not (although it should d
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Juergen Spitzmueller wrote:
>> Instead, we could implement a
>> dociterator::forwardPosIgnoreCollapsed() method, which basically
>> contains the same code.
Juergen> That would be the attached. Personally, I'd prefer this
Juergen Spitzmueller wrote:
> Instead, we could implement a dociterator::forwardPosIgnoreCollapsed()
> method, which basically contains the same code.
That would be the attached. Personally, I'd prefer this one.
Jürgen
Index: src/bufferview_funcs.C
Juergen Spitzmueller wrote:
> I think I found it: bruteFind in cursor.C
Attached is what I came up with. Now the cursor does not move into collapsed
insets anymore, and the crash is fixed as well.
Instead, we could implement a dociterator::forwardPosIgnoreCollapsed() method,
which basically cont
Jean-Marc Lasgouttes wrote:
> OK. So we have to find at which point the dociterator enters the
> inset.
I think I found it: bruteFind in cursor.C. Consider this loop:
for ( ; it != et; it.forwardPos()) {
// avoid invalid nesting when selecting
if (b
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> Could this be an artefact of the autoOpen feature (where insets are
>> both open and closed at the same time)?
>>
>> Do you have an easy way to disable autoopen and see whether this
>> help
Jean-Marc Lasgouttes wrote:
> Could this be an artefact of the autoOpen feature (where insets are
> both open and closed at the same time)?
>
> Do you have an easy way to disable autoopen and see whether this helps?
Yes (commenting out insetcollapsable.C: 132). This changes the situation
insofar
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> There is something I do not understand: if the code arrives there,
>> it means that the cursor is already inside the inset, isn't it? How
>> can this happen when it is collapsed? Isn't _this
Jean-Marc Lasgouttes wrote:
> There is something I do not understand: if the code arrives there, it
> means that the cursor is already inside the inset, isn't it? How can
> this happen when it is collapsed? Isn't _this_ the real bug we want to
> fix?
I'm not sure. Doesn't the DocIterator just iter
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> My analysis is as follows: The fix for bug 2094, which
Juergen> prevents coordOffset() from going into collapsed insets is
Juergen> not good enough, because it continues to descend down even in
Juergen> collapsed collapsa
http://bugzilla.lyx.org/show_bug.cgi?id=2241
The crash (or assert, if compiled with --disable-stdlib-debug) happens only if
the collapsable below the mathinset has not been opened before (cold cache)
and if it contains a HIGHLY_EDITABLE (table, inlined ERT) or math inset.
My analysis is as foll
16 matches
Mail list logo
