emacs-devel
[Top][All Lists]
Advanced

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

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


From: Drew Adams
Subject: RE: bind commands that change buffer contents to `undefined' when read-only?
Date: Mon, 24 Sep 2007 14:49:22 -0700

> I wrote unbound.el (http://www.emacswiki.org/cgi-bin/wiki/unbound.el);
> does that count?

Cool; I didn't know about that - great idea. What about adding that to
Emacs? It could perhaps be invoked with `C-h <something>'. Or it could
perhaps be invoked with some simple binding from the `C-h b' display. (See
also the EOM.)

> C-h b is so verbose that it's useless to me.

I agree that it's too verbose, but I still find it useful. It is all that
dead-tilde, dead-asciitilde etc. stuff and the self-insert-command stuff
that gets in the way. (No, I don't see the dead-tilde stuff in emacs -Q, but
I see it in my Emacs, and I have no idea where it's from or what it's for.)

Actually, a better use for `C-u C-h b' might be to show what we see now
(verbose), and let plain `C-h b' exclude some of the uninteresting stuff
(e.g. self-insert-command).

> 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.

That's why I mentioned `C-h b', but same idea. `C-h m' usually doesn't give
you any indication of unbound keys, AFAIK. It sometimes lists the bindings,
but that is anyway part of what you see in `C-h b'. In that case, `C-h m'
too would be improved by my suggestion to bind such keys to `undefined'.

> > 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.

Right. _If_ they should be shown to users as "undefined" and thus available
for defining, _then_ binding them to `undefined' is a better way to show
that than relying upon read-only error messages. I said that before.

> 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?

If that specific key were bound to `undefined', then _any_ mention of its
binding would show you that information, not just a read-only error.
Whatever the context where that particular key's binding is shown, it is
indicated that that key is available.

> > 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.

Not accidentally, and not the only 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:

That's why I submitted a specific possible list, for discussion.

And that's why the list is a customizable variable (as opposed, for example,
to using a symbol property for each such command's symbol). Programs or
users can adjust the list contextually, as needed. For instance, Dired mode
could bind that variable to a list of commands that is appropriate, and then
call the function that binds commands to `undefined'.

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

It wasn't on my list. Are you suggesting to include it? I would say it
should be excluded.

> 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.

Agreed. There are many commands, some of which might be bound to keys, that
modify buffers. Not all of them should be part of the list of "such keys". I
did not include `C-x 4 a' either.  Are you suggesting to include it?

> 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?

I'm not sure I follow you, but if I do, no, you would not be able to.

If that kind of thing is thought to be generally useful, then we might
modulate what I proposed, so that the key is undefined only when the buffer
is read-only. I don't have a particular mechanism in mind for that now, not
having thought about it.

> 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.

Maybe you're right. As you know, I am typically against Emacs trying to be
too clever. In practice, I haven't found a difficulty with what I'm
proposing (and I've used it for years), but maybe others could try it and
pound on it a bit to see if they find it limiting.

> 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.

That's just what I do in order to bind those keys to `undefined':

(defun undefine-keys-bound-to (command keymap)
  "Undefine all keys bound only by inheritance to COMMAND in KEYMAP.
If a key is bound to COMMAND in KEYMAP, but it is not bound directly
in KEYMAP, then bind it to `undefined' in KEYMAP."
  (dolist (key (where-is-internal command keymap))
    (when (and key (not (lookup-key keymap key)))
      (define-key keymap key 'undefined))))

(defun undefine-killer-commands (keymap)
  "Undefine KEYMAP keys that are bound to buffer-modifying commands.
For each key in KEYMAP that is indirectly bound to one of the commands in
`buffer-modifying-cmds', rebind it to `undefined'."
  (mapcar (lambda (cmd) (undefine-keys-bound-to cmd keymap))
          buffer-modifying-cmds))

But as Stefan, I think, pointed out, if this is built into Emacs it would
not need to be done in this after-the-fact way.

And your point is to leave it up to the user, via a `what-keys-are-useless'
command. That's a good argument.

> 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.

I agree with that, of course; absolutely.

And I think your `what-keys-are-useless' proposal is OK. But the name should
perhaps be changed - maybe `list-available-keys' or some such.

And the listing could distinguish keys that are truly unbound from those
that are bound to commands that might be inappropriate in the current mode.
And the latter might be divided into groups such as Richard suggested
(local/global buffer modifiers). IOW, the display would make it clear _why_
certain keys might be inappropriate in the current context - e.g., they try
to modify a read-only buffer.

Perhaps that is the best solution. It would also satisfy those who would
like to be able to pseudo-kill in a read-only buffer. The new command could
have the `C-h' prefix, perhaps `C-h u' (for "unbound" or "undefined" or
"useless" keys, as opposed to `C-h b' for  "bound" keys).

A disadvantage of that solution is that it is not readily apparent in other
listings and other mention of such keys that they are available (as
mentioned above). A user only gets that information upon demand. I could
live with that; it's still better than no indication at all of what's
available.






reply via email to

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