GNU bug report logs - #78844
30.1; feature request: public interface for querying builtin packages and versions

Previous Next

Full log

Message #82 received at 78844-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Xiyue Deng <manphiz <at> gmail.com>
Cc: 78844-done <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 spwhitton <at> spwhitton.name
Subject: Re: bug#78844: 30.1; feature request: public interface for querying
 builtin packages and versions
Date: Sat, 12 Jul 2025 10:15:11 +0300

> From: Xiyue Deng <manphiz <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, spwhitton <at> spwhitton.name,
>  78844 <at> debbugs.gnu.org
> Date: Sat, 28 Jun 2025 17:36:03 -0700
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> >>> FWIW, I'd consider it an error if an entry in
> >>> `package--builtin-versions` has a nil "version".
> >>> There are no such things as "unversioned packages" in this respect.
> >>> So, I think the code is OK but the docstring should not mention that
> >>> we return nil for packages without a version.
> >>
> >> I think in principle you are correct given that the current public
> >> functions don't provide a way to obtain such a symbol.  But it's
> >> possible that someone can construct a symbol, either by hand or through
> >> a new interface that queries all builtin packages, which is in
> >> `package--builtins' but not in `package--builtin-versions', and the
> >> function will return nil.  Do you think it's worth keeping such
> >> possibility into consideration?
> >
> > Returning nil for packages (aka symbols) which aren't in
> > `package--builtin-versions` is fine and I have no objection to
> > documenting it.
> >
> > My objection is to
> >
> >     if @var{package} does not have a version
> >
> > but not to
> >
> >     if @var{package} ... is not a buil-tin package
> >
> 
> I see.  Though technically people can get a package symbol from
> `package--builtins', and hence built-in, but not in
> `package--builtin-versions', and hence does not have a version
> associated.  Maybe I can be more explicit to say "if @var{package} is
> built-in but does not have a version ..."?  (Revised as such.)
> 
> > [ BTW, note the typo above.  ]
> 
> Thanks for spotting.  Also fixed.

Now installed on the master branch, and closing the bug.

Please note that there were missing pieces in the documentation part
(missing menu items), which caused makeinfo to emit error messages.
Please in the future always be sure to build Emacs with your patches,
including the documentation, and please examine the output for any
warnings/errors that need to be fixed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.