Le 29/11/2025 à 18:08, Richard Kimberly Heck a écrit :
On 11/29/25 10:20 AM, Jean-Marc Lasgouttes wrote:
The other question is: why does one more call to updateBuffer create such a
problem? Many other actions trigger it.
Yes, though when I redid all that code, I tried very hard not to have it
be called in this way, but only when the dispatch is done.
And this is great!
Is there a way we could remove the deleted label from the reference
cache, without having to go through the whole updateBuffer process? That
was Georg's idea, and it's the right idea. But it's not clear how to
make that happen. My first thought is to trigger the removal from the
InsetLabel destructor. But that might trigger too often (e.g.,
destruction of copied labels). Another would be to introduce some
separate procedure that *only* rebuilds the reference cache that could
be called from here. But that would involve a lot of code duplication,
possibly. And it would probably also call the expensive forwardInset.
When copying an inset, is the Buffer value kept? Otherwise this inset
will not trigger anything.
I think that removing the reference on deletion is the way to go.
A twist is that when removing an Input inset, all the references coming
from this inset should be removed too.
Maybe a third idea would be brute force: look through what we are
deleting and see if there are any labels in there. If so, remove them
from the cache.
I suspect it would be worse. And the removal in destructor is really
done at the place where it matters IMO, whereas this solution is
patching over an issue.
JMarc
--
lyx-devel mailing list
[email protected]
https://lists.lyx.org/mailman/listinfo/lyx-devel
