Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

>     >> Should erase-buffer in a Customize buffer leave it empty?
> 
>     Yes.
> 
>     >> The result would be an undesirable confusion.
> 
>     In what way could it be confusing?
> 
> Doesn't Custom create overlays?  If you erase the buffer,
> the overlays will continue to exist;

They will span empty ranges, though.

> basically, the Custom mechanism won't know that the buffer is empty.

Well, we had this already.  If the user is supposed to be allowed to
call erase-buffer (and I don't see anything that would make this a
sensible proposition), then the overlays should have the 'evaporate
property set.  Now your complaint was that user editable fields
should probably not evaporate when empty, but the user editable
fields are not read-only in the first place!

It is a bad idea to protect the user-editable fields by having
erase-buffer fail on completely different fields.  That is a side
effect.

Anyway, it might be a good idea if erase-buffer also kills all
overlays, after giving them a chance with modification-hooks and
evaporate and whatever else there is in way of notification.

> I think it is better for erase-buffer to get an error in the Custom
> buffer.

Even if you think so, I don't think that putting some read-only text
in as a side effect is the right way to achieve this.

Then it would be saner just to make the buffer-readonly.

Or at least restrict the failure on non-evaporating read-only overlays
without modification-hook, but let read-only text properties not cause
any problems.  An evaporating overlay, or one with a non-nil
modification-hook _anticipates_ deletion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum