From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mike Kupfer Newsgroups: gmane.emacs.bugs Subject: bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' Date: Wed, 10 Jul 2019 22:51:11 -0700 Message-ID: <12410.1562824271@alto> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="261205"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35367@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 11 07:52:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hlS0A-000nwf-DR for geb-bug-gnu-emacs@m.gmane.org; Thu, 11 Jul 2019 07:52:18 +0200 Original-Received: from localhost ([::1]:38730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlS09-0008Aj-Ci for geb-bug-gnu-emacs@m.gmane.org; Thu, 11 Jul 2019 01:52:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60429) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlRzv-0007wM-Dx for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2019 01:52:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlRzt-0005lt-Rt for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2019 01:52:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56353) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlRzt-0005lj-Nu for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2019 01:52:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hlRzt-0004Ha-Jh for bug-gnu-emacs@gnu.org; Thu, 11 Jul 2019 01:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mike Kupfer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2019 05:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35367 X-GNU-PR-Package: emacs Original-Received: via spool by 35367-submit@debbugs.gnu.org id=B35367.156282428416416 (code B ref 35367); Thu, 11 Jul 2019 05:52:01 +0000 Original-Received: (at 35367) by debbugs.gnu.org; 11 Jul 2019 05:51:24 +0000 Original-Received: from localhost ([127.0.0.1]:36941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlRzH-0004Gh-Sw for submit@debbugs.gnu.org; Thu, 11 Jul 2019 01:51:24 -0400 Original-Received: from shell1.rawbw.com ([198.144.192.42]:31256 ident=root) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlRzE-0004GX-25 for 35367@debbugs.gnu.org; Thu, 11 Jul 2019 01:51:21 -0400 Original-Received: from alto (96-95-200-133-static.hfc.comcastbusiness.net [96.95.200.133]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id x6B5pBTD085298 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jul 2019 22:51:17 -0700 (PDT) (envelope-from mkupfer@alum.berkeley.edu) X-Authentication-Warning: shell1.rawbw.com: Host 96-95-200-133-static.hfc.comcastbusiness.net [96.95.200.133] claimed to be alto In-Reply-To: Your message of "Tue, 09 Jul 2019 16:21:24 +0200." <87wogrthjv.fsf@mouse.gnus.org> X-Mailer: MH-E 8.6+git; nmh 1.6; GNU Emacs 26.2.90 Content-ID: <12409.1562824271.1@alto> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:173301 Lars Ingebrigtsen wrote: > Drew Adams writes: > > > 1. I believe `dired-copy-how-to-fn' was added to Emacs quite a while ago > > (1991[1]). lisp/ChangeLog.8 in the 25.3 tarball attributes the change to Inge Frick, with a date of 1999-09-14 (a couple days before the date listed in bug#25075). > > But it's not clear to me what it's really for, and there > > seem to be no uses of it in the distributed Emacs code, apart from > > `dired-do-copy', which just passes it on to `dired-create-files'. > > The variable's doc just says to "See HOW-TO argument for > > `dired-create-files'." > > > > So why was this variable created? Presumably it's so you could override dired's behavior for handling a target. If the target is a symlink to a directory, the default behavior would be to treat it as a directory, but maybe there are cases where you want to replace the link instead. The bit about If it return value is a list, TARGET is a generalized directory (e.g. some sort of archive). The first element of this list must be a function with at least four arguments: looks like it might be useful when the target is, for example, a tar file. By default, copying a single file would replace the tar file. But this could be overridden (I think) to add or replace entries in the tar file. Besides the possibility of a user setting dired-copy-how-to-fn, I can imagine a package might want to dynamically rebind dired-copy-how-to-fn, perhaps as a buffer-local variable in a dired buffer. (I'm not sure what sort of package might want to do that, but it seems like a possible reason for having a variable.) > I hoped that the code might throw some light on this variable, but: > > (defun dired-into-dir-with-symlinks (target) > (and (file-directory-p target) > (not (file-symlink-p target)))) > ;; This may not always be what you want, especially if target is your > ;; home directory and it happens to be a symbolic link, as is often the > ;; case with NFS and automounters. Or if you want to make symlinks > ;; into directories that themselves are only symlinks, also quite > ;; common. > > ;; So we don't use this function as value for HOW-TO in > ;; dired-do-symlink, which has the minor disadvantage of > ;; making links *into* a symlinked-dir, when you really wanted to > ;; *overwrite* that symlink. In that (rare, I guess) case, you'll > ;; just have to remove that symlink by hand before making your marked > ;; symlinks. > > (defvar dired-copy-how-to-fn nil > "Either nil or a function used by `dired-do-copy' to determine target. > See HOW-TO argument for `dired-do-create-files'.") > > It's still clear as mud to me. dired-into-dir-with-symlinks returns t if TARGET is a real directory. It returns nil if TARGET is a plain file or a symlink to a directory. The first generation automounter(s) mounted your home directory in a temporary directory and then created a symlink to the mounted directory. But $HOME would be the path to the symlink. > My interpretation of t is that all files you copy will up in the same > file if it's t, which is a supremely useless thing, you'd think... No, you can only copy one file if the target is a plain file. From earlier in the docstring for dired-do-create-files: The target may also be a non-directory file, if only one file is marked. Maybe this sentence should be deleted: Otherwise, the target is a plain file; an error is raised unless there is exactly one marked file. The way the docstring is currently written, it seems to imply that the error only gets raised in the case where HOW-TO is nil. I agree that this is all very complicated and confusing. It doesn't help that if HOW-TO is t, the target is treated as a plain file. But if HOW-TO is a function, it returns nil to indicate a plain file. mike