On Sat, Jun 25, 2005 at 05:40:50PM +0200, Juergen Spitzmueller wrote:
Juergen Spitzmueller wrote:
LyX asserts when it searches for a note inset in a _collapsed_ footnote:
Assertion triggered in void lyxbreaker(const void*, const char*, int) by
failing check false in file coordcache.C:30
On Sat, Jun 25, 2005 at 05:40:50PM +0200, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
> > LyX asserts when it searches for a note inset in a _collapsed_ footnote:
> >
> > Assertion triggered in void lyxbreaker(const void*, const char*, int) by
> > failing check "false" in file
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen I have already tested those cases, and they still worked.
Juergen I'll test again over the weekend and apply the stuff if there
Juergen are no problems
Thanks.
JMarc
Juergen Spitzmueller wrote:
I have already tested those cases, and they still worked. I'll test again
over the weekend and apply the stuff if there are no problems
I have found no problems that are related to my patch. I have found, however,
a problem, which also exists in current cvs (I can
Juergen Spitzmueller wrote:
LyX asserts when it searches for a note inset in a _collapsed_ footnote:
Assertion triggered in void lyxbreaker(const void*, const char*, int) by
failing check false in file coordcache.C:30
This is a general problem with insets that are not in the CoordCache. LyX
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> I have already tested those cases, and they still worked.
Juergen> I'll test again over the weekend and apply the stuff if there
Juergen> are no problems
Thanks.
JMarc
Juergen Spitzmueller wrote:
> I have already tested those cases, and they still worked. I'll test again
> over the weekend and apply the stuff if there are no problems
I have found no problems that are related to my patch. I have found, however,
a problem, which also exists in current cvs (I can
Juergen Spitzmueller wrote:
> LyX asserts when it searches for a note inset in a _collapsed_ footnote:
>
> Assertion triggered in void lyxbreaker(const void*, const char*, int) by
> failing check "false" in file coordcache.C:30
This is a general problem with insets that are not in the CoordCache.
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen Jean-Marc Lasgouttes wrote:
Sorry for being so long. As I worte earlier, I would prefer to
modify gotoNextInset (which could just use a dociterator as
parameter) and gotoInset to fit your needs. They do what you want,
but they
Jean-Marc Lasgouttes wrote:
I like it. You might want to rename gotoNextInset to findNextInset (or
find a better name).
findNextInset looks good to me. I have renamed that.
Did you test that the searching works even in corner cases (inset is
the first thing in a document; cursor is at
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> Sorry for being so long. As I worte earlier, I would prefer to
>> modify gotoNextInset (which could just use a dociterator as
>> parameter) and gotoInset to fit your needs. They do what you
Jean-Marc Lasgouttes wrote:
> I like it. You might want to rename gotoNextInset to findNextInset (or
> find a better name).
findNextInset looks good to me. I have renamed that.
> Did you test that the searching works even in corner cases (inset is
> the first thing in a document; cursor is at
Jean-Marc Lasgouttes wrote:
Sorry for being so long. As I worte earlier, I would prefer to modify
gotoNextInset (which could just use a dociterator as parameter) and
gotoInset to fit your needs. They do what you want, but they change
the bv cursor.
You're a very patient educator :-)
Would
Jean-Marc Lasgouttes wrote:
> Sorry for being so long. As I worte earlier, I would prefer to modify
> gotoNextInset (which could just use a dociterator as parameter) and
> gotoInset to fit your needs. They do what you want, but they change
> the bv cursor.
You're a very patient educator :-)
>
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen Juergen Spitzmueller wrote:
Jean-Marc Lasgouttes wrote: My point is that the behaviour of
getInsetByCode is intended and should be left alone.
OK, then the comment to the function is at least misleading. How
about the
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Juergen Spitzmueller wrote:
>> Jean-Marc Lasgouttes wrote: > My point is that the behaviour of
>> getInsetByCode is intended and > should be left alone.
>>
>> OK, then the comment to the function is at least misleading.
Juergen Spitzmueller wrote:
Jean-Marc Lasgouttes wrote:
My point is that the behaviour of getInsetByCode is intended and
should be left alone.
OK, then the comment to the function is at least misleading. How about the
following (I know that it is not exactly what you are looking for, but I
Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
> > My point is that the behaviour of getInsetByCode is intended and
> > should be left alone.
>
> OK, then the comment to the function is at least misleading. How about the
> following (I know that it is not exactly what you are looking
Jean-Marc Lasgouttes wrote:
My point is that the behaviour of getInsetByCode is intended and
should be left alone.
OK, then the comment to the function is at least misleading. How about the
following (I know that it is not exactly what you are looking for, but I do
not see the need in
Jean-Marc Lasgouttes wrote:
> My point is that the behaviour of getInsetByCode is intended and
> should be left alone.
OK, then the comment to the function is at least misleading. How about the
following (I know that it is not exactly what you are looking for, but I do
not see the need in
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen Juergen Spitzmueller wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=961
The attached patch reimplements those lfuns. It also fixes
InsetBibtex::delDatabase, which is broken in 1.3.
The only drawback is that the lfuns are
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Juergen Spitzmueller wrote:
>> http://bugzilla.lyx.org/show_bug.cgi?id=961
>>
>> The attached patch reimplements those lfuns. It also fixes
>> InsetBibtex::delDatabase, which is broken in 1.3.
>>
>> The only drawback
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen Juergen Spitzmueller wrote:
I'm not even sure I understand what LABEL_GOTO does (or is it
broken?)
Juergen OK, now I do. This is really odd.
Odd in which sense?
JMarc
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen Juergen Spitzmueller wrote:
I'm not even sure I understand what LABEL_GOTO does (or is it
broken?)
OK, now I do. This is really odd.
Juergen I think this menu entry is extremely irritating. How about
Juergen the following
Jean-Marc Lasgouttes wrote:
I'm not even sure I understand what LABEL_GOTO does (or is it
broken?)
Juergen OK, now I do. This is really odd.
Odd in which sense?
Let me put it like this: It's not what I would have expected (though I see its
use).
Jürgen
Jean-Marc Lasgouttes wrote:
Yes, definitely good, although I would write:
+ case LFUN_LABEL_GOTO: {
+ flag.enabled(!cmd.argument.empty()
+ ||getInsetByCodeInsetRef(cursor_,
InsetBase::REF_CODE)); + break;
I did so and committed.
Thanks,
Juergen Spitzmueller wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=961
The attached patch reimplements those lfuns. It also fixes
InsetBibtex::delDatabase, which is broken in 1.3.
The only drawback is that the lfuns are not working when the cursor sits
behind the inset. The same applies to
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Juergen Spitzmueller wrote:
>> I'm not even sure I understand what LABEL_GOTO does (or is it
>> broken?)
Juergen> OK, now I do. This is really odd.
Odd in which sense?
JMarc
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Juergen Spitzmueller wrote:
>> > I'm not even sure I understand what LABEL_GOTO does (or is it
>> broken?)
>>
>> OK, now I do. This is really odd.
Juergen> I think this menu entry is extremely irritating. How about
Jean-Marc Lasgouttes wrote:
> >> I'm not even sure I understand what LABEL_GOTO does (or is it
> >> broken?)
>
> Juergen> OK, now I do. This is really odd.
>
> Odd in which sense?
Let me put it like this: It's not what I would have expected (though I see its
use).
Jürgen
Jean-Marc Lasgouttes wrote:
> Yes, definitely good, although I would write:
>
> + case LFUN_LABEL_GOTO: {
> + flag.enabled(!cmd.argument.empty()
> + ||getInsetByCode(cursor_,
> InsetBase::REF_CODE)); + break;
I did so and committed.
Thanks,
Juergen Spitzmueller wrote:
> http://bugzilla.lyx.org/show_bug.cgi?id=961
>
> The attached patch reimplements those lfuns. It also fixes
> InsetBibtex::delDatabase, which is broken in 1.3.
>
> The only drawback is that the lfuns are not working when the cursor sits
> behind the inset. The same
http://bugzilla.lyx.org/show_bug.cgi?id=961
The attached patch reimplements those lfuns. It also fixes
InsetBibtex::delDatabase, which is broken in 1.3.
The only drawback is that the lfuns are not working when the cursor sits
behind the inset. The same applies to 1.3. The reason is that
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen The only drawback is that the lfuns are not working when the
Juergen cursor sits behind the inset. The same applies to 1.3. The
Juergen reason is that getInsetByCode stops at the end of the
Juergen document.
Did you look at
Jean-Marc Lasgouttes wrote:
Did you look at gotoInset in bufferview_funcs.[Ch]?
Yes, but I think this is not what I need here. gotoInset moves the cursor to
the next inset, while LFUN_BIBDB_* needs the next bibtex inset, without
moving the cursor.
It would probably make more sense to use
Juergen Spitzmueller wrote:
/// Get next inset of this class from current cursor position
template class T
T * getInsetByCode(LCursor cur, InsetBase::Code code)
{
T * inset = 0;
DocIterator it = cur;
if (it.nextInset()
it.nextInset()-lyxCode() == code)
Juergen Spitzmueller wrote:
I'm not even sure I understand what LABEL_GOTO does (or is it broken?)
OK, now I do. This is really odd.
Jürgen
Juergen Spitzmueller wrote:
I'm not even sure I understand what LABEL_GOTO does (or is it broken?)
OK, now I do. This is really odd.
I think this menu entry is extremely irritating. How about the following
patch, that does enable the entry only when it actually makes sense?
Jürgen
Index:
http://bugzilla.lyx.org/show_bug.cgi?id=961
The attached patch reimplements those lfuns. It also fixes
InsetBibtex::delDatabase, which is broken in 1.3.
The only drawback is that the lfuns are not working when the cursor sits
behind the inset. The same applies to 1.3. The reason is that
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> The only drawback is that the lfuns are not working when the
Juergen> cursor sits behind the inset. The same applies to 1.3. The
Juergen> reason is that getInsetByCode stops at the end of the
Juergen> document.
Did you
Jean-Marc Lasgouttes wrote:
> Did you look at gotoInset in bufferview_funcs.[Ch]?
Yes, but I think this is not what I need here. gotoInset moves the cursor to
the next inset, while LFUN_BIBDB_* needs the next bibtex inset, without
moving the cursor.
It would probably make more sense to use
Juergen Spitzmueller wrote:
> /// Get next inset of this class from current cursor position
> template
> T * getInsetByCode(LCursor & cur, InsetBase::Code code)
> {
> T * inset = 0;
> DocIterator it = cur;
> if (it.nextInset() &&
> it.nextInset()->lyxCode() ==
Juergen Spitzmueller wrote:
> I'm not even sure I understand what LABEL_GOTO does (or is it broken?)
OK, now I do. This is really odd.
Jürgen
Juergen Spitzmueller wrote:
> > I'm not even sure I understand what LABEL_GOTO does (or is it broken?)
>
> OK, now I do. This is really odd.
I think this menu entry is extremely irritating. How about the following
patch, that does enable the entry only when it actually makes sense?
Jürgen
44 matches
Mail list logo
