GNU bug report logs - #42904
[PATCH] Non-Unicode frame title crashes Emacs on macOS

Previous Next

Full log

Message #49 received at 42904 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 42904 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#42904: [PATCH] Non-Unicode frame title crashes Emacs on macOS
Date: Tue, 18 Aug 2020 17:40:33 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Tue, 18 Aug 2020 16:11:02 +0200
> Cc: Alan Third <alan <at> idiocy.org>, 42904 <at> debbugs.gnu.org
> 
> 18 aug. 2020 kl. 14.24 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > It isn't wrong (and there's no need to worry about alignment in this
> > case, AFAIK).
> 
> Do you mean that SDATA is guaranteed to be aligned, or that no NS platforms that Emacs runs on (or is likely to run on in the near future, such as macOS on arm64) trap on unaligned?

Both, AFAIK.

> it is not reasonable to depend on non-Unicode characters being translated to spaces

We are not the only program which does that, but.

> > Why is it a problem to display a space instead of invalid bytes in
> > this case?
> 
> A problem is not necessary for a change to be desirable. The Unicode replacement character clearly indicates that something could not be encoded correctly, and the exact position for it

But that character only makes sense when it can be displayed, because
otherwise no one will realize what was the problem.

Anyway, this discussion should be on emacs-devel, not as part of an
unrelated bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.