Kyle Jones <kyle_jones(a)wonderworks.com> writes:
Yeah, this discussion does sound familiar. I think my position was
"well, fix this broken code!" and no one else wanted to fix it, so
in order to implement the change I would have to fix it.
Broken Lisp code or broken C code?
I wanted to fix the C code, but it was too hard for me at the time. I
plan to try again soon. You claimed the code was fixable in Lisp. I
asked you to fix it, but you said you wouldn't get involved. So it
was 1:1, as our soccer friends would say.
> > We can fix the crash, but things like font-lock and
setnu-mode,
> > which rely on having access to every change to operate
> > correctly, are still going to be screwed unless we disallow
> > these changes.
>
> Neither font-lock nor setnu are very useful with things like
> Customize buffers.
Yes, but this is awfully ad hoc. We don't know what other
developers are going to do with the feature. It may be imperative
to see all the text that goes in and out of a buffer, even in a
Custom buffer.
I don't see the reason why one would want that with a Customize
buffer.
If I fix wid-edit.el (assuming its possible) and whatever else we
ship that uses buffer modifying change functions, would you be more
amenable to disabling buffer modifications while inside a buffer
change function?
The point is not only what we ship, but what the users have written.
Buffer modification has been allowed in before/pre-change functions
for years, and code that employs it could have been written. In fact,
it has been written -- Customize wasn't always shipped with XEmacs.