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

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

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> branch: master
> commit d506d91b1fa98b3868437e4d3638f606b4bd20a0
> Author: Stefan Kangas <stefankangas@gmail.com>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
>     Make linum.el obsolete
>     
>     * lisp/obsolete/linum.el: Add Obsolete-since.
>     * etc/NEWS: Announce obsoletion of linum.el.  (Bug#57412)
>     
>     * doc/misc/efaq.texi (Displaying the current line or column):
>     * etc/TODO:
>     * lisp/faces.el: Don't mention linum.el.
> ---
>  doc/misc/efaq.texi     | 3 ---
>  etc/NEWS               | 6 ++++++
>  etc/TODO               | 6 ------
>  lisp/faces.el          | 1 -
>  lisp/obsolete/linum.el | 8 ++++++++
>  5 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/doc/misc/efaq.texi b/doc/misc/efaq.texi
> index ccaca1d017..0da397919d 100644
> --- a/doc/misc/efaq.texi
> +++ b/doc/misc/efaq.texi
> @@ -1810,9 +1810,6 @@ optional display.  Alternatively, you can use the
>  customize @code{display-line-numbers-type} with the same value as you
>  would use with @code{display-line-numbers}.
>  
> -There is also the @samp{linum} package which will henceforth become
> -obsolete.  We recommend using @samp{display-line-numbers} instead.
> -
>  @node Displaying the current file name in the titlebar
>  @section How can I modify the titlebar to contain the current file name?
>  @cindex Titlebar, displaying the current file name in
> diff --git a/etc/NEWS b/etc/NEWS
> index 5e34f43179..97174ba7a2 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -389,6 +389,12 @@ The user options 'url-gateway-rlogin-host',
>  'url-gateway-rlogin-parameters', and 'url-gateway-rlogin-user-name'
>  are also obsolete.
>  
> +---
> +** The linum.el library is now obsolete.
> +We recommend using either the built-in `display-line-numbers-mode', or
> +the `nlinum' package from GNU ELPA instead.  The former has better
> +performance, but the latter is closer to a drop-in replacement.

If I try to load linum now, I just get a message that it is deprecated,
but no hint to use `display-line-numbers-mode'.  Can that be added?

>  ---
>  ** The autoarg.el library is now marked obsolete.
>  This library provides the 'autoarg-mode' and 'autoarg-kp-mode' minor
> diff --git a/etc/TODO b/etc/TODO
> index 5a89c47a9c..3e4979da8a 100644
> --- a/etc/TODO
> +++ b/etc/TODO
> @@ -1686,12 +1686,6 @@ and the one to use when terminating the selection.
>  More specifically do what's needed to make ibuffer.el the default, or
>  just an extension of buff-menu.el.
>  
> -** Replace linum.el with nlinum.el
> -https://lists.gnu.org/r/emacs-devel/2013-08/msg00379.html
> -
> -(Since Emacs 26 introduced native line numbers, this item is
> -probably obsolete.)
> -
>  ** Merge sendmail.el and messages.el
>  Probably not a complete merge, but at least arrange for messages.el to
>  be a derived mode of sendmail.el.  Or arrange for messages.el to be
> diff --git a/lisp/faces.el b/lisp/faces.el
> index e171b32e31..ffdc391f66 100644
> --- a/lisp/faces.el
> +++ b/lisp/faces.el
> @@ -2548,7 +2548,6 @@ default."
>    :version "21.1"
>    :group 'basic-faces)
>  
> -;; Definition stolen from linum.el.
>  (defface line-number
>    '((t :inherit (shadow default)))
>    "Face for displaying line numbers.
> diff --git a/lisp/obsolete/linum.el b/lisp/obsolete/linum.el
> index 1b897a2bd2..017c06e426 100644
> --- a/lisp/obsolete/linum.el
> +++ b/lisp/obsolete/linum.el
> @@ -6,6 +6,7 @@
>  ;; Maintainer: emacs-devel@gnu.org
>  ;; Keywords: convenience
>  ;; Old-Version: 0.9x
> +;; Obsolete-since: 29.1
>  
>  ;; This file is part of GNU Emacs.
>  
> @@ -24,6 +25,13 @@
>  
>  ;;; Commentary:
>  
> +;; NOTE: This library was made obsolete in Emacs 29.1.  We recommend
> +;; using either the built-in `display-line-numbers-mode', or the
> +;; `nlinum' package from GNU ELPA instead.  The former has better
> +;; performance, but the latter is closer to a drop-in replacement.
> +;;
> +;; --------------------
> +;;
>  ;; Display line numbers for the current buffer.
>  ;;
>  ;; Toggle display of line numbers with M-x linum-mode.  To enable

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

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> If I try to load linum now, I just get a message that it is deprecated,

That's weird, shouldn't that be

diff --git a/lisp/subr.el b/lisp/subr.el
index 59f9308f31..7a0896e91e 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -5557,7 +5557,7 @@ do-after-load-evaluation
            (package (intern (substring file 0
 			               (string-match "\\.elc?\\>" file))
                             obarray))
-	   (msg (format "Package %s is deprecated" package))
+           (msg (format "Package %s is obsolete" package))
 	   (fun (lambda (msg) (message "%s" msg))))
       (when (or (not (fboundp 'byte-compile-warning-enabled-p))
                 (byte-compile-warning-enabled-p 'obsolete package))

> but no hint to use `display-line-numbers-mode'.  Can that be added?

I don't think we have any way of displaying such messages.  Maybe it
would be worth adding, though.

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

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> If I try to load linum now, I just get a message that it is deprecated,
>
> That's weird, shouldn't that be
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 59f9308f31..7a0896e91e 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -5557,7 +5557,7 @@ do-after-load-evaluation
>             (package (intern (substring file 0
>  			               (string-match "\\.elc?\\>" file))
>                              obarray))
> -	   (msg (format "Package %s is deprecated" package))
> +           (msg (format "Package %s is obsolete" package))
>  	   (fun (lambda (msg) (message "%s" msg))))
>        (when (or (not (fboundp 'byte-compile-warning-enabled-p))
>                  (byte-compile-warning-enabled-p 'obsolete package))

I'm not sure what you mean.  Are we talking about the usage of
"deprecated" vs. "obsolete"?

>> but no hint to use `display-line-numbers-mode'.  Can that be added?
>
> I don't think we have any way of displaying such messages.  Maybe it
> would be worth adding, though.

Another idea might be to explicitly mark `linum-mode' as obsolete and
recommend using `display-line-numbers-mode' when it is enabled.  Though
the issue here is probably that most people who use linum enable it on
startup and might miss the message.

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

[Stefan Kangas]

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.

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

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

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?

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

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

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

AFAIU, "deprecated" doesn't always imply removal, whereas "obsolete"
does.  So the latter is more clear.

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

If we still have a feeling in 2032 that there are users out there, we
can always just postpone its removal for N more years.  We've done that
before.

RE: [External] : Re: master d506d91b1f 2/2: Make linum.el obsolete

[Drew Adams]

> AFAIU, "deprecated" doesn't always imply removal,

Yes.

> whereas "obsolete" does.

No, it doesn't.

Even desupporting ("unsupported") doesn't
require code removal.  It just means that
you can't expect it to work and you can't
expect any support (help) for it.

Of course, anyone and any organization can
define any such terms the way they want.

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Wed, Sep 21, 2022 at 9:24 AM Philip Kaludercic <philipk@posteo.net>
wrote:

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

Perhaps a variant of the disabled-command machinery for replaced
functionality? Something like:

 (put 'linum-mode 'replaced "This library was made obsolete in Emacs 29.1.
We recommend...")

If this need doesn't deserve a generalized approach, it looks like a
one-off for linum based on #'command-query could work.

Hope this helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1325 bytes --]

Re: [External] : Re: master d506d91b1f 2/2: Make linum.el obsolete

[Stefan Kangas]

> > AFAIU, "deprecated" doesn't always imply removal,
> > whereas "obsolete" does.
>
> No, it doesn't.
>
> Even desupporting ("unsupported") doesn't [...]

We don't use the term "desupporting" in Emacs, AFAIK.

Look, I'm merely trying to describe how we currently seem to be using
these terms in the Emacs project.  I might be wrong, of course, in
which case I trust that our maintainers will make the necessary
corrections.

Naturally, we are all entitled to our personal opinions about how we'd
like to see these terms used in an ideal world.  That's fine and, as
you note, different organizations use them differently.  However, I
don't think discussing that here will necessarily lead to more clarity
about our current and past usage of these terms.  I would therefore
suggest starting a new thread if there is a need for such a discussion
(e.g., if you are not happy with how they are currently used).

That said, the above could have been more clear if I said "eventual"
or "future" removal instead.  That point is taken.

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

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> 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.
>
> AFAIU, "deprecated" doesn't always imply removal, whereas "obsolete"
> does.  So the latter is more clear.

OK, I wasn't familiar with that difference, thank you for the
clarification.

>> 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'.
>
> If we still have a feeling in 2032 that there are users out there, we
> can always just postpone its removal for N more years.  We've done that
> before.

What other examples are there?  I have the impression that line
numbering is a pretty popular feature, that might be lingering around in
many configurations for ages without anyone noticing it.

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

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

>> If we still have a feeling in 2032 that there are users out there, we
>> can always just postpone its removal for N more years.  We've done that
>> before.
>
> What other examples are there?

See for example the comment in `interactive-p', or Bug#50999 on deleting
obsolete libraries in Emacs 29.1.

> I have the impression that line numbering is a pretty popular feature,
> that might be lingering around in many configurations for ages without
> anyone noticing it.

That concern is valid, however I do think our track record shows that we
can and do take such concerns into account when deciding whether or not
we should delete obsolete things.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> AFAIU, "deprecated" doesn't always imply removal, whereas "obsolete"
> does.  So the latter is more clear.

AFAIU we don't use "deprecated" in Emacs at all.

Alternatively, how about this.  Every time an obsolete file is removed,
it gets moved to some other folder (i.e. obsolete-gone) that is not
scanned for autoloads or byte-compiled, or possibly even in a repository
maintained separately from the rest of Emacs.

People who want those files can simply copy them to obsolete/ and hope
they work.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> AFAIU we don't use "deprecated" in Emacs at all.

We don't use it very frequently.  You could grep for it in our tree.

Notably, we seem to use it here:

    Package longlines is deprecated

Does anyone object to changing that to "obsolete"?

> Alternatively, how about this.  Every time an obsolete file is removed,
> it gets moved to some other folder (i.e. obsolete-gone) that is not
> scanned for autoloads or byte-compiled, or possibly even in a repository
> maintained separately from the rest of Emacs.

Maybe the emacsattic would be interested in keeping them around:

    https://github.com/emacsattic

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Alternatively, how about this.  Every time an obsolete file is removed,
>> it gets moved to some other folder (i.e. obsolete-gone) that is not
>> scanned for autoloads or byte-compiled, or possibly even in a repository
>> maintained separately from the rest of Emacs.
>
> Maybe the emacsattic would be interested in keeping them around:
>
>     https://github.com/emacsattic

I'd prefer something closer to Emacs itself, and not on GitHub, which
(its other problems aside) is so slow in my country that it is
essentially nonfunctional without a proxy.

Maybe another repository under the Emacs project itself?  Or better,
lisp/obsolete-gone in the regular Emacs repository, which should allow
the VCS history to be kept.

Thanks.

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

[Stefan Monnier]

>> Maybe the emacsattic would be interested in keeping them around:
>>
>>     https://github.com/emacsattic
>
> I'd prefer something closer to Emacs itself, and not on GitHub, which
> (its other problems aside) is so slow in my country that it is
> essentially nonfunctional without a proxy.
>
> Maybe another repository under the Emacs project itself?  Or better,
> lisp/obsolete-gone in the regular Emacs repository, which should allow
> the VCS history to be kept.

We already have some left-over branches in `elpa.git` for packages which
we don't actually distribute any more (W3, mainly).  We could try and
make that more "formal" and easier to find.


        Stefan

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

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> We already have some left-over branches in `elpa.git` for packages which
> we don't actually distribute any more (W3, mainly).  We could try and
> make that more "formal" and easier to find.

IMO, it would be best to avoid littering GNU ELPA with unmaintained
libraries.  So if we want to do that, they should be separated out from
the main archive somehow.

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

[Stefan Monnier]

Stefan Kangas [2022-09-22 07:01:24] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> We already have some left-over branches in `elpa.git` for packages which
>> we don't actually distribute any more (W3, mainly).  We could try and
>> make that more "formal" and easier to find.
>
> IMO, it would be best to avoid littering GNU ELPA with unmaintained
> libraries.  So if we want to do that, they should be separated out from
> the main archive somehow.

I wasn't suggesting to re-add it to GNU ELPA, but to give those things
a more visible place than some unreferenced branch in `elpa.git`.


        Stefan