bug#57412: Could we make linum.el obsolete?

bug#57412: Could we make linum.el obsolete?

[Stefan Kangas]

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.

bug#57412: Could we make linum.el obsolete?

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca
> From: Stefan Kangas <stefankangas@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.

bug#57412: Could we make linum.el obsolete?

[Lars Ingebrigtsen]

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

bug#57412: Could we make linum.el obsolete?

[Dmitry Gutov]

On 26.08.2022 14:11, Lars Ingebrigtsen wrote:
> Eli Zaretskii<eliz@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

bug#57412: Could we make linum.el obsolete?

[Colin Baxter]

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

    > On 26.08.2022 14:11, Lars Ingebrigtsen wrote:
    >> Eli Zaretskii<eliz@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,

bug#57412: Could we make linum.el obsolete?

[Colin Baxter]

>>>>> Stefan Kangas <stefankangas@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,

bug#57412: Could we make linum.el obsolete?

[Dmitry Gutov]

On 26.08.2022 11:20, Colin Baxter wrote:
>>>>>> Stefan Kangas<stefankangas@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.

bug#57412: Could we make linum.el obsolete?

[Colin Baxter]

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

    > On 26.08.2022 11:20, Colin Baxter wrote:
    >>>>>>> Stefan Kangas<stefankangas@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,

bug#57412: Could we make linum.el obsolete?

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#57412: Could we make linum.el obsolete?

[Colin Baxter]

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

bug#57412: Could we make linum.el obsolete?

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#57412: Could we make linum.el obsolete?

[Drew Adams]

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

bug#57412: Could we make linum.el obsolete?

[Stefan Kangas]

close 57412 29.1
thanks

Stefan Kangas <stefankangas@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.