From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#16214: Consistency in dired-, occur-, and grep-mode Date: Sat, 21 Dec 2013 11:23:53 -0800 (PST) Message-ID: <4f292d00-c910-4c95-8fb6-1a7c367bb2ff@default> References: <20131221.224043.270400015.tkk@misasa.okayama-u.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1387653922 30471 80.91.229.3 (21 Dec 2013 19:25:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 19:25:22 +0000 (UTC) Cc: Roland McGrath To: Tak Kunihiro , 16214@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 21 20:25:26 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VuSAv-00005p-5L for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Dec 2013 20:25:25 +0100 Original-Received: from localhost ([::1]:55319 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuSAu-0002kk-Oi for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Dec 2013 14:25:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuSAi-0002kY-5B for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 14:25:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuSAZ-0006xo-Hq for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 14:25:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuSAZ-0006xA-Ff for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 14:25:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VuSAY-00013A-Fv for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 14:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Dec 2013 19:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16214-submit@debbugs.gnu.org id=B16214.13876538433930 (code B ref 16214); Sat, 21 Dec 2013 19:25:02 +0000 Original-Received: (at 16214) by debbugs.gnu.org; 21 Dec 2013 19:24:03 +0000 Original-Received: from localhost ([127.0.0.1]:33578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuS9a-00011J-Ea for submit@debbugs.gnu.org; Sat, 21 Dec 2013 14:24:02 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:41262) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuS9Y-00010t-8Z for 16214@debbugs.gnu.org; Sat, 21 Dec 2013 14:24:01 -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 rBLJNvgl004593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Dec 2013 19:23:58 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBLJNsgC024581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Dec 2013 19:23:55 GMT Original-Received: from ubhmt103.oracle.com (ubhmt103.oracle.com [156.151.24.8]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBLJNsmo024576; Sat, 21 Dec 2013 19:23:54 GMT In-Reply-To: <20131221.224043.270400015.tkk@misasa.okayama-u.ac.jp> X-Priority: 2 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82355 Archived-At: While there might be room for some minor alignment, in general it is not good to privilege standardization too highly here, IMO. There are superficial similarities, and maybe some that are more than superficial. But there are also different purposes and use patterns. These are quite different modes when you look closely and take all of what each does into account - its raison d'etre: what it is for. Each should be handled case by case, with an eye to all of its features and its overall set of use cases. Dired, in particular, is extremely rich. Let us not start hobbling it in the name of standardization. With that caveat expressed, I have no big objection to what has been proposed here so far. (I would prefer that SPC in Dired remain what it is, but that's about it.) But I would strongly recommend that we not go overboard with such an approach - that would be quite misguided IMO. The main guide for us should be the full set of features - and how they interact - for each individual mode viewed on its own. Let's keep in mind the most important rule regarding consistency: Consistency *within* a given system/application/realm/area/function is very important. Consistency *across* different areas is not so important - essentially only a nice-to-have, permitted when other things are in fact equal. Consistency within an area involves/includes also how its parts fit together. Individual parts (e.g. key sequences) should not be considered only on their own - they are parts of a whole/system. And even in the latter case, when we allow ourselves some added consistency across areas, we should always keep that *tentative*. A better idea that comes up later, based on reasons relevant to a given domain itself, should trump any such cross-domain tentative harmony we allowed before that better idea. IOW, internal cohesion/meaning/relevance is in general a much more important consideration than is external coupling/consistency/convention.