GNU bug report logs - #64697
29.0.92: cannot paste NUL on macOS (regression from Emacs 28)

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattias.engdegard <at> gmail.com>

Date: Tue, 18 Jul 2023 08:32:01 UTC

Severity: normal

Found in version 29.0.92

Done: Mattias Engdegård <mattias.engdegard <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: alan <at> idiocy.org, 64697 <at> debbugs.gnu.org
Subject: bug#64697: 29.0.92: cannot paste NUL on macOS (regression from Emacs 28)
Date: Tue, 18 Jul 2023 16:02:50 +0300
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Tue, 18 Jul 2023 14:00:49 +0200
> Cc: 64697 <at> debbugs.gnu.org,
>  alan <at> idiocy.org
> 
> 18 juli 2023 kl. 13.28 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > do we want a unibyte string
> > here or a multibyte string?
> >  We should try to call either
> > make_unibyte_string or make_multibyte_string accordingly, because
> > make_string has its own ideas about which one to produce.
> 
> That is more than I expected to change in emacs-29, but we could do that too if you like.

Let's install your change on emacs-29, and do the rest (if needed) on
master.

> Since the input is UTF-8 the result, with the patch, will always be either a multibyte string or a unibyte ASCII string. Always making a multibyte string would also do and be marginally faster, but not more correct in any meaningful way.

OK, but please add a comment there with the above rationale.

Thanks.




This bug report was last modified 2 years and 2 days ago.

Previous Next


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