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: Mon, 6 Dec 2021 17:38:29 +0000 Message-ID: References: <87tufmjyai.fsf@gnus.org> 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="29136"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 06 18:39:38 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 1muHxh-0007Oy-Vs for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 18:39:37 +0100 Original-Received: from localhost ([::1]:57662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muHxg-0002hl-EV for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 12:39:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muHwt-00020Z-1p for emacs-devel@gnu.org; Mon, 06 Dec 2021 12:38:47 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:13750 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1muHwq-00061y-CH for emacs-devel@gnu.org; Mon, 06 Dec 2021 12:38:46 -0500 Original-Received: (qmail 81744 invoked by uid 3782); 6 Dec 2021 17:38:31 -0000 Original-Received: from acm.muc.de (p4fe15d73.dip0.t-ipconnect.de [79.225.93.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 06 Dec 2021 18:38:30 +0100 Original-Received: (qmail 9681 invoked by uid 1000); 6 Dec 2021 17:38:29 -0000 Content-Disposition: inline In-Reply-To: <87tufmjyai.fsf@gnus.org> 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=ham 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:281139 Archived-At: Hello, Lars. On Mon, Dec 06, 2021 at 02:51:33 +0100, Lars Ingebrigtsen wrote: > I think many user experience things in Emacs would be better if Emacs > remembered more. > The bigger systems don't have this problem -- Gnus needs a large > .newsrc.eld file, and it maintains that. > The tiny things don't really have this problem, either: You save options > with `customize-save-variable', and that fine. > It's the many things that fall between these two extremes that have the > problem: Where you want to store some state, but figuring it's just too > much work to figure out Yet Another Storage Format, but the data is too > messy to stash in somebody's .emacs file via Customize (like lists of > stuff). > So there's a bunch of stuff that Emacs just forgets when you shut down, > where it perhaps shouldn't. > I've brought this up before, but I didn't really have a solution then, > but I think I do now: sqlite3. YUCK!! That would break 45 years of Emacs tradition and practice. In Emacs, data are stored as PLAIN TEXT. Even .elc files are pretty much plain text. That is, text that you can examine with standard tools, such as grep, awk, perl, less, ...., and C-s and friends within Emacs. You seem to be suggesting moving plain text data to an opaque format, which can only be examined with special purpose tools. > sqlite3 is supported on more platforms than Emacs is, the interface is > small and stable, and (best of all) somebody has already created > interface functions for Emacs (via a module): > https://github.com/syohex/emacs-sqlite3 So, in addition to learning ELisp and C, and the tools mentioned above, one will now have to learn sqlite3 in order to make full use of Emacs? Firefox changed some years ago to having its store of visited sites as an opaque format. That's been entirely a loss for me, since I can no longer examine and edit it with any tool other than Firefox itself. Please don't do the same to Emacs. > I think it'd be good to bring that into core, and then write a small > wrapper library (well, a trivial ORM) for the rest of Emacs to use, so > that we don't have to write SQL all over the place. That is: > (setf (persistent-data :namespace "emoji" :key "favorites") emoji--favorites) > I.e., what Emacs needs is a persistent key/value store, and this would > give us that. Emacs has that already. It's called an alist. It becomes persistent when you print it to a file, not a challenging project. > In addition, if somebody really wants to write SQL stuff (it can be very > handy for some things), having sqlite3 in there gives us that in > addition for free. If somebody wants to develop an SQL application, that's fine. But you seem to be talking about turning Emacs _into_ an SQL application. That's anything but fine. > This comes with questions about how the users are supposed be able to > clear out the data, for instance, but we could have a `M-x > list-persistent-data' where the users could blow out whatever they want > to. Such a data store would be an opaque format. Please don't. Just don't. > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no -- Alan Mackenzie (Nuremberg, Germany).