Subject: bug#48404: 28.0.50; "Invalid version syntax" errors with read-extended-command

From: Eli Zaretskii <[email-masked]>
Date: Sun, 16 May 2021 17:48:16 +0300

> From: Lars Ingebrigtsen <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Sun, 16 May 2021 16:38:58 +0200
> 
> Eli Zaretskii <[email-masked]> 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.