emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Support for Sqlite Archive files


From: Björn Bidar
Subject: Re: [PATCH] Support for Sqlite Archive files
Date: Sun, 23 Jun 2024 02:50:38 +0300
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.
>
Also it is not really an argument to complain about external
dependencies when they come in the form of a library than a cli
program, dependency is dependency.

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

Are you talking about the OpenSSL CLI or the library?

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


There's also the advantage of using an upstream library vs. maintaining
your own shim around Tree-sitter grammars.
 
>> 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.

I also want to add that parsing command line utilities is hacky at best
without a structured format. There's also the advantage that using
extern libraries can workaround Emacs single threaded nature although
that is something that external commands too however I don't think they
are really intended as an interface to a library unless there's a
defined IPC such as in the case of GNUPG.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]