GNU bug report logs - #57412
Could we make linum.el obsolete?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57412 in the body.
You can then email your comments to 57412 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Could we make linum.el obsolete?
Date: Thu, 25 Aug 2022 18:08:06 +0000

Severity: wishlist

Is there any reason to keep linum.el around any longer, or could it be
marked obsolete in favor of `display-line-numbers-mode'?

Given our obsoletion policy, it would still be around for another
decade, which should give users plenty of time to adapt.

Message #8 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 57412 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Thu, 25 Aug 2022 21:29:36 +0300

> Cc: monnier <at> iro.umontreal.ca
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 25 Aug 2022 18:08:06 +0000
> 
> Severity: wishlist
> 
> Is there any reason to keep linum.el around any longer, or could it be
> marked obsolete in favor of `display-line-numbers-mode'?

The only possible reason is that linum.el allows more freedom in
formatting the line numbers and their faces.  I don't know whether
this reason is serious enough to not obsolete linum.el.

Message #11 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Colin Baxter <m43cap <at> yandex.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 57412 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 09:20:32 +0100

>>>>> Stefan Kangas <stefankangas <at> gmail.com> writes:

    > Severity: wishlist Is there any reason to keep linum.el around any
    > longer, or could it be marked obsolete in favor of
    > `display-line-numbers-mode'?

    > Given our obsoletion policy, it would still be around for another
    > decade, which should give users plenty of time to adapt.


Please do not obsolete this. I do not like display-line-numbers-mode,
preferring line numbers in the margin. There must be other users
similarly inclined.

I do not understand this need to obsolete packages that perform
perfectly well. Emacs often has multiple ways of achieving the same
outcome, which is surely a positive.

Best wishes,

Message #14 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: m43cap <at> yandex.com, Stefan Kangas <stefankangas <at> gmail.com>
Cc: 57412 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 13:49:55 +0300

On 26.08.2022 11:20, Colin Baxter wrote:
>>>>>> Stefan Kangas<stefankangas <at> gmail.com>  writes:
>      > Severity: wishlist Is there any reason to keep linum.el around any
>      > longer, or could it be marked obsolete in favor of
>      > `display-line-numbers-mode'?
> 
>      > Given our obsoletion policy, it would still be around for another
>      > decade, which should give users plenty of time to adapt.
> 
> 
> Please do not obsolete this. I do not like display-line-numbers-mode,
> preferring line numbers in the margin. There must be other users
> similarly inclined.

Have you tried nlinum-mode from GNU ELPA? I hear it has better 
performance and apparently fewer bugs.

> I do not understand this need to obsolete packages that perform
> perfectly well. Emacs often has multiple ways of achieving the same
> outcome, which is surely a positive.

It's good to reduce the volume of code we have to support over time.

It would also help people land on a faster and better supported alternative.

Message #17 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57412 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 13:11:15 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> The only possible reason is that linum.el allows more freedom in
> formatting the line numbers and their faces.  I don't know whether
> this reason is serious enough to not obsolete linum.el.

I think nlinum is supposed to support everything that linum does (and is
faster and less buggy) -- but I haven't looked in detail.

If that's the case, then I think it would make sense to obsolete
linum.el.

Message #20 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 57412 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 14:19:59 +0300

On 26.08.2022 14:11, Lars Ingebrigtsen wrote:
> Eli Zaretskii<eliz <at> gnu.org>  writes:
> 
>> The only possible reason is that linum.el allows more freedom in
>> formatting the line numbers and their faces.  I don't know whether
>> this reason is serious enough to not obsolete linum.el.
> I think nlinum is supposed to support everything that linum does (and is
> faster and less buggy) -- but I haven't looked in detail.

Here's one such case when I ended just just recommending to avoid linum:

https://github.com/company-mode/company-mode/issues/1336

Message #23 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "m43cap <at> yandex.com" <m43cap <at> yandex.com>, Stefan Kangas
 <stefankangas <at> gmail.com>
Cc: "57412 <at> debbugs.gnu.org" <57412 <at> debbugs.gnu.org>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 16:18:28 +0000

> I do not understand this need to obsolete packages that perform
> perfectly well. Emacs often has multiple ways of achieving the same
> outcome, which is surely a positive.

Marie-Condo Complex?

https://en.wikipedia.org/wiki/Marie_Kondo

Nothing wrong with some wanting to declutter
their _own_ lives and living rooms.  Emacs is
everyone's living room.  The Emacs way would
be to provide decluttering user options, to
let users decide for themselves. ;-)

Message #26 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Colin Baxter <m43cap <at> yandex.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefankangas <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca, 57412 <at> debbugs.gnu.org
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 17:55:24 +0100

>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:

    > On 26.08.2022 14:11, Lars Ingebrigtsen wrote:
    >> Eli Zaretskii<eliz <at> gnu.org> writes:
    >> 
    >>> The only possible reason is that linum.el allows more freedom in
    >>> formatting the line numbers and their faces.  I don't know
    >>> whether this reason is serious enough to not obsolete linum.el.
    >> I think nlinum is supposed to support everything that linum does
    >> (and is faster and less buggy) -- but I haven't looked in detail.

    > Here's one such case when I ended just just recommending to avoid
    > linum:

    > https://github.com/company-mode/company-mode/issues/1336


I've never experienced any problems with linum.el but then my setup is
super-simple and does not include company-mode.

Best wishes,

Message #29 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Colin Baxter <m43cap <at> yandex.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 57412 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 20:00:40 +0100

>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:

    > On 26.08.2022 11:20, Colin Baxter wrote:
    >>>>>>> Stefan Kangas<stefankangas <at> gmail.com> writes:
    >> > Severity: wishlist Is there any reason to keep linum.el around
    >> any > longer, or could it be marked obsolete in favor of >
    >> `display-line-numbers-mode'?  > Given our obsoletion policy, it
    >> would still be around for another > decade, which should give
    >> users plenty of time to adapt.  Please do not obsolete this. I do
    >> not like display-line-numbers-mode, preferring line numbers in
    >> the margin. There must be other users similarly inclined.

    > Have you tried nlinum-mode from GNU ELPA? I hear it has better
    > performance and apparently fewer bugs.

    >> I do not understand this need to obsolete packages that perform
    >> perfectly well. Emacs often has multiple ways of achieving the
    >> same outcome, which is surely a positive.

    > It's good to reduce the volume of code we have to support over
    > time.

    > It would also help people land on a faster and better supported
    > alternative.

Yes, I understand that and agree. From my perspective, I am disappointed
that candidates for obsolescence seem to be chosen from libraries that
are useful and not from morse, zone and the like.

Best wishes,

Message #32 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Colin Baxter <m43cap <at> yandex.com>
Cc: 57412 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 15:14:40 -0400

Colin Baxter [2022-08-26 20:00:40] wrote:
> Yes, I understand that and agree. From my perspective, I am disappointed
> that candidates for obsolescence seem to be chosen from libraries that
> are useful and not from morse, zone and the like.

Those that are useful but suffer from corner-case problems due to the
underlying design are bound to fall into this trap: if they weren't
very useful, noone would bother to reimplement them to fix those
corner cases but since the problems stem from the underlying approach,
the fix requires a significant rewrite which inevitably leads to
a slightly different featureset.

The purpose of obsoleting a library like `nlinum.el` is to help/encourage
people to move to the better options out there (and sometimes also to
discover important use-cases not yet covered by the new code).

The maintenance cost of `nlinum.el` isn't very high, but there's a cost
for users of having to choose between various options, none of which is
a strict superset of the other.


        Stefan

Message #35 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Colin Baxter <m43cap <at> yandex.com>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 57412 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 21:17:47 +0100

>>>>> Bug reports for GNU Emacs, the Swiss army knife of text editors <Stefan> writes:

    > Colin Baxter [2022-08-26 20:00:40] wrote:
    >> Yes, I understand that and agree. From my perspective, I am
    >> disappointed that candidates for obsolescence seem to be chosen
    >> from libraries that are useful and not from morse, zone and the
    >> like.

    > Those that are useful but suffer from corner-case problems due to
    > the underlying design are bound to fall into this trap: if they
    > weren't very useful, noone would bother to reimplement them to fix
    > those corner cases but since the problems stem from the underlying
    > approach, the fix requires a significant rewrite which inevitably
    > leads to a slightly different featureset.

    > The purpose of obsoleting a library like `nlinum.el` is to
    > help/encourage people to move to the better options out there (and
    > sometimes also to discover important use-cases not yet covered by
    > the new code).

    > The maintenance cost of `nlinum.el` isn't very high, but there's a
    > cost for users of having to choose between various options, none
    > of which is a strict superset of the other.

I am not convinced. However thank you nevertheless for taking the time
and effort to explain.

Best wishes,

Message #41 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Colin Baxter <m43cap <at> yandex.com>
Cc: 57412 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Fri, 26 Aug 2022 17:11:20 -0400

Colin Baxter [2022-08-26 21:17:47] wrote:
> I am not convinced. However thank you nevertheless for taking the time
> and effort to explain.

BTW, obsoleting `linum.el` doesn't mean removing it from Emacs for
several more years.  And even if/when we do decide to remove it, we can
move it to GNU ELPA instead if there's still interest.


        Stefan

Message #46 received at 57412 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: 57412 <at> debbugs.gnu.org
Cc: monnier <at> iro.umontreal.ca
Subject: Re: bug#57412: Could we make linum.el obsolete?
Date: Tue, 20 Sep 2022 15:10:48 -0400

close 57412 29.1
thanks

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Is there any reason to keep linum.el around any longer, or could it be
> marked obsolete in favor of `display-line-numbers-mode'?

(That was 4 weeks ago.)

Despite one notable objection on the grounds that it is still useful,
most people here seem to agree that we can go ahead and obsolete it,
given that it can be replaced by `nlinum' (on GNU ELPA) which is faster
and has less bugs.[1]

Meanwhile, Stefan Monnier pointed out that:[2]

> [O]bsoleting `linum.el` doesn't mean removing it from Emacs for
> several more years.  And even if/when we do decide to remove it, we
> can move it to GNU ELPA instead if there's still interest.

So I've now obsoleted linum.el in commit 903de63c6c and d506d91b1f, and
I'm closing this bug.  We recommend `nlinum' as a close to drop-in
replacement, alternatively `display-line-numbers-mode'.

Footnotes:
[1] Users also seem to like `nlinum', see e.g.:
     https://github.com/company-mode/company-mode/issues/1336

[2] Hopefully, however, Emacs will be shipping with nlinum.el included
     in our release tarballs by then.  We just need to figure out how to
     properly integrate GNU ELPA packages first.

Previous Next

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