From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Kenichi Handa <handa@gnu.org>, emacs-devel@gnu.org, handa@m17n.org
Subject: Re: Why does dired go through extra efforts to avoid unibyte names
Date: Fri, 29 Dec 2017 21:17:29 +0200 [thread overview]
Message-ID: <83lghlfinq.fsf@gnu.org> (raw)
In-Reply-To: <jwvpo6xbobe.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 29 Dec 2017 09:34:53 -0500)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 29 Dec 2017 09:34:53 -0500
> Cc: emacs-devel@gnu.org
>
> I bumped into the following code in dired-get-filename:
>
> ;; The above `read' will return a unibyte string if FILE
> ;; contains eight-bit-control/graphic characters.
> (if (and enable-multibyte-characters
> (not (multibyte-string-p file)))
> (setq file (string-to-multibyte file)))
>
> and I'm wondering why we don't want a unibyte string here.
> `vc-region-history` told me this comes from the commit appended below,
> which seems to indicate that we're worried about a subsequent encoding,
> but AFAIK unibyte file names are not (re)encoded, and passing them
> through string-to-multibyte would actually make things worse in this
> respect (since it might cause the kind of (re)encoding this is
> supposedly trying to avoid).
>
> What am I missing?
Why does it matter whether eight-bit-* characters are encoded one more
or one less time?
As for the reason for using string-to-multibyte: maybe it's because we
use concat further down in the function, which will determine whether
the result will be unibyte or multibyte according to its own ideas of
what's TRT?
next prev parent reply other threads:[~2017-12-29 19:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-29 14:34 Why does dired go through extra efforts to avoid unibyte names Stefan Monnier
2017-12-29 19:17 ` Eli Zaretskii [this message]
2018-01-03 4:14 ` Stefan Monnier
2018-01-03 15:10 ` Eli Zaretskii
2018-01-03 20:09 ` Stefan Monnier
2018-01-05 9:10 ` Eli Zaretskii
2018-01-05 16:12 ` Stefan Monnier
2018-01-05 18:14 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83lghlfinq.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=handa@gnu.org \
--cc=handa@m17n.org \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.