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

[Mattias Engdegård]

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.

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

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".

0001-Fix-NS-crash-on-invalid-frame-title-string-bug-42904.patch
Description: Binary data