From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Lisp files that load cl-lib in problematical ways Date: Tue, 24 Oct 2023 14:43:48 +0200 Message-ID: <87msw8kx6j.fsf@dataswamp.org> References: <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.org> <83lebyu5yx.fsf@gnu.org> <4684f43123d7dee59461@heytings.org> <835y2xo1a5.fsf@gnu.org> <4684f4312391906f6101@heytings.org> <831qdlo084.fsf@gnu.org> <83edhkmfax.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34392"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:30gFz3b6GSDqhZlFyiyt98J+7bc= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 24 14:49:47 2023 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 1qvGqv-0008fw-SC for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Oct 2023 14:49:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvGqd-0005Xt-Cu; Tue, 24 Oct 2023 08:49:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvGlV-0001eQ-4Q for emacs-devel@gnu.org; Tue, 24 Oct 2023 08:44:10 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvGlQ-0001a6-DD for emacs-devel@gnu.org; Tue, 24 Oct 2023 08:44:07 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qvGlJ-0000yb-Ke for emacs-devel@gnu.org; Tue, 24 Oct 2023 14:43:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 24 Oct 2023 08:49:22 -0400 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311787 Archived-At: Eli Zaretskii wrote: >> About how much memory are we talking here? All this sounds >> like talk about micro optimizations. > > If we ignore such "micro optimizations", we will quickly > bloat Emacs, since those small amounts add up. We have a lot > of relatively small potential additions that we make a point > of not adding, because if we decide adding one is okay, then > why not add all the rest? We don't add such stuff to subr.el > or to simple.el or to files.el, and keep them separate, > precisely because adding them all will not be insignificant. > > The only way of keeping this kind of bloat at bay is to > resist adding anything, no matter how small, because, like > I said, it's a slippery slope. While I agree one shouldn't ignore micro optimizations in general, you keep refering to useful Elisp as bloat. That is disrespectful and also not true, it is useful code, and where it is or isn't added or loaded doesn't change it into something it isn't. Also, instead of the general "slippery slope" model of thought and offered explanation, it is better to either have a clear policy "we add stuff that [...]". Then one can say "we don't intend to include some-package.el because it doesn't fall under our policy what stuff to add, because it is [...] and the policy is [...]". If one cannot formulate a general policy it will instead have to be dealt with on a case-by-case basis. But then one would like to hear the arguments for each such case suggested, and in terms of what that package brings (or lacks) and where it is suggested to be added, not that you want to keep "this kind of bloat at bay". -- underground experts united https://dataswamp.org/~incal