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

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattiase <at> acm.org>

Date: Mon, 17 Aug 2020 14:13:02 UTC

Severity: normal

Tags: patch

Merged with 41184

Found in version 28.0.50

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 42904 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#42904: [PATCH] Non-Unicode frame title crashes Emacs on macOS
Date: Tue, 18 Aug 2020 19:28:26 +0200 (CEST)
On Tue, Aug 18, 2020 at 01:48:10PM +0200, Mattias Engdegård wrote:
> 18 aug. 2020 kl. 10.43 skrev Alan Third <alan <at> idiocy.org>:
> > Anyway, as I understand it the internal representation of NS strings
> > are UTF-16, so the conversion through UTF-8 seems a bit of a waste if
> > we can go direct.
> 
> Maybe, but the conversion to UTF-16 then has to be done on the Emacs
> side instead, probably less efficiently than in the NS libs. It's
> probably a wash.
> 
> Anyway, here is an alternative patch using your method. Tell us what
> you think.

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.

I don't know if this is worth it because I don't know if we really
need these clean conversions elsewhere, but the neatness of

    newStr = [NSString withLispObject:str];

appeals. :)
-- 
Alan Third




This bug report was last modified 4 years and 269 days ago.

Previous Next


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