bug#42904: [PATCH] Non-Unicode frame title crashes Emacs on macOS

[Alan Third]

On Thu, Aug 20, 2020 at 11:27:01AM +0200, Mattias Engdegård wrote:
> 18 aug. 2020 kl. 19.28 skrev Alan Third <alan@idiocy.org>:
> 
> > Looks good to me. The only thought I have is that perhaps we should
> > consider extending NSString to handle these lisp strings rather than
> > making it a separate function? We could provide a method to convert to
> > a lisp string as well, although that's not as complex.
> > 
> > I believe using categories would do it without us having to create a
> > new EmacsString class or similar.
> 
> Fun, I hadn't done that before! Of course we should.
> 
> As it happens I just enjoyed the HOPL paper about the history of
> Objective-C (https://dl.acm.org/doi/10.1145/3386332). An excellent
> read in general, and it has some history about how the categories
> came about.

I haven't seen that before and am just reading through it now. Thanks.

> Here is an updated patch: it is now self-contained and does not
> change anything outside the NS backend.

It looks good to me. The only thing I'd like you to change is to move
the implementation down to the "Class implementations" part of
nsfns.m.

> There is a minor imperfection: the incoming name string can actually
> be miscoded if it contains both non-ASCII characters and raw bytes.
> As an example, consider
> 
>  (rename-buffer "aéb\300")
> 
> In xdisp.c:12497, the Lisp name string is created using make_string
> which decides that the above multibyte string should really be
> unibyte, and that confuses the converter. It is of no great
> consequence, but it makes the result look messier than it should
> have: "a��b��c" instead of "aéb�c".

I think we can live with that, it's definitely better than a crash and
seems reasonable given that the input is junk.

Thanks!
-- 
Alan Third