On 04/24/2011 06:02 AM, Edwin Leuven wrote:
Richard Heck:
What the usual calls to updateBuffer() do is always
make the macro context a ParIterator that points to
the first paragraph in the current inset. (See e.g.
the calls at InsetText:682,695.)
ok. makes me wonder though why it is necessary t
Richard Heck :
> What the usual calls to updateBuffer() do is always
> make the macro context a ParIterator that points to
> the first paragraph in the current inset. (See e.g.
> the calls at InsetText:682,695.)
ok. makes me wonder though why it is necessary to set the macro
context explicitly.
>
Il 23/04/2011 19:52, Edwin Leuven ha scritto:
Richard Heck wrote:
I guess the other idea would be to recurse
through all the insets.
attached, and no more crashes.
i think i prefer this solution (although i am not sure we need to add
the code to insettext)
ed.
FYI, I just added a test-case
On 04/23/2011 02:07 PM, John McCabe-Dansted wrote:
On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuven wrote:
..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false
VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188
In case this is relevant, this assertion also shows up in:
http://gmat
Regarding the x2.patch, the problem is that par_iterator_begin() does
not give us a "complete" DocIterator (one starting with the Buffer's own
InsetText, etc), which is what we need. I am constantly running into
this problem!
Regarding the other patch, adding the code to InsetText just seeme
On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuven wrote:
> ..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false
> VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188
In case this is relevant, this assertion also shows up in:
http://gmatht.homelinux.net/xp/keytest/html_out/out/t18//html/
Richard Heck wrote:
> I guess the other idea would be to recurse
> through all the insets.
attached, and no more crashes.
i think i prefer this solution (although i am not sure we need to add
the code to insettext)
ed.
x3.patch
Description: Binary data
Richard Heck wrote:
> Can you post this version of the patch
> and I'll try to have a look?
attached
> I'm wondering where these comparisons are
> being made and whether we need to do
> something to the cursor. But I'm really
> just guessing here.
very frustating this poking in the dark...
> I
On 04/23/2011 11:45 AM, Edwin Leuven wrote:
I wonder if we could try:
ParagraphList::const_iterator pit =
tail.getText(0)->paragraphs().begin();
buffer().updateBuffer(pit, OutputUpdate);
i am not sure i completely follow you, but when i use
buffer().updateBuffer(par_iterator_begin(tai
On 04/23/2011 11:45 AM, Edwin Leuven wrote:
I wonder if we could try:
ParagraphList::const_iterator pit =
tail.getText(0)->paragraphs().begin();
buffer().updateBuffer(pit, OutputUpdate);
i am not sure i completely follow you, but when i use
buffer().updateBuffer(par_iterator_begin(tai
Richard Heck wrote:
> My main comment would be that I suspect, but of course
> couldn't verify, due to the crashes, that the same
> problem exists in the TexRow() output routine,
i checked that previewing the document and having the source view pane
open worked
my guess was that things are ok as
On 04/23/2011 06:56 AM, Edwin Leuven wrote:
Richard Heck wrote:
Answer: No, probably not, because it's hard to see
how to do this without making copies, which would
just give us the same problem back again.
the attached avoids the crash for me by setting the macrocontext for
nested insets (and
Richard Heck wrote:
> Answer: No, probably not, because it's hard to see
> how to do this without making copies, which would
> just give us the same problem back again.
the attached avoids the crash for me by setting the macrocontext for
nested insets (and only doing the metrics call on the tail;
On 04/22/2011 10:42 PM, Richard Heck wrote:
On 04/22/2011 05:24 PM, Edwin Leuven wrote:
Richard Heck wrote:
I think I know what's happening here.
sounds reasonable indeed
We might somehow need to call updateBuffer()
on these new insets.
or find a way of calculating the width of the insette
On 04/22/2011 05:24 PM, Edwin Leuven wrote:
Richard Heck wrote:
I think I know what's happening here.
sounds reasonable indeed
We might somehow need to call updateBuffer()
on these new insets.
or find a way of calculating the width of the insettext before and
after the decimal separator wit
Richard Heck wrote:
> I think I know what's happening here.
sounds reasonable indeed
> We might somehow need to call updateBuffer()
> on these new insets.
or find a way of calculating the width of the insettext before and
after the decimal separator without making a copy, chopping it into
two a
On 04/22/2011 02:17 PM, Richard Heck wrote:
On 04/22/2011 01:46 PM, Edwin Leuven wrote:
Richard Heck wrote:
Same crash with a footnote there. So it looks
as if for some reason insets inside cells are not
getting their macro context set properly.
which is done in lines 3453-3473 of insettabula
17 matches
Mail list logo
