From: Stefan Kangas <stefan@marxist.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 48657@debbugs.gnu.org, Rodrigo Morales <moralesrodrigo1100@gmail.com>
Subject: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Sun, 24 Oct 2021 00:11:28 -0700 [thread overview]
Message-ID: <CADwFkm=rMCKKnLRAVv=GyBe_1L3p_t7Gj=+Zg+nmP1+VsMf7wQ@mail.gmail.com> (raw)
In-Reply-To: <83bl8yboat.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 25 May 2021 22:34:18 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Rodrigo Morales <moralesrodrigo1100@gmail.com>
>> Date: Tue, 25 May 2021 14:12:02 -0500
>>
>> (defun dired-copy-filename-as-kill (&optional arg)
>> ...
>> (mapconcat #'identity
>> (if arg
>> (cond ((zerop (prefix-numeric-value arg))
>> (dired-get-marked-files))
>> ((consp arg)
>> (dired-get-marked-files t))
>> (t
>> (dired-get-marked-files
>> 'no-dir (prefix-numeric-value arg))))
>> (dired-get-marked-files 'no-dir))
>> " ") ;; <---- [[[ Here's the hardcoded delimiter ]]]
>> ...)
>> #+END_SRC
>>
>> I thought that it would be useful to have a defvar that allows
>> specifying the delimiter for copied filenames through the mentioned
>> function. Perhaps, its name could be "dired-copy-filename-delimiter".
>
> The only sane value for a reliable delimiter is the null byte, so
> maybe it doesn't make much sense to customize it.
That's true, but on the other hand replacing space with the null byte as
the hard-coded delimiter for dired-copy-filename-as-kill seems a
bit... clunky. Even if space sometimes fails, it is not a control
character, which is why I assume that it was chosen.
I've personally never had a problem with using space here, but you
obviously will eventually run into problems. So I think something
should be done.
I was thinking for a while about allowing a user to set the delimiter
with a prefix command, but then I realized that users might be using
this function *a lot* (I do sometimes) and that UI would quickly get
old.
So perhaps we should just provide the asked for defvar?
next prev parent reply other threads:[~2021-10-24 7:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-25 19:12 bug#48657: Defvar delimiter for dired-copy-filename-as-kill Rodrigo Morales
2021-05-25 19:34 ` Eli Zaretskii
2021-10-24 7:11 ` Stefan Kangas [this message]
2021-10-24 12:01 ` Eli Zaretskii
2021-10-24 12:27 ` Stefan Kangas
2021-10-24 14:01 ` Eli Zaretskii
2021-10-24 14:27 ` Stefan Kangas
2022-07-15 10:37 ` Lars Ingebrigtsen
2022-07-15 14:16 ` Drew Adams
2021-05-25 19:44 ` bug#48657: [External] : " Drew Adams
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='CADwFkm=rMCKKnLRAVv=GyBe_1L3p_t7Gj=+Zg+nmP1+VsMf7wQ@mail.gmail.com' \
--to=stefan@marxist.se \
--cc=48657@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=moralesrodrigo1100@gmail.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).