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

Reply via email to