RE: bind commands that change buffer contents to `undefined' when read-only?

["Drew Adams" <drew.adams@oracle.com>]

> In any case I don't like much this idea of adding explicit `undefined'
> bindings, just in order to get a "undefined" message rather than
> a "buffer is read-only" error.
>
> So maybe a better direction is to change the toplevel so that using
> a command with a "*" (or a call to barf-if-buffer-read-only) in its
> interactive spec when the buffer is read-only will signal
> "undefined" rather than signalling the error.  And similarly C-h k
> may give information such as "the global binding is foo but is of
> no use in this buffer because it's read-only".

Sounds OK to me at first, but:

1. We would need to make sure that all such bases were covered. `C-h k' is
one thing; `C-h b' might be another; the read-only error text is another;
and there are perhaps others.

2. It doesn't really help users see that such keys are, in effect, available
for binding in such read-only contexts. That was a main motivation behind my
proposal. A user might check `C-h b' in Dired, for example, and s?he would
see what? A long message explaining what you suggested, for each such key?
Is it as clear to read something like that as it is to read `undefined'? I
don't think so. And we might end up complicating the code that way, having
different kinds of such messages for different contexts (error message, `C-h
b' binding list, `C-h k', and so on).

I don't think you have given any reason _why_ you "don't like much this
idea"; you've just stated a preference. What are the disadvantages you see
to this idea? Deciding on a good way to handle this should involve weighing
the pros & cons.