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: Dired restrictions on arbitrary file & dir listings Date: Sun, 14 Sep 2014 14:30:42 -0700 (PDT) Message-ID: <5c128720-8d8a-459d-b0d8-5ee9ac7d95fe@default> 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 1410730281 507 80.91.229.3 (14 Sep 2014 21:31:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2014 21:31:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 23:31:13 2014 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 1XTHO5-0001Nv-21 for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 23:31:13 +0200 Original-Received: from localhost ([::1]:56300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTHO4-0005RS-Ac for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 17:31:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTHNm-0005RC-Nk for emacs-devel@gnu.org; Sun, 14 Sep 2014 17:31:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTHNf-0007Vo-2W for emacs-devel@gnu.org; Sun, 14 Sep 2014 17:30:54 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:41795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTHNe-0007Vg-S0 for emacs-devel@gnu.org; Sun, 14 Sep 2014 17:30:46 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8ELUjFS018886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 14 Sep 2014 21:30:46 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8ELUin6003868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Sep 2014 21:30:45 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s8ELUi9F001994 for ; Sun, 14 Sep 2014 21:30:44 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:174297 Archived-At: 1. Let users create arbitrary Dired listings interactively? You can open Dired for virtually any list of files and dirs (root directories such as c:/ and / should not be included). Today, you cannot do this interactively, but you can do it by passing a cons DIRNAME arg to `dired': the car is the Dired buffer name, and the cdr is the list of files/dirs. This feature has been present from the beginning, AFAIK, but users are not very aware of it. Why not let users do this interactively, by using a prefix arg <=3D 0? A prefix arg >=3D 0 means prompt for `ls' switches. A non-positive arg would prompt for the buffer name and files. (The current behavior of plain `C-u' would be preserved.) I do this in Dired+, modifying `dired-read-dir-and-switches'. It loops with `read-file-name' using lax completion, so you can use glob patterns to specify multiple files/dirs at once. 2. Remove `dired-insert-subdir-validate'? =20 You can use `i' to insert a subdir listing, but function `dired-insert-subdir-validate' is a gatekeeper that prevents you from inserting a directory in these two cases: * it is not in the same directory tree as `default-directory' * the `ls' switches you request for the listing to insert "conflict" with those for the main listing, where this means that switch -b or -F is present for one and absent for the other This code is quite old. I wonder whether it is really useful. AFAICT so far, it is not. a. The comment that takes the place of a doc string speaks of protecting against trying to insert `..'. But that is already taken care of by the call to `dired-get-filename' in `dired-insert-subdir', which raises the error for `..'. b. Those two cases are completely unrelated. That they find themselves coupled in this function is a bit suspect. c. Why not be able to insert directories that do not belong to the same tree? I have been doing this and have not noticed a problem. I reported this as bug/enhancement #18421 (no response so far). This feature is quite useful. You can not only have Dired list any files and dirs you want, but you can also use `i' to insert any of those dirs. Inserted dirs need not be from the same root (e.g., on Windows, listings can be for dirs on different drives). d. Just what is the purported conflict between having some listings that use some switches and other listings with other listings, when some of them use -b or -F and others do not? There is no indication in the code - no comment. And users are not given a reason in the error message; it says only "Can't have dirs with and without -%s switches together". Well, why not? Again, I've been using `dired-insert-subdir' without `dired-insert-subdir-validate', and I have not noticed a problem. Granted, I use MS Windows, and `ls-lisp' does not always have exactly the behavior of `ls'. But I asked a GNU/Linux user to test briefly, and he saw no problem either. This is not exhaustive testing. But then again, it's not clear what should be tested: just what is the supposed conflict between having a mix of switches (no `F' + `F', or no `b' + `b')? What is `dired-insert-subdir-validate' protecting us from? My guess is that this code is a vestige. Perhaps it used to compensate for `dired-get-filename' not correctly handling file names when -F is present in some listings but absent from others? Nowadays, `dired-get-filename' uses a text property to handle name retrieval correctly, and it seems to have no problem with a mix of F and no-F. Perhaps one of you knows the history of this code and the rationale behind the restrictions imposed by it? I've so far not seen any use for `dired-insert-subdir-validate' (including brief testing with `wdired-mode'). Can we please relax these restrictions? Or can someone please provide a good reason why we should not do so? Dired is a lot more useful if you can use it with an arbitrary listing of files and dirs. If someone wants to test a bit with the code I use, you can get it here: http://www.emacswiki.org/emacs-en/download/dired%2b.el