On Tue, Mar 25, 2008 at 04:03:24PM -0400, rgheck wrote: > Andre Poenitz wrote: >> On Tue, Mar 25, 2008 at 02:24:48PM -0400, rgheck wrote: >> >>> rgheck wrote: >>> >>>> Or are there some that don't need it? or want it? >>>> >>>> >>> Here's the point of the question. There are surely still places in the >>> code where insets get constructed and their buffers don't get set. We can >>> hunt these down one crash at a time and probably still miss some or we >>> can do something more general. The way to do the latter would seem to be >>> to change: >>> /// Constructor >>> explicit Inset() : buffer_(0) {} >>> to explicit Inset::Inset(Buffer const & buf) : >>> buffer_(const_cast<Buffer *>(&buf)) {} >>> and then every Inset will HAVE to set its Buffer. Making that work seems >>> to be just a matter of making it compile. >>> >> >> It's a bit more than that as I mentioned. lib/symbols e.g. is read >> fairly early _and_ creates insets... >> >> > Are you sure about this? I just put a "lyxerr" line into the Inset > constructor, and I don't get anything on startup. File>New gives me one > construction, the InsetText, of course.
Hm... initMath()... but it seems to be called indeed only when the first math inset is created, and we should have a buffer by then... > Of course, there may be other issues elsewhere, and you would know better > than I. I suppose I could start by doing this sort of thing to InsetText > and InsetCommand. Yep, just do it ;-) Andre'