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

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@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.

>> But I'm wondering whether `version-to-list' should be more lax here.
>> That is, currently it'll barf of things like:
>> 
>> (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))) 

>> 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.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no