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: persistent data feature Date: Mon, 13 Dec 2021 14:42:18 +0200 Message-ID: <83o85kn0b9.fsf@gnu.org> References: <87tufmjyai.fsf@gnus.org> <87bl1olyhr.fsf@localhost> <87bl1ngnj1.fsf@logand.com> <3437406.lxAJRBJNBK@galex-713.eu> <875yrvgchu.fsf@logand.com> <83sfuyq4oo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33437"; mail-complaints-to="usenet@ciao.gmane.io" Cc: galex-713@galex-713.eu, tom@logand.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 13 13:45: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 1mwkhV-0008SN-Uo for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Dec 2021 13:45:06 +0100 Original-Received: from localhost ([::1]:53042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwkhU-0007mv-BV for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Dec 2021 07:45:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37620) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwkez-00067c-T2 for emacs-devel@gnu.org; Mon, 13 Dec 2021 07:42:30 -0500 Original-Received: from [2001:470:142:3::e] (port=57314 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 1mwkey-0005ZF-AZ; Mon, 13 Dec 2021 07:42:28 -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=Z1q+XqBH3eXppk0pFymF60V/CzNqNODSTe9ySqqAp+E=; b=absZO55GEZCp FhT5YorKPLKpQDQ6vFzO4sX82MhGAiRMFxaXRTDiPRa6FUOtURUngD2mHub7CtN+/f/l9A1jv+XtO mywQFgabgs1rxOYnqVOKtZt7WxwVzlYgp19TVsF5AkECmAEaEQVAkrBuNkKhW1FCwUnDEWYBs+oCP bybCvQQhNKOksPSS9okScN+uY5kTXHmVTdHx510j49uwXnmu//i0zQDv+7xH3AKlrcIE0IkWETFF7 q5CYf/IlaGG9kJSEB5xtYCUS0jFDW/eGrjNXE0PjVzD5QUE1VvIRakf1NUSpOe2pT32aelfgtLFWC FWlOI11w6ftPxcG2hdh0wA==; Original-Received: from [87.69.77.57] (port=1630 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 1mwkeu-0004K0-3C; Mon, 13 Dec 2021 07:42:24 -0500 In-Reply-To: (message from Richard Stallman on Sun, 12 Dec 2021 22:42:41 -0500) 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:281840 Archived-At: > From: Richard Stallman > Cc: tom@logand.com, galex-713@galex-713.eu, emacs-devel@gnu.org > Date: Sun, 12 Dec 2021 22:42:41 -0500 > > > > Also I find the trend of linking everything into the emacs process > > > concerning: > > > What's the alternative? to reinvent all the wheels in Emacs's own > > code? to use external programs? something else? Rejecting a trend for > > which there are no better alternatives is not smart. > > For any given facility, I see these alternatives to consider: > (1) Link it in statically. > (2) Use an external program in a subprocess. > (3) Use a dynamically linked module. > (4) Write it in Lisp. > (5) Decline to support it. I think (1) and (3) are the same, for the purpose of this sub-thread, since the issue raised was how many external libraries we depend on. (2) is only viable if the amount of stuff flowing back and forth between Emacs and the program is relatively small, otherwise it's just bad design and worse performance. (4) is not relevant because that's normally the first solution we try, and if we decided that Lisp cannot handle it well enough, or not at all (like with drawing images on the Emacs display), we are way past that when we get to the decision point. Declining to support a useful capability when there's a reasonable way of supporting it is silly. So we are left with (1) and (3), which are usually indistinguishable (except in weird cases like libgcc). > If we conclude that we are using (1) too readily, > that wouldn't imply we should reject it entirely henceforth, > but would lead us to be more ready to choose the others. Once again, (1) and (3) are the same. I think nowadays people prefer shared libraries for reasons of system maintenance, and its infeasible to try to force users or distros to use only static linking (nor do I see any reasons for that, either technical or political, as long as we are talking about Free Software anyway).