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

["Davis Herring" <herring@lanl.gov>]

> It's not about the reaction to `C-h c' or to the read-only error message.
> It's about a user looking for available keys to bind in a particular
> context.
>
> Are you assuming that a user looking for available keys to bind starts
> with that error message, that is, by trying a key and seeing if it
> produces an error?

I've often done something like that: chosen a key first, then made sure it
was available (though perhaps with C-h c instead for safety).

> A user is more likely to try `C-h b' to see which keys are available.
> Especially if s?he wants to find multiple available bindings for a set of
> related commands. Have you never done that: check to see which keys are
> not bound in the current mode?

I wrote unbound.el (http://www.emacswiki.org/cgi-bin/wiki/unbound.el);
does that count?  C-h b is so verbose that it's useless to me.  And anyone
who is trying to find bindings for a whole family of commands is probably
sufficiently clued to just look at C-h m (and its description of the local
map) directly.

> So, yes, such an isolated error message might (though a bit indirectly)
> help
> a user to see that that particular key is, in effect, available. But:
>
> a. It is an indirect indication. It requires understanding that since that
> key cannot be used here because the buffer is read-only, it is, in effect,
> available for some other use. It is far clearer to simply tell the user
> that the key is `undefined'.

Er, it's clearer to tell them that if that is in fact the case!  But that
supposes your conclusion, that they should be undefined.  The status quo
is that, aside from self-inserters that we don't even really think of as
commands (but rather as "keyboard keys"), major modes override keys only
when they have something better to assign them.  This means that some
useless commands slip through; more on this under (c).

> b. The information is after the fact (after trying that particular key).

This is redundant with your (c): how would any key-specific help tell you
anything -before- you told it what key you were interested in?

> c. It provides information for only that one key - it does not help you
> see that _all_ "such keys" are also available, and it doesn't tell you
> what those keys are.

I think you may have (accidentally?) found the real point here.  What are
"such keys"?  Our presumed definition is "buffer-modifying keys in modes
associated with read-only buffers", but this is vague, incomplete, and
insufficiently specific all at once:

Vague: Is M-: a "buffer-modifying key"?  What about C-u M-:?

Incomplete: C-x 4 a never modifies the current buffer, but is quite
useless in, say, *Messages*.  Should we unbind it there?  (If so, in what
map?)  Similarly I -hope- `ffap' is useless to most people in hexl-mode.

Unspecific: I often find it useful to "hack" a Dired listing by making the
buffer writable and then using something like M-x keep-lines.  Obviously
M-x wouldn't be unbound, so this would continue to work, but why shouldn't
I also be able to use M-z in such a case?

Summary: trying to second-guess the global map by deciding that some of
its keys are "useless" in some environment is trying to be too clever. 
Instead: (continued)

> d. It helps only if you start by trying that key, not if you try to look
> up the current bindings (`C-h b') to see all that might be available.

And here you have the solution.  Let's take your list of modifying
commands (and any other commands that might be useless in some environment
or another) and add a simple command that runs `where-is' on it, dropping
any results that say "not bound".  Then a user can run the new M-x
what-keys-are-useless (with a better name) and have all and only the
relevant information, without any change to any keymaps.

> Please see also the rest of the referenced email - in particular, point #1
> and this part of #2:
>
>> 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.

Please do not tell me (I know this was not originally written to me, but
you have written similar things so directly) that I have not justified my
statements simply because you do not agree with the justifications.  I
said that I didn't think the use case (of a person looking for keys to
bind) was significantly improved by your proposal, which is why I don't
like it.  (Now, with more thought, I think I have come up with a better
proposal as well as better-understood why I prefer it.)

Never mind the necessary bias in favor of the status quo (necessary to
avoid endlessly reconsidering equally justified alternatives): it is up to
the proponent of a proposal to give -more- justification for it than can
be given for anything else.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.