GNU bug report logs - #48404
28.0.50; "Invalid version syntax" errors with read-extended-command

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 48404 <at> debbugs.gnu.org, stefan <at> marxist.se, tsdh <at> gnu.org
Subject: bug#48404: 28.0.50; "Invalid version syntax" errors with read-extended-command
Date: Sun, 16 May 2021 17:48:16 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: tsdh <at> gnu.org,  48404 <at> debbugs.gnu.org,  stefan <at> marxist.se
> Date: Sun, 16 May 2021 16:38:58 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > For obsolete commands from 3rd-party packages, which state something
> > like "Magit 3.0" in the version since which they are obsolete, the
> > obsolescence will never happen, in the sense that they will _always_
> > appear in "M-x TAB", even 100 years from now.  Is that what we want?
> 
> That is what was the case before applying the patch, so it's no change
> for those commands.

No change for the worse, sure.  That's what I meant when I said they
will not be able to take advantage of this feature.  They will be
excluded.

> >> (version-to-list "28.1 Magit/2.5")
> >
> > I'm not sure it's possible without introducing ambiguity into the
> > version string and complicating comparison of versions.  We already
> > support some non-numeric versions, and that's not easy.
> 
> Sorry, I was imprecise here -- I didn't mean that we should change
> `version-to-list' itself here, but add a new function that's more
> permissive, just for use in this context.  It would basically be
> something along the lines of (version-to-list (car (split-string string))) 

The main purpose is to compare versions.  How would you do that with
loose version strings such as the one above?

> >> It might make sense to allow the obsoletion versions to refer to both an
> >> (approximate) Emacs version, as well as a package version.
> >
> > How can this be done, even in principle?  Versions of unbundled
> > packages are unrelated to Emacs versions; typically, a given version
> > of an unbundled package supports quite a few Emacs versions.  So what
> > Emacs version will you put there?
> 
> That would be up to the package maintainers -- they get to choose what
> Emacs version(s) the obsolete command would show up in `M-x TAB'
> completions.  

I don't think they will be able to solve this problem, not in
satisfactory ways anyway.

Previous Next

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