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#20739: 25.0.50; Dired switches have no effect when explicit list of files provided Date: Sun, 7 Jun 2015 10:34:18 -0700 (PDT) Message-ID: <186494c2-6958-42eb-a351-6543237bfb75@default> References: <> <<83oaksmyc8.fsf@gnu.org>> <> <<83fv63mvkj.fsf@gnu.org>> 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 1433698525 15198 80.91.229.3 (7 Jun 2015 17:35:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jun 2015 17:35:25 +0000 (UTC) Cc: 20739@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 07 19:35:12 2015 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 1Z1eTX-0006m5-RL for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jun 2015 19:35:12 +0200 Original-Received: from localhost ([::1]:54811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1eTX-0004Q1-48 for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jun 2015 13:35:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1eTT-0004Nr-0a for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 13:35:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1eTQ-0000ms-9d for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 13:35:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1eTQ-0000lg-3W for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 13:35:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z1eTP-0000Ln-8q for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 13:35:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Jun 2015 17:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20739-submit@debbugs.gnu.org id=B20739.14336984691305 (code B ref 20739); Sun, 07 Jun 2015 17:35:03 +0000 Original-Received: (at 20739) by debbugs.gnu.org; 7 Jun 2015 17:34:29 +0000 Original-Received: from localhost ([127.0.0.1]:44226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z1eSq-0000Ky-I1 for submit@debbugs.gnu.org; Sun, 07 Jun 2015 13:34:29 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:22619) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z1eSn-0000Kk-KF for 20739@debbugs.gnu.org; Sun, 07 Jun 2015 13:34:26 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t57HYJai027380 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Jun 2015 17:34:19 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t57HYIkw005954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 7 Jun 2015 17:34:18 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t57HYHeX018644; Sun, 7 Jun 2015 17:34:17 GMT In-Reply-To: <<83fv63mvkj.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] 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:103698 Archived-At: > > > I've found no switches that are ignored as result of this > > > implementation, except those that control the order of the > > > files in the listing, so that's what I stated in the doc string. =20 > > > I think this makes the actual behavior clear enough. > > > > It is not about the order. `r' works, for example - it reverses > > the order. >=20 > No, it doesn't. The order is always the same as in the list you > pass to 'dired'. That's not what I see. (dired ("foo" "/path/to/bbbbb" "/path/to/foo.el" "/path/to/bar.el") "-alFr") shows the files in Dired in the reverse order: bar.el, foo.el, bbbbb. Switch -r, even though it is about the sort order, works fine with a cons DIRNAME. Here anyway (with emacs -Q). =20 > > And anyway I don't think that sort-order switches are the only > > ones that are ignored/irrelevant when DIRNAME is a cons. >=20 > Which other switches are ignored? >=20 > > It's not about switches that control the order. It's about > > switches that deal with directory (or directories) themselves, > > their entire contents, as opposed to switches that deal only > > with an individual entry to be listed or that (like `r') deal > > only with the set of entries without needing any knowledge of > > the directory. >=20 > Yes, and those are all the switches that control the order of > presenting the files in the listing. I don't agree. Unless you are interpreting "switches that control the order" as including any switch that affects the display. You say that -C, for instance, "controls the order". At least here (I'm using Cygwin), -C lists the entries by columns. It does not change/control the order. And (here anyway), -C has no effect with a cons DIRNAME: With string DIRNAME, -C lists only the file names. With cons DIRNAME, the -C shows a full listing of fields, not just file names. > > On MS Windows `ls-lisp.el' is used, and it says that it supports > > all of these switches: A a B C c F G g h i n R r S s t U u v X > > > > I think that besides `t' and the other sort switches (besides > > `r'), at least `A', `a', `B', and `C' have no effect. >=20 > "-C" is about the order; the others are meaningless when you specify > the files explicitly. Whether -A, -a, and -B are meaningless is in the eye of the user. The point is that if you specify an explicit . or .., switch -A still lists those directories. And switch -a still lists dot files that are in the explicit list. And switch -B still lists backup files that are in the list. Such behavior means that those switches have no effect when DIRNAME is a cons. And they have nothing to do with sort order. And each could be made to work, I think: they require no knowledge of the directory; they just filter the input file names. > The doc string already says that the list of > files to display is specified by the 1st argument in this case. >=20 > So I think the current doc string, after yesterday's changes, fixes > the issues you raised. I don't have that doc string, but I'll take your word for it, modulo what I've noted above. A user should not get the impression that switches such as -A, -a, and -B work, even though they are not about controlling the sort order. IMO, it is not about sort order. > Your other points are specific to ls-lisp.el, No, they are not. The mode-line lighter, for instance, has nothing to do with ls-lisp. It is incorrect for the lighter to indicate the order as being "by name" or "by date" when it is not. > so they don't really belong to this bug report, IMO. Why do you think that what is controlled by the ls-lisp.el code has nothing to do with this bug report? The bug is about certain Dired switches having no effect when DIRNAME is a cons, even though they could work (have the usual effect). It is about fixing that no-effect behavior and documenting the no-effect behavior for the remaining switches that are meaningful only for a directory. The switches that need to be fixed are those that could apply to an explicit set of files and dirs. The fact that the ls-lisp code for -B does not work, and that it raises an error, is part of this bug. I proposed a simple fix for the erroneous error raising. Why not apply it? And why not eventually fix the problem completely, so that -B is supported? There is no reason not to support it, IMO. If there is a lack of resources, then let's keep the bug open until someone steps up. But the error-raising part of the problem can be fixed now, trivially. That's what this bug is about: fixing the fact that some switches that could be effective with a DIRNAME cons are currently ineffective. And fixing the doc so that whatever the behavior is with a cons DIRNAME, it is clearly described. It sounds like you have worked on the latter part, which is great. Thanks for that.