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: Lisp files that load cl-lib in problematical ways Date: Thu, 19 Oct 2023 12:34:42 +0000 Message-ID: References: <87il8betof.fsf@dataswamp.org> <83fs3dgxv8.fsf@gnu.org> <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.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="4859"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 19 14:35:48 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 1qtSFg-000114-LF for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Oct 2023 14:35:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtSEq-0005co-Md; Thu, 19 Oct 2023 08:34:56 -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 1qtSEl-0005ae-79 for emacs-devel@gnu.org; Thu, 19 Oct 2023 08:34:52 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtSEh-0000eF-M5 for emacs-devel@gnu.org; Thu, 19 Oct 2023 08:34:50 -0400 Original-Received: (qmail 58444 invoked by uid 3782); 19 Oct 2023 14:34:43 +0200 Original-Received: from acm.muc.de (pd953a45c.dip0.t-ipconnect.de [217.83.164.92]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 19 Oct 2023 14:34:42 +0200 Original-Received: (qmail 3828 invoked by uid 1000); 19 Oct 2023 12:34:42 -0000 Content-Disposition: inline In-Reply-To: <83ttqnm4ti.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; 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_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311591 Archived-At: Hello, Eli. On Thu, Oct 19, 2023 at 10:47:37 +0300, Eli Zaretskii wrote: > > Date: Thu, 19 Oct 2023 05:27:03 +0000 > > Cc: Emanuel Berg , emacs-devel@gnu.org > > From: Alan Mackenzie > > With the following command, started from the lisp directory: > > $ sed 's/^[^;]*(load "\(.*\)".*$/\1.el/; s/\.el\.el/.el/; t; d' loadup.el | \ > > sort | xargs grep -c "^[^;]*(cl-" | sed '/:0/d' > > , I get the following files, with counts of '(cl-' usages: > > abbrev.el:2 [ .... ] > > vc/vc-hooks.el:1 > > .. That's a total of 541 occurrences, just in the files that get dumped > > with the Emacs binary. > Those use cl-lib during byte-compilation, they don't load cl-lib at > run time. They do, I think (see below). > So this is not what Richard asked about, AFAIU. Yes, you're right. So, I counted all the occurrences of "cl-" not inside an eval-when-compile, by piping all the dumped .el files through the following script: find-run-time-cl.el: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun run-time-cl () (save-excursion (goto-char (point-min)) (let ((count 0)) (while (and (< (point) (point-max)) (re-search-forward "^[^;]*(\\(eval-when-compile\\|cl-\\)" nil 'stop)) (if (string= (match-string-no-properties 1) "cl-") (progn (setq count (1+ count))) ;; (message "%s:%s %s" (buffer-file-name) (line-number-at-pos) ;; (buffer-substring-no-properties (line-beginning-position) ;; (line-end-position))) (goto-char (1- (match-beginning 1))) (forward-list))) (prin1 (format "%s:%s\n" (buffer-file-name) count) t)))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; $ for f in `sed 's/^[^;]*(load "\(.*\)".*$/\1.el/; s/\.el\.el/.el/; t; d' \ loadup.el | sort`; \ do ../src/emacs -Q -batch -l ~/find-run-time-cl.el \ --eval "(progn (find-file \"$f\") (run-time-cl))"; \ done | sed '/:0$/d' | sed 's%^.*/lisp/%%' and got the following results: abbrev.el:2 dnd.el:4 emacs-lisp/byte-run.el:1 emacs-lisp/cconv.el:13 emacs-lisp/cl-generic.el:56 emacs-lisp/cl-preloaded.el:16 emacs-lisp/eldoc.el:6 emacs-lisp/lisp-mode.el:6 emacs-lisp/nadvice.el:2 emacs-lisp/oclosure.el:8 emacs-lisp/seq.el:25 emacs-lisp/shorthands.el:1 emacs-lisp/syntax.el:5 emacs-lisp/tabulated-list.el:1 emacs-lisp/timer.el:1 font-lock.el:1 frame.el:5 international/mule-cmds.el:3 international/ucs-normalize.el:1 isearch.el:3 ldefs-boot.el:3 loaddefs.el:3 minibuffer.el:12 progmodes/elisp-mode.el:11 progmodes/prog-mode.el:1 register.el:3 replace.el:1 select.el:3 simple.el:9 startup.el:1 subr.el:1 tab-bar.el:4 term/android-win.el:4 term/haiku-win.el:3 term/ns-win.el:2 term/pc-win.el:6 term/pgtk-win.el:3 term/w32-win.el:4 term/x-win.el:2 uniquify.el:2 vc/vc-hooks.el:1 That may not be 541 occurrences, but it's still 239. Incidentally, when I start emacs -Q, cl-lib isn't yet loaded for me, either. > > I fear that that's the way things will stay, because it would be too > > much work to fix. But more because there are enough contributors who > > think that cl-lib is just an ordinary part of Emacs to be used freely > > without restraint. I am not among this group of contributors. > We cannot possibly expect people to contribute code if we force them > not to use the macros they are used to. If cl-lib is not loaded as > result, that is good enough for us, I think. We "force" them to use Emacs Lisp, but they still contribute. The problem is that use of cl- makes maintenance of other people's code much harder, at least for me. I'm sure I'm not alone. cl- probably multiplies the size of the Lisp language parts of Elisp (i.e. things like defun, defmacro, if, while, cond, ...) by around three. I'm not able to learn all these fancy macros which are used rarely enough not to be learnable, but frequently enough to cause maintenance headaches - every time I encounter `if-let' and the like, it just stops me in my tracks. I either have to guess what it means, which makes me uncomfortable, or laboriously consult a doc string, if any. Yes, I know if-let isn't a cl- function, and its doc string is of reasonable quality. Many cl- functions don't have doc strings, or have inadequate ones, however. There was a time in the medium past when the use of run time cl- was not allowed. Emacs was then, from my point of view, much easier to maintain. At some stage this rule was done away with, but I don't recall there being any discussion on emacs-devel about this change. There should have been such discussion. But we are where we are, as you said. -- Alan Mackenzie (Nuremberg, Germany).