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: Sat, 6 Jun 2015 14:57:05 -0700 (PDT) Message-ID: References: <> <<83oaksmyc8.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 1433627910 4973 80.91.229.3 (6 Jun 2015 21:58:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2015 21:58:30 +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 Sat Jun 06 23:58:17 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 1Z1M6U-0007Rj-K1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jun 2015 23:58:10 +0200 Original-Received: from localhost ([::1]:52590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1M6U-0004B0-1X for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jun 2015 17:58:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1M6Q-0004Au-L1 for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2015 17:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1M6N-0002l2-AP for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2015 17:58:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1M6N-0002ky-6Q for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2015 17:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z1M6M-0003k3-P5 for bug-gnu-emacs@gnu.org; Sat, 06 Jun 2015 17:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jun 2015 21:58:02 +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.143362783314323 (code B ref 20739); Sat, 06 Jun 2015 21:58:02 +0000 Original-Received: (at 20739) by debbugs.gnu.org; 6 Jun 2015 21:57:13 +0000 Original-Received: from localhost ([127.0.0.1]:43537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z1M5Y-0003iw-K9 for submit@debbugs.gnu.org; Sat, 06 Jun 2015 17:57:13 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:35433) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z1M5W-0003ig-Nd for 20739@debbugs.gnu.org; Sat, 06 Jun 2015 17:57:11 -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 t56Lv3l1006104 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Jun 2015 21:57:04 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t56Lv3qn028870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Jun 2015 21:57:03 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t56Lv3vt024980; Sat, 6 Jun 2015 21:57:03 GMT In-Reply-To: <<83oaksmyc8.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:103679 Archived-At: > > The behavior is limited, I'm guessing, wrt any parts of `ls' that > > depend on the whole list of files and subdirs. It seems that > > parts of the `ls' behavior that depend only on the info about a > > given file are retained. >=20 > Yes. >=20 > > First, the doc should specify what I said above (if it is in fact > > the case): `ls' behavior that depends on the entire list is not > > available for this use case - the only switches that affect the > > display are those that depend only on the info for an individual > > file or dir; other switches are ignored. >=20 > 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. I think > this makes the actual behavior clear enough. It is not about the order. `r' works, for example - it reverses the order. And anyway I don't think that sort-order switches are the only ones that are ignored/irrelevant when DIRNAME is a cons. 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. 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. BTW, I see a bug for `B': (dired-other-window '("foo" "toto.el" "foo.el") "-B") The problem is at the beginning of `ls-lisp-insert-directory, AFAICT. There we see this code on the first line: (if (or wildcard-regexp full-directory-p) But that is incorrect, because when switch `B' is used we do this (ugly hack) in `ls-lisp--insert-directory': (if (memq ?B switches) (setq wildcard-regexp "[^~]\\'")) and this, similarly: (setq wildcard-regexp (if (memq ?B switches) "[^~]\\'") file (file-relative-name orig-file)) IOW, we use a pseudo wildcard-regexp. And that doesn't work with this call: (directory-files-and-attributes dir nil wildcard-regexp t (if (memq ?n switches) 'integer 'string)) Debugger entered--Lisp error: (file-error "Opening directory" "No such file or directory" "d:/the/path/to/foo.el/foo.el/") directory-files-and-attributes("foo.el/" nil "[^~]\\'" t string) ls-lisp-insert-directory("foo.el" (66) nil "[^~]\\'" nil) ls-lisp--insert-directory(... If I change the (if (or wildcard-regexp full-directory-p) to this then it seems to fix the problem of raising an error: (if (or (and wildcard-regexp (not (string=3D "[^~]\\'" wildcard-regexp))) full-directory-p) But that is not a complete fix. It does not solve the problem that `B' does not work for a cons DIRNAME. =20 I'm not sure what the right fix is for that, since it's not clear to me where switch `-B' is handled. A guess is that for a whole directory (not for a cons DIRNAME or for a non-dir filename) it is handled by `directory-files-and-attributes'. And I'm guessing that that function should still (after a fix) be called only for the non-cons DIRNAME case. In that case, I'm guessing that `ls-lisp-insert-directory' should test for the pseudo wildcards-regexp "[^~]\\'" and should then DTRT to list the entry showing the block size. Maybe you can take a look at what that code should be. Of course, we can just implement the fix I described above, to prevent an error being raised, and document that `-B' is not supported for cons DIRNAME. It would be better to make it DTRT, however. This switch needs only to consider a single file or dir name entry, so it should be possible to support it. [BTW, `g' and `n' are listed as supported, but the ls-lisp doc says that `l' is always assumed (cannot be overridden), so I don't think `g' or `n' is really supported (`g' is supposed to be like `l' but does now show owner; `n' is supposed to show numeric user and group ids). At least I don't see `g' and `n' having any effect. Perhaps this is an ls-lisp.el bug?] IOW, the switches that correspond to your "Yes" agreement, above, have no effect when DIRNAME is a cons. > > Second, it's not just about the doc string. If no improvement > > in the behavior is to be expected (I would prefer that it be > > improved to respect the switches generally, to the extent that is > > possible), then I think a minimum bug fix, beyond the doc (see > > above), would be to change the mode-line lighter. At a bare > > minimum, the misleading lighter indications "by name|date" need > > to be removed. > > > > Whe DIRNAME is a cons, the lighter should not show anything like > > "by name" or "by date". Instead, it should either have just > > "Dired" or (better) include some indication that the listing is > > from an explicit list and not necessarily a directory listing. > > In the latter case, it could also show the (relevant) switches. >=20 > The 's' toggle's implementation is problematic to begin with, IMO, > so it's small wonder that it doesn't work right in this case. It is not about the `s' toggle. It is about switches. There are multiple switches that are currently not supported for cons DIRNAME, including but not limited to most of the switches that handle sort order.