GNU bug report logs - #60872
29.0.60; emacsql broken after Jan 12 change

Previous Next

Package: emacs;

Reported by: emacs18 <at> gmail.com

Date: Tue, 17 Jan 2023 04:51:01 UTC

Severity: normal

Found in version 29.0.60

Done: Eli Zaretskii <eliz <at> gnu.org>

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: Robert Pluim <rpluim <at> gmail.com>
Cc: 60872 <at> debbugs.gnu.org, jonas <at> bernoul.li, emacs18 <at> gmail.com
Subject: bug#60872: 29.0.60; emacsql broken after Jan 12 change
Date: Tue, 17 Jan 2023 16:54:19 +0200
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: jonas <at> bernoul.li,  emacs18 <at> gmail.com,  60872 <at> debbugs.gnu.org
> Date: Tue, 17 Jan 2023 15:42:06 +0100
> 
> >>>>> On Tue, 17 Jan 2023 15:58:10 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Is it enough of an error for us to silently replace `utf-8-auto' with
>     >> `utf-8' when itʼs specified for `coding-system-for-write'?
> 
>     Eli> That's what the bug I fixed effectively did.  But no, I don't think
>     Eli> this is something we can do, let alone silently.  It could be that
>     Eli> some extremely rare/obscure, but nevertheless legitimate use case does
>     Eli> really want to produce BOM on encoding.
> 
> Right. Iʼd suggest a doc change, but thereʼs no documentation for
> `utf-8-auto' anyway, and perhaps we should avoid drawing attention to
> it :-)

I agree.  I'm curious what Jonas will tell us about this particular
use of it.




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

Previous Next


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