Re: [PATCH] Support for Sqlite Archive files

[Eli Zaretskii]

> From: Madhu <enometh@meer.net>
> Date: Sat, 22 Jun 2024 20:35:46 +0530
> 
> * Eli Zaretskii <86ed8qlepr.fsf@gnu.org> :
> Wrote on Fri, 21 Jun 2024 14:25:52 +0300:
> 
> > Thanks, but why do we need a cli utility when we have built-in SQLite
> > support?  Can't we access the SQLite Archive files via that built-in
> > support?  I'd prefer to have that instead of relying on external
> > utility.
> 
> 1. Because the cli-utility will work even when emacs is not built linked
> to libsqlite3.so  (sqlite is an optional dependency), only call-process
> is needed.
> 
> 2. Because arc-mode is a good design abstraction, and extending it to
> support a new format is good design principle.
> 
> Both of these are no-brainers. Why aren't they obvious to you?

They are obvious, but there are other considerations which IMO
outweigh these.

> When did "Introducing a new mode and code just to make an
> optional-dependency non-optional" become a design-goal of Emacs?

It didn't.

> Youve been pushing this relentlessly

I haven't.

> since openssl (gnutls) json,
> treesitter, etc., all encouraging linking with 3rd party libraries, and
> removing the option of having the functionalitu in emacs, without emacs
> depending on those libraries.

GnuTLS is preferred because the alternative communicates with Emacs
via signals, something that is much less portable and also an awful
design.  (We switched to internal timers long ago for the same
reasons.)

JSON library was added because the Lisp implementation was not
performant enough.  (Emacs 30 will have internal JSON code which
tosses the optional library, so this is now a moot point.)

Tree-sitter was added because the internal fontification is not
performant enough and also requires us to have on board experts in the
corresponding language grammars, something that we found to be hard.
(Also, the original modes that do not require tree-sitter are still
available, and enabled by default.)

> Is there some GNU related ideology behind this, or where did the memo
> come from?

No ideology and no memo, just the urge to give you and the other users
the best, most performant Emacs we can.