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

Message #23 received at 60872 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60872 <at> debbugs.gnu.org, jonas <at> bernoul.li, emacs18 <at> gmail.com
Subject: Re: bug#60872: 29.0.60; emacsql broken after Jan 12 change
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 :-)

    >> 
    >> Either that or use `make-process' directly and pass `:coding'

    Eli> No, that will suffer from the same problem:

Yep

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