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: master 5a125fb5a97 1/2: Update to Org 9.7.3 Date: Tue, 11 Jun 2024 15:23:29 +0300 Message-ID: <8634pj7jni.fsf@gnu.org> References: <171796793548.23337.12512115872160390161@vcs2.savannah.gnu.org> <20240609211858.A2C31C1F9FB@vcs2.savannah.gnu.org> <87a5jtd403.fsf@yahoo.com> <87h6e1lhtd.fsf@kyleam.com> <868qzd9hjg.fsf@gnu.org> <871q53u75e.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6902"; mail-complaints-to="usenet@ciao.gmane.io" Cc: kyle@kyleam.com, emacs-devel@gnu.org To: Ihor Radchenko , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 11 14:24:03 2024 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 1sH0Xh-0001Yr-TQ for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Jun 2024 14:24:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sH0XQ-0001nE-35; Tue, 11 Jun 2024 08:23:44 -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 1sH0XO-0001mu-QE for emacs-devel@gnu.org; Tue, 11 Jun 2024 08:23:42 -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 1sH0XN-0007HW-QT; Tue, 11 Jun 2024 08:23:41 -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=6AeNmYaYDMEgu/aARutsjhNX7TQ1USD/EjUkEL3f3zU=; b=npQHWTB0vwv1 7Rlg0MTRsO04pDPeWl2YUvuWxg85q4xCWIRgAnZlU8bwOxfLDftYX/Ic393qAMKrNYuFGh6VVhj/Q E6I7wOMml2ry7fEy+0bvh8azJbowE5hIS3mQsAPlRSHRPa1+KH0BtNZwZuSwquQo3G/k/XOMjz5ms jsArQrtEuLQiN129B9dSBqd+2gC0Zft7t+X0SB0uGYZfkAOiXFDTM6m4lfbdwUqel+URzQJ7viKu2 htgaksKaySTR2mB/iZ8Hk1Jlqpsr2u0E4q0DZL9rmzH/6+MyS1Bk21lnkDe1WBdfkTG0URXaYyoD6 TLnu29GdEqLAaEN4OCCbpA==; In-Reply-To: <871q53u75e.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Jun 2024 10:05:01 +0000) 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:319969 Archived-At: > From: Ihor Radchenko > Cc: Kyle Meyer , emacs-devel@gnu.org > Date: Tue, 11 Jun 2024 10:05:01 +0000 > > Eli Zaretskii writes: > > > There are other issues with this update: > > > > ELC org/org-macs.elc > > > > In end of data: > > org/org-loaddefs.el:1278:78: Warning: the function `cl-every' is not known to be defined. > > > > Can this warning be eliminated, please? > > It can be eliminated, but the warning does not seem to be Org mode's > fault. > > The line in question in org-loaddefs is > > (custom-autoload 'org-num-skip-tags "org-num" t) > (put 'org-num-skip-tags 'safe-local-variable (lambda (val) (and (listp val) (cl-every #'stringp val)))) > > It is not generated by Org mode, but by loaddefs.el from > > (defcustom org-num-skip-tags nil > "List of tags preventing the numbering of sub-trees. > > For example, add \"ARCHIVE\" to this list to avoid numbering > archived sub-trees. > > Tag in this list prevent numbering the whole sub-tree, > irrespective to `org-use-tag-inheritance', or other means to > control tag inheritance." > :group 'org-appearance > :package-version '(Org . "9.3") > :type '(repeat (string :tag "Tag")) > :safe (lambda (val) (and (listp val) (cl-every #'stringp val)))) > > Note that org-num.el where `org-num-skip-tags' is defined does have > (require 'cl-lib). > > IMHO, there is some problem either with loaddefs generation or with the > fact that loaddefs file is compiled at all. No, the problem is that this variable uses cl-lib stuff for safep functions. IMO, this is not a good idea, and the above situation is precisely the evidence for that. > Of course, we can always convert that lambda into a proper function, > which will likely get rid of the warning. Yes, please. Emacs 28 and later has list-of-strings-p, but if you want to support older versions of Emacs, perhaps that's not usable. Or maybe we could add that to compat.el. Stefan, WDYT about this issue? > > Could not read `org-id-locations' from ~/.emacs.d/.org-id-locations, setting it to nil > > > > Why does it want to read a file from my home directory as part of > > building Emacs? That shouldn't happen. > > Agree. But I am unable to reproduce. > Could you please provide more information? I could, if you tell me what information to provide. I'm not familiar with the code which emits that, and don't even know which code did. > > Executing Emacs-Lisp code block at position 643527... > > Code block evaluation complete. > > Executing Emacs-Lisp code block at position 646480... > > Code block evaluation complete. > > Executing Emacs-Lisp code block at position 648303... > > Code block evaluation complete. > > Executing Emacs-Lisp code block at position 648968... > > Code block evaluation complete. > > Executing Emacs-Lisp code block at position 655333... > > Code block evaluation complete. > > Executing Emacs-Lisp code block at position 659159... > > Code block evaluation complete. > > Executing Emacs-Lisp code block at position 659467... > > Code block evaluation complete. > > Executing Emacs-Lisp code block at position 660552... > > Code block evaluation complete. > > > > Can we please shut up these messages, or at least hide them behind > > some $(AM_V_GEN) trick? > > Why? It is not much different from "scraping loaddefs..." message > sequence. The messages about loaddefs are progress indicators, and show some indication of how much is done and how much is left. By contrast, the above don't show any progress indications, and are completely incomprehensible, except perhaps to those who wrote the relevant code. > Of course, we can hide this, but seeing that some code is evaluated may > be useful in the logs. People who want this in the logs could perhaps turn it on by setting an environment variable or saying "make VAR=value". The value of VAR should be accessible from Lisp via getenv. But I think by default this should be off. Thanks.