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: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60872 <at> debbugs.gnu.org, Jonas Bernoulli <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 14:10:13 +0100
>>>>> On Tue, 17 Jan 2023 14:45:30 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> If I use
    >> 
    >> (coding-system-for-read 'utf-8)
    >> 
    >> instead it all works fine.

    Eli> coding-system-for-read or coding-system-for-write?  The offending
    Eli> commit didn't change anything about decoding, it only changed how
    Eli> utf-8-auto behaves on _encoding_.  So I expect the problem to be with
    Eli> coding-system-for-write.

Youʼre right, Iʼd inverted my testing.

This fails:

         (coding-system-for-write 'utf-8-auto)
         (coding-system-for-read 'utf-8)

This works:

         (coding-system-for-write 'utf-8)
         (coding-system-for-read 'utf-8-auto)

    Eli> Anyway, it sounds like someone else thought utf-8-auto is about EOL
    Eli> format?  Setting coding-system-for-write to utf-8-auto makes no sense;
    Eli> that coding-system's _only_ raison d'être is for using in
    Eli> coding-system-for-read, i.e. when decoding stuff that may or may not
    Eli> start with a BOM.

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> Jonas, any idea why these coding-systems are used in
    Eli> emacsql-sqlite.el?  The Git log of the package offers no explanation,
    Eli> and I find no references to it in Issues or PRs around the date of the
    Eli> commit.

    Eli> If indeed there's sometimes a need to send to the process stuff that
    Eli> is encoded in UTF-8 with BOM, then instead of binding
    Eli> coding-system-for-write around start-process, you should set it using
    Eli> set-process-coding-system only _after_ the process starts, because the
    Eli> way the code is written now, utf-8-auto is also used to encode the
    Eli> command-line arguments to the sub-process, and so, for example,
    Eli> fullfile (which I presume is a file name?) gets the BOM prepended, and
    Eli> I'm guessing the program emacsql-sqlite isn't prepared for that, and
    Eli> exits abnormally.

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

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.