From: Bill Wohler <wohler@newt.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: bzg@altern.org, stefan@marxist.se, 13824@debbugs.gnu.org
Subject: bug#13824: 24.3.50; :package-version not taking priority over :version
Date: Sun, 11 Aug 2019 11:06:04 -0700 [thread overview]
Message-ID: <34219.1565546764@olgas.newt.com> (raw)
In-Reply-To: <83r25ru7fs.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> wrote:
> > cc: Stefan Kangas <stefan@marxist.se>, bzg@altern.org,
> > 13824@debbugs.gnu.org
> > From: Bill Wohler <wohler@newt.com>
> > Date: Sat, 10 Aug 2019 15:10:13 -0700
> >
> > > Bill, what is your take on this? Your change, which introduced this
> > > attribute, only modified customize-changed-options. Was that on
> > > purpose?
> >
> > Thanks for asking. The original intent of package-version was to provide
> > more accurate version information in packages that were updated more
> > often than Emacs, regardless of whether they were packaged in Emacs
> > (like MH-E and Gnus) or not. I think that should apply to any function
> > that displays version information for an option. That is, any function
> > that looks for :version should also look for :package-version.
>
> Thanks.
>
> Upon taking a better look, I conclude that there's more here than
> originally met the eye.
>
> First, the doc string of defcustom says:
>
> :package-version
> VALUE should be a list with the form (PACKAGE . VERSION)
> specifying that the variable was first introduced, or its
> default value was changed, in PACKAGE version VERSION. This
> keyword takes priority over :version. For packages which
> are bundled with Emacs releases, the PACKAGE and VERSION
> must appear in the alist `customize-package-emacs-version-alist'.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> So Stefan's reproducer, viz.:
>
> (progn
> (defcustom foobar nil
> "foo"
> :version "27.1"
> :package-version '(foo . "1"))
> (describe-variable-custom-version-info 'foobar))
>
> wasn't supposed to work, since it doesn't play by the rules.
>
> Next, MH-E uses :package-version, but doesn't use :version. So, for
> example, "C-h v mh-whitelist-preserves-sequences-flag RET" produces
> the expected
>
> This variable was introduced, or its default value was changed, in
> version 8.4 of the MH-E package that is part of Emacs 24.4.
>
> By contrast, Org mode files use both :package-version and :version,
> which I guess was the reason why Bastien filed this bug report in the
> first place.
>
> Now, since we _require_ the package versions to appear in
> customize-package-emacs-version-alist, specifying :package-version
> alone provides all the info we need about both the package version and
> the corresponding Emacs version. Therefore, specifying :version as
> well is simply redundant when :package-version is given, and Org
> shouldn't use :version (btw, Org is the only bundled package which
> uses both these attributes). IOW, if a package uses both attributes,
> it's a mistake, we should document that to be a mistake (i.e. not just
> say :package-version "overrides"), and it should probably be flagged
> as a mistake by checkdoc. And yes, functions that need the version
> information should ignore :version if :package-version is available.
> Which means describe-variable-custom-version-info should indeed be
> fixed.
Thanks for digging in. That makes sense. A function that gets the
version info from :package-version or :version as appropriate could be
written (if it hasn't already). If used consistently throughout, it
would provide a good example for obtaining version information.
>
> Thanks.
>
--
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD
prev parent reply other threads:[~2019-08-11 18:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-26 17:28 bug#13824: 24.3.50; :package-version not taking priority over :version Bastien Guerry
2019-08-08 3:59 ` Stefan Kangas
2019-08-10 9:22 ` Eli Zaretskii
2019-08-10 14:13 ` Stefan Kangas
2019-08-10 22:10 ` Bill Wohler
2019-08-10 22:40 ` Bill Wohler
2019-08-11 14:01 ` Eli Zaretskii
2019-08-11 18:06 ` Bill Wohler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34219.1565546764@olgas.newt.com \
--to=wohler@newt.com \
--cc=13824@debbugs.gnu.org \
--cc=bzg@altern.org \
--cc=eliz@gnu.org \
--cc=stefan@marxist.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.