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 09:12:41 -0700 Message-ID: References: <45998.128.165.123.18.1190647454.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 1190650656 29952 80.91.229.12 (24 Sep 2007 16:17:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2007 16:17:36 +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 18:17:31 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 1IZqck-0001PW-UD for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 18:17:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZqci-0007mN-0i for ged-emacs-devel@m.gmane.org; Mon, 24 Sep 2007 12:17:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZqZ7-0006Da-HH for emacs-devel@gnu.org; Mon, 24 Sep 2007 12:13:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZqZ7-0006DO-0I for emacs-devel@gnu.org; Mon, 24 Sep 2007 12:13:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZqZ6-0006DL-S0 for emacs-devel@gnu.org; Mon, 24 Sep 2007 12:13:44 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IZqZ6-0004k2-J0 for emacs-devel@gnu.org; Mon, 24 Sep 2007 12:13:44 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8OGDf45000432; Mon, 24 Sep 2007 11:13:41 -0500 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 l8OG5qIB022459; Mon, 24 Sep 2007 10:13:41 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt350.oracle.com with ESMTP id 3240053551190650361; Mon, 24 Sep 2007 09:12:41 -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: <45998.128.165.123.18.1190647454.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:79704 Archived-At: > > 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. > > Exactly how much help does an semi-knowledgeable user (who knows enough to > want to bind a key) need beyond the error? > ... > I don't see the reaction to C-h c proceeding like that, but rather > "Aha. Good to know, but I can obviously use it here, since it doesn't > work anyway." 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? 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? 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'. b. The information is after the fact (after trying that particular key). 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. 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. 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.