Re: master d506d91b1f 2/2: Make linum.el obsolete

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I'm not sure what you mean.  Are we talking about the usage of
>> "deprecated" vs. "obsolete"?
>
> Yes, the directory is called "lisp/obsolete" after all.

I don't know if there are strict definitions, but to me these two are de
facto synonyms.

>> Another idea might be to explicitly mark `linum-mode' as obsolete and
>> recommend using `display-line-numbers-mode' when it is enabled.
>
> Yes, indeed.  I've now made that change on master.

1+

>> Though the issue here is probably that most people who use linum
>> enable it on startup and might miss the message.
>
> True.  Maybe we could think about ways to make the message more visible.
>
> We do have this comment in `do-after-load-evaluation':
>
>     ;; Maybe we should just use display-warning?  This seems yucky...

It is a tricky question.  The question is will (most) people notice the
deprecation message before linum is removed from emacs.git/the release
that does so is distributed.  I am guessing this could take a few years
to happen, then maybe 2-3 years until the release until whatever version
of Emacs that ends up being is even distributed by stable distribution
channels.

That might be long enough to notice a warning and fix it, or they will
start up Emacs one day after an update an encounter a void function
error.

Perhaps, when it comes to this, it might be enough to add a legacy alias
and make `linum-mode' invoke `display-line-numbers-mode', doing the same
for `global-linum-mode' and `global-display-line-numbers-mode'.

A more general idea might be to have some kind of init.el-health-checker
command that could detect and propose to fix simple issues like these.
But then again, will those who never pay attention notice this?