all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Third <alan@idiocy.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 48902@debbugs.gnu.org, larsi@gnus.org, salutis@me.com,
	naofumi@yasufuku.dev
Subject: bug#48902: 28.0.50; Directory names containing apostrophes and backticks cause problems
Date: Tue, 8 Jun 2021 20:24:26 +0100	[thread overview]
Message-ID: <YL/D6ip/z/RZN68W@idiocy.org> (raw)
In-Reply-To: <83lf7kdy8h.fsf@gnu.org>

On Tue, Jun 08, 2021 at 09:09:51PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 8 Jun 2021 17:19:44 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: larsi@gnus.org, naofumi@yasufuku.dev, 48902@debbugs.gnu.org,
> > 	salutis@me.com
> > 
> > In this case the call to ENCODE_FILE in allocInitFromFile is actually
> > redundant because image_find_image_fd already calls ENCODE_FILE on the
> > filename before passing it back. So we get a UTF-8 string no matter
> > what.
> 
> Then why was the code re-encoding t in UTF-16?  A bug?

No, sorry, I'm not being clear. The internal format of NSString is
UTF-16. We can load practically anything into it, as long as we know
ahead of time what the encoding is.

> > NSString can read in almost anything, and Mattias extended it to read
> > in multibyte (and ascii) lisp strings, so we don't need a UTF-16 input
> > specifically. It would probably be nice if NSString was also able to
> > recognise that a lisp string is UTF-8 and handle that itself, but I
> > don't think that's really possible, unless we make the assumption that
> > any unibyte string it's passed will already be ascii or UTF-8.
> > 
> > I don't know if that's a reasonable assumption.
> 
> Any file name passed through ENCODE_FILE should be in UTF-8 on macOS,
> as I understand that's how the macOS filesystems work.  Am I mistaken?
> Can the value of default-file-name-coding-system on macOS be anything
> other than UTF-8?

Not as far as I'm aware. But NSString is used all over the place in
the NS port code base (and all through the toolkit). Any time we pass
a string to or from the toolkit it has to be converted to or from
NSString. I think most of the actual file access code in Emacs is low
level C code which won't go near NSString, though, so it's not worth
changing C code to make ObjC code cleaner.

I guess I'm just being lazy and would like our extensions to NSString
to just DTRT, but it seems that's impractical. :)
-- 
Alan Third





      reply	other threads:[~2021-06-08 19:24 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 13:32 bug#48902: 28.0.50; Directory names containing apostrophes and backticks cause problems Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-07 14:08 ` Lars Ingebrigtsen
2021-06-07 14:15   ` Eli Zaretskii
2021-06-07 14:24   ` Lars Ingebrigtsen
2021-06-07 14:36     ` Eli Zaretskii
2021-06-07 14:13 ` Eli Zaretskii
2021-06-08 22:21   ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-08 10:39 ` naofumi
2021-06-08 11:57   ` Lars Ingebrigtsen
2021-06-08 12:12     ` Alan Third
2021-06-08 12:14       ` Lars Ingebrigtsen
2021-06-08 17:45         ` Mattias Engdegård
2021-06-08 18:18           ` Eli Zaretskii
2021-06-08 19:13             ` naofumi
2021-06-08 20:08               ` Mattias Engdegård
2021-06-08 19:10           ` Alan Third
2021-06-08 19:52             ` Mattias Engdegård
2021-06-08 20:33               ` Alan Third
2021-06-09 11:40                 ` Mattias Engdegård
2021-06-09 15:19                   ` Alan Third
2021-06-11 22:09                     ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-09 11:56                 ` Eli Zaretskii
2021-06-08 18:17         ` Mattias Engdegård
2021-06-08 12:37       ` Eli Zaretskii
2021-06-08 13:00         ` Alan Third
2021-06-08 14:02           ` Eli Zaretskii
2021-06-08 16:19             ` Alan Third
2021-06-08 18:09               ` Eli Zaretskii
2021-06-08 19:24                 ` Alan Third [this message]

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=YL/D6ip/z/RZN68W@idiocy.org \
    --to=alan@idiocy.org \
    --cc=48902@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    --cc=naofumi@yasufuku.dev \
    --cc=salutis@me.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 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.