Le 22/10/2019 à 03:33, Richard Kimberly Heck a écrit :
Only one way to find out...
More seriously, I think we /shoudn't/ be doing anything that accesses
buffer() before then, though there are some cases where we do. I think
there is such a case in the cut and paste code, though I'm not sure.
What I learnt by implementing proper painting mechanism is that paint
event can happen at any point. For the same reason, I fear that buffer
access can happen at weird times.
Don't get me wrong: you solution would be my preferred one if we foud a
100% foolproof place to put it.
I would propose two other solutions:
1/ the opposite of yours
* add assertion on Inset::isBufferValid() in updateBuffer to maximise
assertions (or just use
my red painting)
* remove the setBuffer statements that are here just because we think
they may help
* track all the places where insets are actually inserted in buffers
and make sure the inset's buffer is set. To this end:
+ add Buffer* parameter to all Inset constructors (maybe not math,
see next point), and set if to non 0 when possible
+ for each place where buffer is not set, go up in the call graph
to the first place where it
can be done and set it there.
2/ try to investigate whether we could get rid of this buffer() method.
This would force to add BufferParams or Buffer argument to methods, but
we already have a lot of these that could be remove if we go all the way
in the 'buffer()' direction.
lyx-devel mailing list