From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Thu, 16 Dec 2021 10:10:26 +0200 Message-ID: <831r2dhswd.fsf@gnu.org> References: <87tufmjyai.fsf@gnus.org> <874k7ljwkr.fsf@gnus.org> <87fsr5cuzq.fsf@ericabrahamsen.net> <878rwx8mdn.fsf@gnu.org> <87r1aphuei.fsf@gnus.org> <837dcex6ub.fsf@gnu.org> <83a6h9tu1c.fsf@gnu.org> <87sfuzwzk0.fsf@gnus.org> <87fsqyh17u.fsf@gnus.org> <87sfuxrvm0.fsf@gnus.org> <87tufbr6lc.fsf@gnus.org> <87sfuumjjw.fsf@gnus.org> <87pmpxhz4y.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17853"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eric@ericabrahamsen.net, cesar.mena@gmail.com, rms@gnu.org, pipcet@gmail.com, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 16 09:14:07 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 1mxltv-0004Pa-Ea for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Dec 2021 09:14:07 +0100 Original-Received: from localhost ([::1]:39892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxltu-00059v-D5 for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Dec 2021 03:14:06 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55234) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxlrJ-0003Io-8f for emacs-devel@gnu.org; Thu, 16 Dec 2021 03:11:25 -0500 Original-Received: from [2001:470:142:3::e] (port=53564 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxlrI-0000hg-K9; Thu, 16 Dec 2021 03:11:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bOOdDGX/msxWdeW73ES6ywI9mBL8S57TU++DS9H2qhE=; b=V4ekp7vuc+gd blTd4RS9dUjfelsldp8SLPk7O9C+B72mOOtp0te+tILclZAk01L+AHDDm8NLsqj+Gwfj1O79Bwdy4 N1tqgFWJJUXJIxzNwdB5X8i8/dhKENWzgw8+2dCrU5JrQWJuT6QbohiPCwhoD+FbeSAKGEyL4b6cX oeia2lsde66mjD/OZ1eVSBZJDjevpbg1orgU6krTLDrL7rc2ChIyO8IIvieT5VBV8zfFRVm4/hrYU L65ePpE7PwHSWv0isLzqkfKSCq5nbjaACI2Zo7AT3tsu8Lc0nkXkXxtxziuE/lVSLfH2yPM3asgws vjyC0tX549puWLPN1iwEzg==; Original-Received: from [87.69.77.57] (port=3355 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxlqh-0006rQ-1v; Thu, 16 Dec 2021 03:10:49 -0500 In-Reply-To: <87pmpxhz4y.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 16 Dec 2021 06:55:41 +0100) 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:282132 Archived-At: > From: Lars Ingebrigtsen > Cc: eric@ericabrahamsen.net, eliz@gnu.org, cesar.mena@gmail.com, > pipcet@gmail.com, emacs-devel@gnu.org > Date: Thu, 16 Dec 2021 06:55:41 +0100 > > Richard Stallman writes: > > > The reason I expected this to be used for configuration specifications > > is that that seems like a natural thing to do. Assuming we get this > > facility into a good shape, why NOT use it for storing configuration > > specs? > > I think defcustom is fine for configuration data. Configuration data > doesn't change a lot, and people like to put it into Git, etc. I think basically wherever saving configuration in text form makes sense, i.e. it is short enough and readable enough by humans, it should be preferred, because that allows viewing it, modifying it, and generally managing it by more general-purpose tools. > Application session state is a different beast, and is something that > Emacs has lacked a convenient interface for, so each package has come up > with its own way to store state, or more commonly -- not bothered, > because it's so much (boring) work. Application state is indeed a different issue, that should be decided separately on a case by case basis. For example, should .emacs.desktop remain in its current text form? I personally think it should, because it's still readable enough and performant enough, but there could be other opinions. Large databases are yet another different beast. For example, consider the mairix-related features in Emacs: we current use an external program for that, where using a database internally from Emacs could make at least some sense: for starters, we wouldn't be limited by search capabilities of mairix the program, but could instead unleash the full power of Emacs searching capabilities.