[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.
- [PATCH] Support for Sqlite Archive files, Vladimir Kazanov, 2024/06/21
- Re: [PATCH] Support for Sqlite Archive files, Madhu, 2024/06/22
- Re: [PATCH] Support for Sqlite Archive files, Eli Zaretskii, 2024/06/22
- Re: [PATCH] Support for Sqlite Archive files,
Björn Bidar <=
- Re: [PATCH] Support for Sqlite Archive files, Eli Zaretskii, 2024/06/23
- Re: [PATCH] Support for Sqlite Archive files, Madhu, 2024/06/23
- Re: [PATCH] Support for Sqlite Archive files, Richard Stallman, 2024/06/27
- Re: [PATCH] Support for Sqlite Archive files, tomas, 2024/06/28
- Re: [PATCH] Support for Sqlite Archive files, Richard Stallman, 2024/06/30
- Re: [PATCH] Support for Sqlite Archive files, Collin Funk, 2024/06/28