unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 35367@debbugs.gnu.org
Subject: bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files'
Date: Tue, 09 Jul 2019 16:21:24 +0200	[thread overview]
Message-ID: <87wogrthjv.fsf@mouse.gnus.org> (raw)
In-Reply-To: <dd28182c-a94d-4654-9d7c-48124886657e@default> (Drew Adams's message of "Sun, 21 Apr 2019 12:30:14 -0700 (PDT)")

Drew Adams <drew.adams@oracle.com> writes:

> 1. I believe `dired-copy-how-to-fn' was added to Emacs quite a while ago
>    (1991[1]).  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?

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.

> 2. Apart from the variable, why was the HOW-TO arg of
>    `dired-do-create-files' added?  I find no uses of it, apart from
>    `dired-do-copy' (which just passes it along).
>
>    Presumably someone thought that someone might want to pass such a
>    thing to `dired-do-copy', but why?
>
>    Half the doc of `dired-do-create-files' is for this parameter.  And
>    its description, although probably correct and complete, reads like
>    gobbledygook, to me.
>
>    For one thing, the nil case should not be described under this
>    parameter; it should be described as the function's default behavior,
>    up above the parameter list.  (That's already 4 lines of its
>    description.)

Well...  I think it makes sense (in so far as this parameter makes any
sense) to keep it where it is:

Optional arg HOW-TO determines how to treat the target.
  If HOW-TO is nil, use `file-directory-p' to determine if the
   target is a directory.  If so, the marked file(s) are created
   inside that directory.  Otherwise, the target is a plain file;
   an error is raised unless there is exactly one marked file.
  If HOW-TO is t, target is always treated as a plain file.
  Otherwise, HOW-TO should be a function of one argument, TARGET.
   If its return value is nil, TARGET is regarded as a plain file.
   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:
      operation - as OPERATION above.
      rfn-list  - list of the relative names for the marked files.
      fn-list   - list of the absolute names for the marked files.
      target    - the name of the target itself.
    The rest of elements of the list returned by HOW-TO are optional
    arguments for the function that is the first element of the list.
   For any other return value, TARGET is treated as a directory."


>    Beyond that:
>
>    * A value of `t' is unclear to me.  What does it mean to target a
>      plain file - is this the same as using a `nil' value?  What happens
>      with `t' if the target is a directory or if there are multiple
>      marked files?  Is that where the difference lies somehow (how)?

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...

>    It was apparently RMS who added this [1].  I'm surprised that it's
>    not more clear what good it is.

Does anybody know what this parameter and variable was meant to do, and
whether it's used anywhere out-of-tree?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2019-07-09 14:21 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-21 19:30 bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' Drew Adams
2019-07-09 14:21 ` Lars Ingebrigtsen [this message]
2019-07-11  5:51   ` Mike Kupfer
2019-07-11 14:04     ` Lars Ingebrigtsen
2019-07-11 14:18     ` Drew Adams
2019-07-12  3:20       ` Mike Kupfer
2019-07-12  3:33         ` Drew Adams
2022-01-22 14:43     ` Lars Ingebrigtsen
  -- strict thread matches above, loose matches on Subject: below --
2020-07-30  4:01 bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work Brett Randall
     [not found] ` <handler.42611.B.159608273314264.ack@debbugs.gnu.org>
     [not found]   ` <(Brett>
2020-10-17  8:41 ` Lars Ingebrigtsen
2020-10-27 10:36   ` brett.randall
     [not found]     ` <(brett>
     [not found]       ` <randall's>
     [not found]         ` <"Tue,>
     [not found]           ` <27>
     [not found]             ` <Oct>
2020-10-27 10:43     ` Lars Ingebrigtsen
2020-10-27 10:49       ` Brett Randall
2020-10-27 11:08         ` Lars Ingebrigtsen
     [not found]           ` <(Lars>
     [not found]             ` <Ingebrigtsen's>
     [not found]               ` <12:08:50>
2020-10-27 11:19           ` bug#42611: (no subject) Lars Ingebrigtsen
     [not found]             ` <877drbhq6c.fsf@gnus.org>
     [not found]               ` <handler.42611.C.160379757411378.notifdonectrl.0@debbugs.gnu.org>
2020-10-27 22:22                 ` bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work Brett Randall
2020-05-21 16:56 bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers Philip K.
2020-05-21 22:18 ` Juri Linkov
2020-05-22 18:26   ` Philip K.
     [not found]   ` <(message>
     [not found]     ` <from>
     [not found]       ` <Juri>
     [not found]         ` <Linkov>
     [not found]           ` <on>
     [not found]             ` <Fri>
     [not found]               ` <22>
     [not found]                 ` <May>
     [not found]                   ` <2020>
     [not found]                     ` <04:01:05>
     [not found]                     ` <01:18:18>
     [not found]                       ` <+0300)>
     [not found]                         ` <87v9kn7rnk.fsf@bulbul>
2020-05-22 19:15                           ` Drew Adams
2020-05-23 22:12                           ` Juri Linkov
2020-06-26 19:46 ` Philip K.
2020-06-27 23:53   ` Juri Linkov
2020-06-28  8:30     ` Philip K.
2020-06-28 23:37       ` Juri Linkov
2020-08-05 18:05         ` Lars Ingebrigtsen
2020-08-05 23:40           ` Juri Linkov
2020-08-06  9:28             ` Philip K.
2020-08-06 23:43               ` Juri Linkov
2020-08-07 10:53                 ` Philip K.
2020-08-08 23:54                   ` Juri Linkov
2021-05-12 20:38                   ` Lars Ingebrigtsen
2021-05-12 21:27                     ` Philip Kaludercic
2021-05-22 20:29                     ` Philip Kaludercic
2021-05-22 21:09                       ` Philip Kaludercic
2021-05-23  6:49                         ` Eli Zaretskii
2021-05-23 12:36                           ` Philip Kaludercic
2021-05-25  5:12                       ` Lars Ingebrigtsen
2021-05-25  7:25                         ` Philip Kaludercic
2021-05-25  9:53                         ` Philip Kaludercic
2021-05-25 11:16                           ` Arthur Miller
2021-05-25 11:42                             ` Philip Kaludercic
2021-05-25 13:31                               ` Arthur Miller
2021-05-25 14:39                                 ` Philip Kaludercic
2021-05-25 11:36                           ` Arthur Miller
2021-05-25 11:46                             ` Philip Kaludercic
2021-05-25 13:58                               ` Arthur Miller
2021-05-25 19:13                             ` Lars Ingebrigtsen
2021-05-25 19:16                           ` Lars Ingebrigtsen
2021-05-25 19:25                             ` Philip Kaludercic
2021-05-25 20:18                           ` Juri Linkov
2021-05-25 21:45                             ` Philip Kaludercic
2021-05-26 21:35                               ` Juri Linkov
2021-05-27 11:09                                 ` Philip Kaludercic
2021-05-30 22:11                                   ` Juri Linkov
2021-05-31  8:50                                     ` Philip Kaludercic
2021-05-31 20:15                                       ` Juri Linkov
2021-05-31 21:27                                         ` Philip Kaludercic
2021-06-03 20:36                                           ` Juri Linkov
     [not found] <Your>
     [not found] ` <message>
     [not found]   ` <of>
     [not found]     ` <"Thu,>
     [not found]     ` <"Thu>
     [not found]     ` <"Tue>
     [not found]       ` <09>
     [not found]         ` <Jul>
     [not found]           ` <2019>
     [not found]             ` <07:18:26>
     [not found]             ` <16:21:24>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wogrthjv.fsf@mouse.gnus.org \
    --to=larsi@gnus.org \
    --cc=35367@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).