bug#60872: 29.0.60; emacsql broken after Jan 12 change

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 60872@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 17 Jan 2023 11:02:29 +0100
> 
> >>>>> On Mon, 16 Jan 2023 20:50:00 -0800, Richard Kim <emacs18@gmail.com> 
> >>>>> said:
> 
>     Richard> On Jan 12 Eli checked in cfd2b3504ab on emacs-29 branch on Jan 
> 12 which seemed to have broken emacssql used by org-roam package. Following 
> is the stack trace I get using emacs-29 built after cfd2b3504ab was checked 
> in.
> 
>     Richard> ,----
>     Richard> | Debugger entered--Lisp error: (error "Selecting deleted 
> buffer")
>     Richard> |   #f(compiled-function (connection) "Return true if the end of 
> the buffer has a properly-formatted prompt." #<bytecode 
> 0x192bbe2fe99c5127>)(#<emacsql-sqlite-connection 
> emacsql-sqlite-connection-15656bd9678a>)
>     Richard> |   apply(#f(compiled-function (connection) "Return true if the 
> end of the buffer has a properly-formatted prompt." #<bytecode 
> 0x192bbe2fe99c5127>) #<emacsql-sqlite-connection 
> emacsql-sqlite-connection-15656bd9678a> nil)
> 
> I can reproduce this, itʼs because the sqlite process is dying
> almost straight away in emacsql-sqlite.el:
> 
>     (cl-defmethod initialize-instance :after
>       ((connection emacsql-sqlite-connection) &rest _rest)
>       (emacsql-sqlite-ensure-binary)
>       (let* ((process-connection-type nil)  ; use a pipe
>              (coding-system-for-write 'utf-8-auto)
>              (coding-system-for-read 'utf-8-auto)
>              (file (slot-value connection 'file))
>              (buffer (generate-new-buffer " *emacsql-sqlite*"))
>              (fullfile (if file (expand-file-name file) ":memory:"))
>              (process (start-process  <== dies
>                        "emacsql-sqlite" buffer emacsql-sqlite-executable 
> fullfile)))
>         (setf (slot-value connection 'process) process)
>         (setf (process-sentinel process)
>               (lambda (proc _) (kill-buffer (process-buffer proc))))
>         (emacsql-wait connection)
>         (emacsql connection [:pragma (= busy-timeout $s1)]
>                  (/ (* emacsql-global-timeout 1000) 2))
>         (emacsql-register connection)))
> 
> If I use
> 
>              (coding-system-for-read 'utf-8)
> 
> instead it all works fine.

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

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

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

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

> Eli, what debug would you like? If I donʼt kill the " *emacsql-sqlite*"
> buffer it contains

I don't think there's anything to debug, the reason is quite clear: a
bug in emacsql-sqlite.el.