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 12:33:16 -0700 (PDT) Message-ID: <99d84238-3b80-4778-a248-7063a7e6b3df@default> References: <<186494c2-6958-42eb-a351-6543237bfb75@default>> <<838ubvmj2s.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 1433705669 23448 80.91.229.3 (7 Jun 2015 19:34:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jun 2015 19:34:29 +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 21:34:16 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 1Z1gKj-0005G9-3x for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jun 2015 21:34:13 +0200 Original-Received: from localhost ([::1]:55064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1gKi-0004Gu-Br for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jun 2015 15:34:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1gKd-0004Gd-NJ for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 15:34:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1gKZ-0001Pn-Hg for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 15:34:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1gKZ-0001Pi-EP for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 15:34:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z1gKY-0007ZX-Tl for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2015 15:34: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 19:34: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.143370560929066 (code B ref 20739); Sun, 07 Jun 2015 19:34:02 +0000 Original-Received: (at 20739) by debbugs.gnu.org; 7 Jun 2015 19:33:29 +0000 Original-Received: from localhost ([127.0.0.1]:44324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z1gK0-0007Yi-0N for submit@debbugs.gnu.org; Sun, 07 Jun 2015 15:33:29 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:36365) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z1gJw-0007YT-JP for 20739@debbugs.gnu.org; Sun, 07 Jun 2015 15:33:25 -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 t57JXHZu003669 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Jun 2015 19:33:17 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 t57JXF8T025311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 7 Jun 2015 19:33:17 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 t57JXF7n011389; Sun, 7 Jun 2015 19:33:15 GMT In-Reply-To: <<838ubvmj2s.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:103716 Archived-At: > > > > It is not about the order. `r' works, for example - it > > > > reverses the order. > > > > > > 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. (I forgot the quote before the list arg, as I'm sure you realized.) > Not in my Emacs, built from the latest development sources. Interesting. I definitely see the list reversed correctly, even in this very recent build: In GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2015-05-29 on LEG570 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D/mingw32 --host=3Di686-pc-mingw32 --enable-checking=3Dyes,glyphs' > > > 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. >=20 > I do. An odd interpretation of sort order. If the doc relies on users understanding things that way then I'd suggest that it won't work as intended. ;-) > > 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. >=20 > It shows them in column-wise order. What does that even mean? The order of the files listed is unchanged from the input order in DIRNAME. What is changed (removed) is the display of fields besides the file/dir name. > > > 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. >=20 > They are also shown without -A or -a. Specifying any files lists > them regardless. Which is just another way of saying that -A and -a do not remove those dot names. We are agreeing about the effect, but not about what it means. IMO, it means that these switches do not do what they say. In your opinion (I guess) they do what they say, because a user must understand what they say to mean that they do not do what they explicitly in this case, i.e., they do not remove . and ... > > Why do you think that what is controlled by the ls-lisp.el code > > has nothing to do with this bug report? >=20 > Because 'dired' the function is not defined in ls-lisp.el, and it > works even without ls-lisp. On MS Windows (my report is from a Windows build) it uses ls-lisp by default, no? The manual says this: Dired normally uses the external program `ls' to produce the directory listing displayed in Dired buffers (*note Dired::). However, MS-Windows and MS-DOS systems don't come with such a program, although several ports of GNU `ls' are available. Therefore, Emacs on those systems _emulates_ `ls' in Lisp, by using the `ls-lisp.el' package. While `ls-lisp.el' provides a reasonably full emulation of `ls', there are some options and features peculiar to that emulation; they are described in this section. And even if it does work in some cases without ls-lisp, my bug report is about fixing Dired generally, including (explicitly) when ls-lisp is used. Why look for some cases where it might work as a way to claim that there is thus no bug if it does not work in other cases? Especially cases that I specifically reported on from the beginning in the 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). >=20 > Exactly. And they have or don't have effect regardless of ls-lisp. OK, as long as fixing them includes fixing them for ls-lisp. And I pointed out the particular case of -B, for which it is not true (AFAIK) that it has or doesn't have "effect regardless of ls-lisp." The specific problem I pointed to wrt -B is ls-lisp only (AFAIK).