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'
