From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: bind commands that change buffer contents to `undefined' when read-only? Date: Mon, 24 Sep 2007 14:49:22 -0700 Message-ID: References: <46501.128.165.123.18.1190655532.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1190670631 20797 80.91.229.12 (24 Sep 2007 21:50:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2007 21:50:31 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 24 23:50:24 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IZvos-0004gh-RC for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 23:50:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZvop-0004Kt-SL for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 17:50:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZvof-0004H9-IQ for emacs-devel@gnu.org; Mon, 24 Sep 2007 17:50:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZvoc-0004G7-VO for emacs-devel@gnu.org; Mon, 24 Sep 2007 17:50:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZvoc-0004G1-E1 for emacs-devel@gnu.org; Mon, 24 Sep 2007 17:50:06 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IZvob-0007Pn-Qn for emacs-devel@gnu.org; Mon, 24 Sep 2007 17:50:06 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8OLo0Jj024990; Mon, 24 Sep 2007 15:50:01 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8OD3n1A020279; Mon, 24 Sep 2007 15:50:00 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt351.oracle.com with ESMTP id 3241094171190670560; Mon, 24 Sep 2007 14:49:20 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <46501.128.165.123.18.1190655532.squirrel@webmail.lanl.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:79761 Archived-At: > 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 '. 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.