emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: erase-buffer (was: with-output-to-temp-buffer)


From: Kevin Rodgers
Subject: Re: erase-buffer (was: with-output-to-temp-buffer)
Date: Tue, 11 May 2004 10:22:10 -0600
User-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2

David Kastrup wrote:
> Stefan Monnier <address@hidden> writes:
>>BTW, it seems the main problem has to do with a conflict between
>>erase-buffer when called interactively and erase-buffer when called
>>from packages.
>>
>>So my question is: why is erase-buffer a command?
>>I didn't know it was a command until 5 days ago, it is not bound to any
>>key, and I can't think of any circumstance where a user might want to say
>>M-x erase-buffer RET.
>
> Right.  At best you want to kill a buffer.

Wrong.  I use it all the time.

>>Actually the only case I can think of is when the user knows what
>>he's doing; and allowing the M-x erase-buffer to work in Custom
>>buffers would then still make perfect sense (even if we don't fix
>>the lingering overlays).
>
> If one wants to use a command like that, one can always say
> M-: (erase-buffer) RET

Yuck.

> I also think that it should not be a command.  If you need to erase a
> buffer for whatever obscure reason, you can clear it with
> M-h C-w

I use M-x erase-buffer specifically to avoid munging the kill ring.

erase-buffer's (interactive "*") spec will continue to protect users who
call it interactively in a read-only buffer.  The suggestion that
erase-buffer bind inhibit-read-only to (not buffer-read-only) would not
affect its interactive use or Lisp function calls in read only buffers,
but would allow it to do its job when there are read-only text
properties or overlays.

I never use M-x customize and don't want it to determine M-x
erase-buffer's fate.

--
Kevin Rodgers






reply via email to

[Prev in Thread] Current Thread [Next in Thread]