Re: master 5a125fb5a97 1/2: Update to Org 9.7.3

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Kyle Meyer <kyle@kyleam.com>, emacs-devel@gnu.org
> Date: Tue, 11 Jun 2024 10:05:01 +0000
> 
> Eli Zaretskii <eliz@gnu.org> 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.