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: Lisp files that load cl-lib in problematical ways Date: Wed, 25 Oct 2023 15:15:42 +0300 Message-ID: <83msw6kidt.fsf@gnu.org> References: <83ttqnm4ti.fsf@gnu.org> <83lebyu5yx.fsf@gnu.org> <83a5scs9pu.fsf@gnu.org> <83bkcrrebj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15799"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 25 14:16:53 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 1qvcoc-0003p1-3M for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Oct 2023 14:16:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvcnt-0001sF-GT; Wed, 25 Oct 2023 08:16:05 -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 1qvcni-0001kx-Q1 for emacs-devel@gnu.org; Wed, 25 Oct 2023 08:15:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvcnh-0000an-T6; Wed, 25 Oct 2023 08:15:53 -0400 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=5FdSZOSB0oQPuFcr3P2c2snYSjQNGVsa6ZHIzyE2Mdo=; b=YZwCW6pgxFv9 c7xT+AMYebR8IsP5j8bAsfW8RU+kiPQDFObPth6Vtx63rqu/Ms+Wh8NTLHUy1+OnMlP90OlhYM60L eqPbhKPuvY5A4vQPT5UevtpNVQLAj5FN9L6hNRxQx9WhIaFFOa+IwKTUApW2FDLhvtD0PiyoV9Van eMfVZT83kbQG7MFcAqYQ3JW/fKikWGuOJQy05JZMdRsP7EP00y6nq8Rh7j3h/ujU4alF+BZ2OPJAm cZog4KdhkUrmhRcM47heilcmSW0jsBq5GuTdw4aiXiR78l4h+/sU/F+NsBLZtz6E9vcc2zZyuygCQ EHfNeL6r4H/GhPjVli3R+g==; In-Reply-To: (message from Richard Stallman on Tue, 24 Oct 2023 22:44:49 -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:311834 Archived-At: > From: Richard Stallman > Cc: eliz@gnu.org, emacs-devel@gnu.org > Date: Tue, 24 Oct 2023 22:44:49 -0400 > > > frameset.el makes moderately heavy use of cl-lib, including at least two > > externally visible cl-defun's where keyword parameters are used. It > > would be a lot of work to replace cl-lib in this file > > cl-defun is a macro; using it ought to work without causing cl-lib to > be loaded. So if frameset.el does load cl-lib, the next question is > what it is in the file that actually does so. It uses several cl-lib functions: cl-every, cl-find-if, cl-delete-if-not, and some others. This code was written before we had seq.el, which is nowadays preloaded. So I guess we could rewrite frameset.el to use seq.el instead (and a few cl-macs macros it uses). If someone wants to work on this, please do. In any case, I see no reason to continue asking this kind of questions on the list. Each such question can be easily answered by using M-. and "C-h f", so anyone who is interested in understanding why a given Lisp package loads cl-lib already has the answers at their fingertips. There's no reason to ask questions on the list that can be easily answered in a few seconds. I also very much doubt that what people will find by using "C-h f" and M-. will be "bugs", since such bugs would have been found long ago. It bothers the heck out of me to hear assessments like that which clearly hint that the quality of our code is deemed to be so low; it is not. And again, let's not keep this discussion, as it just wastes bandwidth and energy on something that can be found within seconds by anyone who wants to know.