From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Tue, 14 Dec 2021 22:01:33 +0000 Message-ID: References: <874k7ljwkr.fsf@gnus.org> <87fsr5cuzq.fsf@ericabrahamsen.net> <878rwx8mdn.fsf@gnu.org> <87zgpdhw4d.fsf@yahoo.com> <2F63580E-FF58-45D0-9DBB-389ED64C0F11@mit.edu> <83v8zzw867.fsf@gnu.org> <87wnk7kkxp.fsf@red-bean.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39629"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Qiantan Hong , rms@gnu.org, eric@ericabrahamsen.net, cesar.mena@gmail.com, emacs-devel@gnu.org, luangruo@yahoo.com, Eli Zaretskii To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 14 23:03:17 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxFtF-000A8R-HG for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 23:03:17 +0100 Original-Received: from localhost ([::1]:52488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxFtD-0007le-NA for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 17:03:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxFrk-0006zm-PN for emacs-devel@gnu.org; Tue, 14 Dec 2021 17:01:44 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:30893 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mxFrb-0007W9-Vr for emacs-devel@gnu.org; Tue, 14 Dec 2021 17:01:41 -0500 Original-Received: (qmail 15818 invoked by uid 3782); 14 Dec 2021 22:01:34 -0000 Original-Received: from acm.muc.de (p4fe154e3.dip0.t-ipconnect.de [79.225.84.227]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 14 Dec 2021 23:01:33 +0100 Original-Received: (qmail 27485 invoked by uid 1000); 14 Dec 2021 22:01:33 -0000 Content-Disposition: inline In-Reply-To: <87wnk7kkxp.fsf@red-bean.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281949 Archived-At: Hello, Karl. On Tue, Dec 14, 2021 at 14:09:38 -0600, Karl Fogel wrote: > On 10 Dec 2021, Alan Mackenzie wrote: > >I've never used org-mode in my life, and only tried out gnus once, > >around 20 years ago, when it was too slow and too complicated for me. > >Yet I have to pay the costs of these packages every time I build Emacs > >bootstrap. > >I'm not arguing for a removal of these things, which are clearly good. > >But I think it is reasonable to question the wisdom of adding more > >inessential stuff. > You've defined "inessential" in a way that happens to match your > particular usage patterns exactly. Not at all. I was using the word correctly. In the words of Fowler, something is essential when "we have in mind a whole that would not be what it is to be or is or was if the part in question were wanting; the essential thing is such that the other thing is inconceivable without it.". Emacs without gnus would still be Emacs. Emacs without Lisp would not. In that sense Lisp is essential to Emacs but gnus isn't. That is an entirely different question as to what is necessary. Windscreen wipers are necessary on a motor car. But wheels are essential. I'm quite prepared to accept that gnus is necessary for Emacs. > But for others, such as myself, Gnus and Org Mode are essential :-). As above, they're not. They're necessary. I question the wisdom of adding more inessential stuff to the Emacs core. To be perfectly blunt, it is bloat. I'm not saying that sqlite shouldn't be added to core. But I am saying it should be questioned carefully, particularly by people who are familiar with it (which I'm not). I feel sqlite has been added to the core, merged into master, with indecent haste, and without due reflection. This cannot be good. I think there are knowledgeable people here who are against this novelty and I think their expertise has been disregarded. That cannot be good for the Emacs project. > In a thread from 2020 ([1], "GNU Emacs raison d'etre"), I offered > a different understanding of Emacs's essence: > It is the editing environment that best rewards sustained user > investment. > That differs from your claim that "primarily Emacs is a > programmers' text editor". Clarification here. I meant an editor used by programmers, not one programmed by them. > Programming Emacs is simply the highest level of investment, but it > doesn't necessarly imply that one is using Emacs *for* computer > programming -- often, I'm not. Naturally, users who are programmers > are going to have the easiest time investing in their Emacs experience, > both due to skills they have and (probably) due to being > temperamentally inclined towards patience with such investments. > The argument for sqlite3 (or something like it) is that it makes > some of those investments easier -- specifically, it makes it > easier to do things that involve selective access to large > datasets. Yes. It comes with a cost, though, and the cost and the benefit have to be weighed against eachother. > A concrete example is https://code.librehq.com/kfogel/mailaprop/. > Right now, I load all the data in to memory at startup time right, > but it's costly -- it noticeably slows down startup. Fortunately, > I don't restart Emacs very often, so this is liveable. However, > if the dataset were 10x or 20x larger, it would be intolerable. In my mail program, mutt, I load my entire mail collection into memory every time I start it. That's around 140,000 mails, it's over 2 GB, and it loads and threads in 7 or 8 seconds. I don't know how long it would take to load into gnus, but I suspect it would be much longer. > I could of course try out the existing 3rd-party sqlite3 library > for Emacs; it's not like there's a huge barrier here. But still, > that would mean adding a dependency that I don't currently have. > Whereas if the facility were built into Emacs, the barrier would > be lower, so I'd be more likely to experiment with selective > loading of such datasets. Presumably, the same argument applies > to others' applications as well, and we'd have the further > advantage that everyone would be using a common facility, so it > could be improved collaboratively. Yes, those are the plusses. The downsides are the bloat (i don't know by how much), the dilution in Emacs's purpose (it's even less the "do one thing and do it well" than it was), and I suppose there might even be negative security implications (it's a database after all). Also people will be forced to learn new tools, both inside and outside of Emacs. I fear it will create another elite in the Emacs project, those who have mastered sqlite, similar to, for example, those who can read and write the cl- library. > I believe this is one of the points Lars is making. > Best regards, > -Karl > [1] > https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01855.html > From: Karl Fogel > To: > Subject: Re: GNU Emacs raison d'etre > Date: Wed, 13 May 2020 11:18:50 -0500 > Message-ID: <871rnnvmdx.fsf@red-bean.com> -- Alan Mackenzie (Nuremberg, Germany).