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: button-buffer-map should inherit from special-mode-map Date: Thu, 21 Feb 2013 13:13:22 -0800 Message-ID: <9FC062B943B4480EADA31997447F20C0@us.oracle.com> References: <87y5ehsimf.fsf@gnu.org><64BBBA8150564874B08184FC5A733196@us.oracle.com><87mwuxse47.fsf@gnu.org><8FD33424BFE2446D8072FC1798D0021B@us.oracle.com> <87bobdsand.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1361481217 29275 80.91.229.3 (21 Feb 2013 21:13:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Feb 2013 21:13:37 +0000 (UTC) To: , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 21 22:13:59 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U8dSp-0002Be-2n for ged-emacs-devel@m.gmane.org; Thu, 21 Feb 2013 22:13:59 +0100 Original-Received: from localhost ([::1]:54299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8dSU-0004Tz-Lm for ged-emacs-devel@m.gmane.org; Thu, 21 Feb 2013 16:13:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8dSR-0004Tr-Fy for emacs-devel@gnu.org; Thu, 21 Feb 2013 16:13:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8dSL-0000Ov-JA for emacs-devel@gnu.org; Thu, 21 Feb 2013 16:13:35 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:40135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8dSI-0000NU-0C; Thu, 21 Feb 2013 16:13:26 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1LLDOYT008453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 21:13:25 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1LLDOCO003320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 21:13:24 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1LLDN8H013779; Thu, 21 Feb 2013 15:13:24 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Feb 2013 13:13:23 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87bobdsand.fsf@gnu.org> Thread-Index: Ac4QbbVUKaIGj1bWQ8eLp9jwLgBPvQABbHBw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157252 Archived-At: > The vehemence of your objection is stunning. What vehemence? Another unwarranted assumption. I just disagree with the assumptions you made and the proposal based on them. I am not vehement about that disagreement. And I mean nothing personal by my disagreement. You explicitly solicited objections (good), and I objected. And the first thing I said was that I am no expert on this, which is the case. AFAICT, there is no necessary reason for such a change, and not even any good reason for it. And there is every reason to keep independent things uncoupled. But I am open to being convinced otherwise. And I'm only one voice. > I am no longer arguing in favor of my proposal, Why not? Don't stop just because it met one objection. > but out of curiosity: > > 1. can you give an example of a non-self-insert buffer where > any of the special-mode-map bindings are not appropriate? Don't have to. Can you show that no such buffer can exist? But yes - Dired. Perhaps you recall this thread that you started? http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00015.html See also: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12311. Some keys in s-m-map, past, current, or future, might not necessarily be appropriate for some particular non-self-insert buffer. In the case of that thread, the argument was over whether `z' was appropriate. It is irrelevant to the current discussion whether it is still part of s-m-map or whether Dired uses s-m-map. Dired mode (not Wdired) has a non-self-insert buffer, and s-m-map is not appropriate for it (see the second URL above). The point is that there is no necessary dependence of non-self-insert buffers upon s-m-map. In this case, BTW, the doc string is no help. The s-m-map doc string just punts to "special mode", and that just punts nowhere (not good). A user needs to consult (elisp) `Basic Major Modes' to find out anything of substance about what a "special mode" is. It is a mode whose buffer text is "produced specially by Emacs, rather than directly from a file". That's pretty broad. The explanation adds that the buffer is set by `special-mode' to read-only (which is different from non-self-insertion, BTW). Whether all read-only or (your question) all non-self-insertion buffers must or should also be special could be debated. I would argue no. For one thing, the criterion of being "produced specially by Emacs, rather than directly from a file" is important. But though necessary, neither criterion is sufficient to _require_ special mode. You can use special mode for such a buffer, but nothing requires you to. > 2. can you give an example of a button-buffer-map usage in a > self-insert buffer? Ditto. Things should not be coupled unless they need to be. Occam. Stating this is not an expression of vehemence. > PS. my practical rationale was that I bound a key in special-mode-map > and was surprised that the binding was not present in *Buffer List*. That's easily remedied, no?