bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Severity: wishlist

I would like to confirm that for Emacs 29.1 we want to delete libraries
obsoleted five major versions ago, i.e. those obsoleted in Emacs 24.

Some things to note:

1. We cannot yet remove iswitchb.el, as isearchb.el depends on it (see
   Bug#36260).

2. We also cannot remove longlines.el, as so-long.el depends on it, and
   even recommends it in certain cases.

3. ccl-tests.el had to be updated to no longer depend on pgg-parse.el.

Other than that, I have not been able to find any problematic
dependencies or other issues.

If anyone wants to double-check the below list, you could use:

    (cd lisp/obsolete ; grep -iR "Obsolete-since: 24" * | sort -t ';' -k 3)

The change looks like this, excluding the massive diff showing all
18,000+ deleted lines:

commit 8ee48fb988bb058d1b6b3a0b96359e1e10a1d645 (HEAD -> master)
Author: Stefan Kangas <stefan@marxist.se>
Date:   Sun Oct 3 21:43:17 2021 +0200

    Delete libraries obsolete since Emacs 24

    * lisp/obsolete/abbrevlist.el:
    * lisp/obsolete/assoc.el:
    * lisp/obsolete/bruce.el:
    * lisp/obsolete/cc-compat.el:
    * lisp/obsolete/complete.el:
    * lisp/obsolete/crisp.el:
    * lisp/obsolete/cust-print.el:
    * lisp/obsolete/erc-hecomplete.el:
    * lisp/obsolete/info-edit.el:
    * lisp/obsolete/mailpost.el:
    * lisp/obsolete/meese.el:
    * lisp/obsolete/mouse-sel.el:
    * lisp/obsolete/old-emacs-lock.el:
    * lisp/obsolete/otodo-mode.el:
    * lisp/obsolete/patcomp.el:
    * lisp/obsolete/pc-mode.el:
    * lisp/obsolete/pc-select.el:
    * lisp/obsolete/pgg-def.el:
    * lisp/obsolete/pgg-gpg.el:
    * lisp/obsolete/pgg-parse.el:
    * lisp/obsolete/pgg-pgp.el:
    * lisp/obsolete/pgg-pgp5.el:
    * lisp/obsolete/pgg.el:
    * lisp/obsolete/rcompile.el:
    * lisp/obsolete/s-region.el:
    * lisp/obsolete/sregex.el:
    * lisp/obsolete/sup-mouse.el:
    * lisp/obsolete/terminal.el:
    * lisp/obsolete/tpu-edt.el:
    * lisp/obsolete/tpu-extras.el:
    * lisp/obsolete/tpu-mapper.el:
    * lisp/obsolete/vi.el:
    * lisp/obsolete/vip.el:
    * lisp/obsolete/ws-mode.el: Delete files.  These libraries have been
    obsolete since Emacs 24.
    * etc/NEWS: Announce their deletion.

    * test/lisp/international/ccl-tests.el: Fix tests to not depend on
    deleted file ppg-pars.el.

diff --git a/etc/NEWS b/etc/NEWS
index 20ed20308e..f6735a960c 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -77,6 +77,15 @@ Emacs buffers, like indentation and the like.  The
new ert function

 * Incompatible Lisp Changes in Emacs 29.1

+** Some libraries obsolete since Emacs 24 have been removed:
+abbrevlist.el, assoc.el, bruce.el, cc-compat.el, complete.el,
+crisp.el, cust-print.el, erc-hecomplete.el, info-edit.el, mailpost.el,
+meese.el, mouse-sel.el, old-emacs-lock.el, otodo-mode.el, patcomp.el,
+pc-mode.el, pc-select.el, pgg-def.el, pgg-gpg.el, pgg-parse.el,
+pgg-pgp.el, pgg-pgp5.el, pgg.el, rcompile.el, s-region.el, sregex.el,
+sup-mouse.el, terminal.el, tpu-edt.el, tpu-extras.el, tpu-mapper.el,
+vi.el, vip.el, ws-mode.el and yow.el.
+

[...]

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I would like to confirm that for Emacs 29.1 we want to delete libraries
> obsoleted five major versions ago, i.e. those obsoleted in Emacs 24.

That does seem logical, since we removed 23.3 stuff last time around.
But shouldn't we delete 24.1 things only -- 24.1-24.5 are distinct
releases (and not like 27.x and 28.x, which are only bugfix releases).

I think.  I haven't actually looked on the timeline for the 24.x releases.

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

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > I would like to confirm that for Emacs 29.1 we want to delete libraries
> > obsoleted five major versions ago, i.e. those obsoleted in Emacs 24.
>
> That does seem logical, since we removed 23.3 stuff last time around.
> But shouldn't we delete 24.1 things only -- 24.1-24.5 are distinct
> releases (and not like 27.x and 28.x, which are only bugfix releases).
>
> I think.  I haven't actually looked on the timeline for the 24.x releases.

In Emacs 28.1, we deleted anything obsoleted in Emacs 23:

2012-01-29 - Emacs 23.4 released
2011-03-10 - Emacs 23.3 released
2010-05-08 - Emacs 23.2 released
2009-07-29 - Emacs 23.1 released

This is what the release schedule looked like for Emacs 24:

2016-09-17 - Emacs 25.1 released
2015-04-10 - Emacs 24.5 released
2014-10-20 - Emacs 24.4 released
2013-03-11 - Emacs 24.3 released
2012-08-27 - Emacs 24.2 released
2012-06-10 - Emacs 24.1 released

(Emacs 23 was around for ~3 years, but Emacs 24 was around for ~4.)

Assuming that Emacs 29 will be released in 2022 or 2023, removing
anything from 24.1-24.3 should mean it's been 9-10 years since the
libraries were obsoleted in an official release.  If we remove stuff
obsoleted in 24.4 and 24.5 as well, that would mean it's only been 7-8
years.  The former should be okay and in line with our historical
practice, the latter is a bit more enthusiastic and could be
discussed.

FWIW, it is kind of nice to have the easy to understand principle that
we generally delete obsolete stuff after five major releases, but it
is true that version 24 is somewhat different from 23, 25, 26 and 27
in that it was around for longer.

I think we should just decide what we want to do in Emacs 29, and then
apply the same principle for deleting obsolete functions, variables,
etc.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Assuming that Emacs 29 will be released in 2022 or 2023, removing
> anything from 24.1-24.3 should mean it's been 9-10 years since the
> libraries were obsoleted in an official release.  If we remove stuff
> obsoleted in 24.4 and 24.5 as well, that would mean it's only been 7-8
> years.  The former should be okay and in line with our historical
> practice, the latter is a bit more enthusiastic and could be
> discussed.

Yeah, I think removing 24.4 and 24.5 things would be premature, but the
older stuff should be fine.

> FWIW, it is kind of nice to have the easy to understand principle that
> we generally delete obsolete stuff after five major releases, but it
> is true that version 24 is somewhat different from 23, 25, 26 and 27
> in that it was around for longer.

We've changed our naming methodology -- we used to have major and minor
releases, but with Emacs 27 we ditched that, so the obsoletion strategy
has to be adjusted a bit.

> I think we should just decide what we want to do in Emacs 29, and then
> apply the same principle for deleting obsolete functions, variables,
> etc.

Yup.  I think everything obsoleted before Emacs 24.3 should be up for
removal in Emacs 29 (since that'd be about a decade old when Emacs 29 is
released), but perhaps Eli has a different opinion.  Eli?

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

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 05 Oct 2021 09:02:35 +0200
> Cc: 50999@debbugs.gnu.org
> 
> > I think we should just decide what we want to do in Emacs 29, and then
> > apply the same principle for deleting obsolete functions, variables,
> > etc.
> 
> Yup.  I think everything obsoleted before Emacs 24.3 should be up for
> removal in Emacs 29 (since that'd be about a decade old when Emacs 29 is
> released), but perhaps Eli has a different opinion.  Eli?

I'd prefer to see the full list of the candidates before we decide.
It could be that some items on the list need to get special treatment
for some valid reasons, or perhaps because we've learned something new
since they were obsoleted.

Thanks.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Phil Sainty]

On 2021-10-06 01:27, Eli Zaretskii wrote:
> It could be that some items on the list need to get special treatment
> for some valid reasons, or perhaps because we've learned something new
> since they were obsoleted.

One such case is longlines.el -- I'd like this to not only be retained,
but also be restored to non-obsolete status.

This was marked obsolete in 24.4 on the basis that visual-line-mode
provided a better alternative, and indeed visual-line-mode is better
for wrapping lines of normal lengths; however longlines-mode is
actually very valuable for editing files with lines that are so long
that they cause performance problems.  This is because longlines-mode
converts the long lines into short lines for editing, and therefore
it will give you good performance at *any* position in the file.

For this reason, so-long.el has supported longlines-mode as a standard
action since version 1.0.  While so-long-mode is very fast to enable,
it still won't cope well if you move point deep into an incredibly long
line.  Conversely longlines-mode is slow to enable (as it has to break
all the long lines), but it then gives good performance everywhere in
the buffer.  As such they complement one another (and you can switch
between them via the "So Long" menu).


-Phil

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Phil Sainty <psainty@orcon.net.nz> writes:

> One such case is longlines.el -- I'd like this to not only be retained,
> but also be restored to non-obsolete status.

longlines.el will not be removed here, as I said in the first message in
this thread.  Even if it were up for removal, that would be in Emacs 30,
as it was obsoleted in Emacs 24.4, and the decision is to not remove
anything obsoleted in that version.

I have not formed an opinion on the rest of your email, but may I
propose that it might be better to open a new bug report for
un-obsoleting it?

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Phil Sainty]

On 2021-10-06 02:39, Stefan Kangas wrote:
> longlines.el will not be removed here, as I said in the first message
> in this thread.

Oops.  Apologies for missing that.

> I have not formed an opinion on the rest of your email, but may
> I propose that it might be better to open a new bug report for
> un-obsoleting it?

I'll do that now.


-Phil

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd prefer to see the full list of the candidates before we decide.
> It could be that some items on the list need to get special treatment
> for some valid reasons, or perhaps because we've learned something new
> since they were obsoleted.

This is the list:

abbrevlist.el:;; Obsolete-since: 24.1
complete.el:;; Obsolete-since: 24.1
erc-hecomplete.el:;; Obsolete-since: 24.1
old-emacs-lock.el:;; Obsolete-since: 24.1
pc-mode.el:;; Obsolete-since: 24.1
pc-select.el:;; Obsolete-since: 24.1
pgg-def.el:;; Obsolete-since: 24.1
pgg-gpg.el:;; Obsolete-since: 24.1
pgg-parse.el:;; Obsolete-since: 24.1
pgg-pgp.el:;; Obsolete-since: 24.1
pgg-pgp5.el:;; Obsolete-since: 24.1
pgg.el:;; Obsolete-since: 24.1
s-region.el:;; Obsolete-since: 24.1
sregex.el:;; Obsolete-since: 24.1
assoc.el:;; Obsolete-since: 24.3
bruce.el:;; Obsolete-since: 24.3
cust-print.el:;; Obsolete-since: 24.3
mailpost.el:;; Obsolete-since: 24.3
mouse-sel.el:;; Obsolete-since: 24.3
patcomp.el:;; Obsolete-since: 24.3

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I'd prefer to see the full list of the candidates before we decide.
>> It could be that some items on the list need to get special treatment
>> for some valid reasons, or perhaps because we've learned something new
>> since they were obsoleted.
>
> This is the list:

Filename              Obsolete-since

abbrevlist.el         24.1
complete.el           24.1
erc-hecomplete.el     24.1
old-emacs-lock.el     24.1
pc-mode.el            24.1
pc-select.el          24.1
pgg-def.el            24.1
pgg-gpg.el            24.1
pgg-parse.el          24.1
pgg-pgp.el            24.1
pgg-pgp5.el           24.1
pgg.el                24.1
s-region.el           24.1
sregex.el             24.1

assoc.el              24.3
bruce.el              24.3
cust-print.el         24.3
mailpost.el           24.3
mouse-sel.el          24.3
patcomp.el            24.3

Ping.  What do you think of the above list (reformatted for easier
reading)?

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Drew Adams]

> Filename              Obsolete-since
> complete.el           24.1

Please don't delete complete.el.

(It actually deserves some up-to-date love.
I expect it may even get some, what with the
recent revival of interest in completion.)

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> Filename              Obsolete-since
>> complete.el           24.1
>
> Please don't delete complete.el.
>
> (It actually deserves some up-to-date love.
> I expect it may even get some, what with the
> recent revival of interest in completion.)

Care to elaborate?  Meanwhile, I'm copying in Stefan Monnier who marked
that library as obsolete, in case he has any comments.

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Drew Adams]

> >> Filename              Obsolete-since
> >> complete.el           24.1
> >
> > Please don't delete complete.el.
> >
> > (It actually deserves some up-to-date love.
> > I expect it may even get some, what with the
> > recent revival of interest in completion.)
> 
> Care to elaborate?  Meanwhile, I'm copying in Stefan Monnier who marked
> that library as obsolete, in case he has any comments.

Very sorry.  I was thinking of completion.el,
not complete.el.  Sorry for the noise.

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> Very sorry.  I was thinking of completion.el,
> not complete.el.  Sorry for the noise.

OK, thanks for clarifying.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Stefan Kangas <stefan@marxist.se> writes:

> pgg-def.el            24.1
> pgg-gpg.el            24.1
> pgg-parse.el          24.1
> pgg-pgp.el            24.1
> pgg-pgp5.el           24.1
> pgg.el                24.1
> assoc.el              24.3

Please at least keep assoc.el and pgg.

Thanks.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> pgg-def.el            24.1
>> pgg-gpg.el            24.1
>> pgg-parse.el          24.1
>> pgg-pgp.el            24.1
>> pgg-pgp5.el           24.1
>> pgg.el                24.1
>> assoc.el              24.3
>
> Please at least keep assoc.el and pgg.

We are looking into deleting pgg*.el, but Po Lu has requested that they
remain.  pgg*.el was marked obsolete by its original author Daiki Ueno
in 2010.

Po Lu writes:

> PGG is important for working with the various odd implementations of PGP
> that can be found on antiquated systems.  I use it regularly at my day
> job, and would really appreciate it not being removed.

Daiki, any comments here?

Thanks in advance.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> pgg-def.el            24.1
>> pgg-gpg.el            24.1
>> pgg-parse.el          24.1
>> pgg-pgp.el            24.1
>> pgg-pgp5.el           24.1
>> pgg.el                24.1
>> assoc.el              24.3
>
> Please at least keep assoc.el and pgg.

We are looking into deleting assoc.el, but Po Lu has requested that it
remains.  assoc.el was marked obsolete by Stefan Monnier in 2012.

Po Lu writes:

> There are many instances of `asort', `aelement', `aput' and `adelete'
> in the Lisp files commonly shared around my organization, many of which
> have to work with Emacs 23 and even Emacs 21 (as some of our Emacs users
> will not move to anything newer).

Stefan, any comments here?

Thanks in advance.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Glenn Morris]

>> There are many instances of `asort', `aelement', `aput' and `adelete'
>> in the Lisp files commonly shared around my organization, many of which
>> have to work with Emacs 23 and even Emacs 21 (as some of our Emacs users
>> will not move to anything newer).

If it were me, I'd just bundle assoc.el with my code, rather than ask
upstream to distribute it forever.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Glenn Morris <rgm@gnu.org> writes:

> If it were me, I'd just bundle assoc.el with my code, rather than ask
> upstream to distribute it forever.

That raises the question of where to put assoc.el.  It might also lead
to a proliferation of various incompatible versions of it.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Po Lu [2021-12-07 10:21:28] wrote:
> Glenn Morris <rgm@gnu.org> writes:
>> If it were me, I'd just bundle assoc.el with my code, rather than ask
>> upstream to distribute it forever.
> That raises the question of where to put assoc.el.

I recommend /dev/null for it.

> It might also lead to a proliferation of various incompatible versions
> of it.

Seeing that there's been basically no substantial made to it in a decade
(other than cosmetic fixes), I wouldn't worry about it.
Also because its semantics is sufficiently twisted that it'd be pretty
hard to make any non-trivial change without risking breaking something.


        Stefan

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

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

> Po Lu [2021-12-07 10:21:28] wrote:
>> Glenn Morris <rgm@gnu.org> writes:
>>> If it were me, I'd just bundle assoc.el with my code, rather than ask
>>> upstream to distribute it forever.
>> That raises the question of where to put assoc.el.
>
> I recommend /dev/null for it.
>
>> It might also lead to a proliferation of various incompatible versions
>> of it.
>
> Seeing that there's been basically no substantial made to it in a decade
> (other than cosmetic fixes), I wouldn't worry about it.
> Also because its semantics is sufficiently twisted that it'd be pretty
> hard to make any non-trivial change without risking breaking something.

To summarize this discussion, it seems like those who still need that
file should just keep a local copy.

One idea is to just copy the definitions from that short file to any
files that still use them.  (If it was me, I'd just wrap the definition
in unless+fboundp.)

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Stefan Kangas <stefan@marxist.se> writes:

> To summarize this discussion, it seems like those who still need that
> file should just keep a local copy.

> One idea is to just copy the definitions from that short file to any
> files that still use them.  (If it was me, I'd just wrap the definition
> in unless+fboundp.)

I will give that a try, but please wait at least a week for me to make
some noise if it causes problems.

Thanks.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 3 Dec 2021 06:56:43 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50999@debbugs.gnu.org
> 
> Filename              Obsolete-since
> 
> abbrevlist.el         24.1
> complete.el           24.1
> erc-hecomplete.el     24.1
> old-emacs-lock.el     24.1
> pc-mode.el            24.1
> pc-select.el          24.1
> pgg-def.el            24.1
> pgg-gpg.el            24.1
> pgg-parse.el          24.1
> pgg-pgp.el            24.1
> pgg-pgp5.el           24.1
> pgg.el                24.1
> s-region.el           24.1
> sregex.el             24.1
> 
> assoc.el              24.3
> bruce.el              24.3
> cust-print.el         24.3
> mailpost.el           24.3
> mouse-sel.el          24.3
> patcomp.el            24.3
> 
> Ping.  What do you think of the above list (reformatted for easier
> reading)?

Thanks.

I think bruce.el should be left in Emacs.  (I also think it shouldn't
have been moved to obsolete/, but I'm sure Glenn and others will
pounce on me for saying that, so let's pretend I didn't say it.)

I have no objections for removing the rest.  (But please let others
comment, and please take those comments into account.)

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I think bruce.el should be left in Emacs.  (I also think it shouldn't
> have been moved to obsolete/, but I'm sure Glenn and others will
> pounce on me for saying that, so let's pretend I didn't say it.)
>
> I have no objections for removing the rest.  (But please let others
> comment, and please take those comments into account.)

Thanks, will do.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Stefan Kangas]

close 50999 29.1
thanks

Eli Zaretskii <eliz@gnu.org> writes:

> I think bruce.el should be left in Emacs.  (I also think it shouldn't
> have been moved to obsolete/, but I'm sure Glenn and others will
> pounce on me for saying that, so let's pretend I didn't say it.)
>
> I have no objections for removing the rest.  (But please let others
> comment, and please take those comments into account.)

Two reviewers requested that bruce.el and pgg-*.el should be left for
now, but the discussion showed that the rest can go.  So I have now done
that on master (commit 17b3f8d56e), and I'm closing this bug report.

Assuming that the kept libraries are still marked obsolete, it seems
natural to reconsider their deletion in time for Emacs 30.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Stefan Kangas <stefan@marxist.se> writes:

>     * lisp/obsolete/assoc.el:

There are many instances of `asort', `aelement', `aput' and `adelete'
in the Lisp files commonly shared around my organization, many of which
have to work with Emacs 23 and even Emacs 21 (as some of our Emacs users
will not move to anything newer).

>     * lisp/obsolete/info-edit.el:

I maintain hand-written Info documentation for most software at my
organization, which I edit with the mechanism provided in info-edit.el.

I would really appreciate it not being removed.

>     * lisp/obsolete/pgg-def.el:
>     * lisp/obsolete/pgg-gpg.el:
>     * lisp/obsolete/pgg-parse.el:
>     * lisp/obsolete/pgg-pgp.el:
>     * lisp/obsolete/pgg-pgp5.el:
>     * lisp/obsolete/pgg.el:

PGG is important for working with the various odd implementations of PGP
that can be found on antiquated systems.  I use it regularly at my day
job, and would really appreciate it not being removed.

>     * lisp/obsolete/vip.el:

Where I work, there is someone still using VIP.  She thinks that newer
packages, such as Viper, have deviated too far from the vi behaviour she
remembers to still be useful to her.

Of the rest, I have no specific opinion, but I'd like to ask something:
why remove this code at all?  Obsolete code doesn't have to be
maintained, and if nobody is really interested in it, it will eventually
rot.

People interested in PGG or VIP will naturally come across issues in
that code and fix it.

So instead of removing obsolete code every N releases, how about
removing all references to such code from the documentation, not
byte-compiling it during builds, and not running tests on that code?

A few more files in obsolete/ cannot possibly hurt, especially if nobody
is expected to maintain them.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The reason we continue to maintain obsolete Lisp packages is that
some people are still using them.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Richard Stallman <rms@gnu.org> writes:

> The reason we continue to maintain obsolete Lisp packages is that
> some people are still using them.

I'm saying that obsolete Lisp packages shouldn't be removed from the
distribution just because a certain degree of time has passed.

And secondly, perhaps even the ones that people "are not using" could be
left as-is, without maintenance.

They could still be useful in the future.  Someone might decide to
resurrect them, and some other unaccounted for person might still be
using them.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Lars Ingebrigtsen]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> And secondly, perhaps even the ones that people "are not using" could be
> left as-is, without maintenance.
>
> They could still be useful in the future.  Someone might decide to
> resurrect them, and some other unaccounted for person might still be
> using them.

It's just not practical.  We have to get rid of things that we no longer
think is very useful in Emacs, otherwise Emacs will grow unbounded, and
we don't have the maintainer capacity for that.

Emacs has a package system.  If there's a feature we remove from Emacs
that people think is useful, they'll create a package for it and carry
on.

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

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's just not practical.  We have to get rid of things that we no longer
> think is very useful in Emacs, otherwise Emacs will grow unbounded, and
> we don't have the maintainer capacity for that.

What about what I proposed, i.e. not byte-compiling those files, and in
general paying no attention to them?

It would take quite a long time for that to have an effect on the size
of Emacs.  And it wouldn't require any maintenance; we could have a
folder acting as a dumping ground for Lisp that would otherwise be
deleted.

> Emacs has a package system.  If there's a feature we remove from Emacs
> that people think is useful, they'll create a package for it and carry
> on.

What about an ELPA package, playing the same role as the dumping ground
folder?

I look forward to hearing your thoughts on this, thanks.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> What about what I proposed, i.e. not byte-compiling those files, and in
> general paying no attention to them?

I don't think that's feasible -- if something breaks, then people will
be reporting bugs about those things.  Not byte-compiling them would
just be more work in the long run, because we'd be discovering the
issues later, and not when somebody does a change that requires the
other files to change.

> What about an ELPA package, playing the same role as the dumping ground
> folder?

If somebody wants to maintain vip.el externally (to take an example),
then we could indeed put it in GNU ELPA.  But if not, then it's the
same -- we're maintaining the things that's included in the ELPA repo.

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

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't think that's feasible -- if something breaks, then people will
> be reporting bugs about those things.  Not byte-compiling them would
> just be more work in the long run, because we'd be discovering the
> issues later, and not when somebody does a change that requires the
> other files to change.

How about telling people to not report bugs in those packages?  For
instance, a disclaimer stating "this is obsolete and unsupported -- use
at your own risk".

Perhaps report-emacs-bug could detect that case, and warn the user.

Thanks.

bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> How about telling people to not report bugs in those packages?  For
> instance, a disclaimer stating "this is obsolete and unsupported -- use
> at your own risk".
>
> Perhaps report-emacs-bug could detect that case, and warn the user.

If we distribute code, then we'll be fixing bugs in that code.  I don't
think there's any way around that.

We choose what code to introduce into Emacs, based on many things, but
among them is a consideration whether we think that the feature will be
useful to many people or not.  It's the same consideration when removing
features -- if we think that it's not used, then we remove it.  (And we
find out by making it obsolete and seeing whether there's any
complaints.)

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

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Drew Adams]

> > How about telling people to not report bugs in those packages?  For
> > instance, a disclaimer stating "this is obsolete and unsupported -- use
> > at your own risk".
> >
> > Perhaps report-emacs-bug could detect that case, and warn the user.
> 
> If we distribute code, then we'll be fixing bugs in that code.  I don't
> think there's any way around that.

I don't agree.

For a long time Emacs even distributed a "contrib"
directory with code provided by others.  It had
the right licenses, but was in no way maintained
or "fixed" by Emacs dev.  It was likely vetted at
the outset, at least in a superficial way.

And there are libraries in Emacs today that are
NOT considered obsolete and yet have undergone no
maintenance in years, sometimes even decades.

It doesn't follow that continuing to distribute
"obsolete" code imposes an obligation on Emacs dev.

There's no obligation to make changes to _any_
Emacs code (with the possible exception of a
moral obligation to fix moral and security bugs).

> We choose what code to introduce into Emacs, based on many things, but
> among them is a consideration whether we think that the feature will be
> useful to many people or not.  It's the same consideration when removing
> features -- if we think that it's not used, then we remove it.  (And we
> find out by making it obsolete and seeing whether there's any
> complaints.)

Obviously some people think that some (maybe even
all) of the "obsolete" code is useful.  Why not
keep it?

What is really gained by removing "obsolete" code?
I think the answer is "nothing".
___

Same goes for closing many bugs that are recognized
as bugs but that no one is _currently_ apt to try
to fix.  It's logical to keep them open, but some
might think it looks good somehow to close them.
Closing bugs is not the same as fixing them.

(One opinion.)

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 14 Nov 2021 17:48:12 +0000
> Cc: "50999@debbugs.gnu.org" <50999@debbugs.gnu.org>,
>  "stefan@marxist.se" <stefan@marxist.se>, Richard Stallman <rms@gnu.org>
> 
> For a long time Emacs even distributed a "contrib"
> directory with code provided by others.

According to the VCS logs, we never had such a directory.

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Drew Adams]

> > For a long time Emacs even distributed a "contrib"
> > directory with code provided by others.
> 
> According to the VCS logs, we never had such a directory.

I distinctly remember it, and I recall using some
of its code.  But it was long ago.  And I may have
been wrong that GNU Emacs distribution included it
"for a long time".

How far back do the VCS logs go?  Would they even
have dealt with/recorded/managed code that wasn't
maintained?

Perhaps Richard recalls this directory.  Not very
important, in any case.

The point is that there's no obligation to make
changes (maintenance or other) to code that you've
declared is "obsolete".  Do you disagree with that
point?

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "luangruo@yahoo.com"
> 	<luangruo@yahoo.com>,
>         "50999@debbugs.gnu.org" <50999@debbugs.gnu.org>,
>         "stefan@marxist.se" <stefan@marxist.se>, "rms@gnu.org" <rms@gnu.org>
> Date: Sun, 14 Nov 2021 18:04:40 +0000
> 
> > > For a long time Emacs even distributed a "contrib"
> > > directory with code provided by others.
> > 
> > According to the VCS logs, we never had such a directory.
> 
> I distinctly remember it, and I recall using some
> of its code.

Show me some distribution that had it, and/or name some files there,
and then I could have a look.  (Assuming this is important.)

> How far back do the VCS logs go?

Back to the very first commits by RMS and friends, in early 1985.

> The point is that there's no obligation to make
> changes (maintenance or other) to code that you've
> declared is "obsolete".

It's easy for you to say that, since you don't have to pick up the
gauntlet of the maintenance.  The downside is non-negligible.

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Drew Adams]

> > The point is that there's no obligation to make
> > changes (maintenance or other) to code that you've
> > declared is "obsolete".
> 
> It's easy for you to say that, since you don't have to pick up the
> gauntlet of the maintenance.  The downside is non-negligible.

What's the obligation to maintain any particular
obsolete code?

(Apart from what I mentioned: moral/security
issues, and apart from possible copyright etc.
issues (e.g. yow).)

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "luangruo@yahoo.com"
> 	<luangruo@yahoo.com>,
>         "50999@debbugs.gnu.org" <50999@debbugs.gnu.org>,
>         "stefan@marxist.se" <stefan@marxist.se>, "rms@gnu.org" <rms@gnu.org>
> Date: Sun, 14 Nov 2021 18:35:06 +0000
> Accept-Language: en-US
> 
> > > The point is that there's no obligation to make
> > > changes (maintenance or other) to code that you've
> > > declared is "obsolete".
> > 
> > It's easy for you to say that, since you don't have to pick up the
> > gauntlet of the maintenance.  The downside is non-negligible.
> 
> What's the obligation to maintain any particular
> obsolete code?

Lars answered that up-thread.

bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Drew Adams]

> > > > The point is that there's no obligation to
> > > > make changes (maintenance or other) to code
> > > > that you've declared is "obsolete".
> > >
> > > It's easy for you to say that, since you don't
> > > have to pick up the gauntlet of the maintenance.
> > > The downside is non-negligible.
> >
> > What's the obligation to maintain any
> > particular obsolete code?
> 
> Lars answered that up-thread.

Where?

I see that he claimed this:

> If we distribute code, then we'll be fixing
> bugs in that code.  I don't think there's
> any way around that.

No reason given there - just a claim that such
fixing has to be done.

And elsewhere in the thread he said this:

> We have to get rid of things that we no longer
> think is very useful in Emacs, otherwise Emacs
> will grow unbounded, and we don't have the
> maintainer capacity for that.

I don't see any evidence that keeping what we
have means Emacs will grow unbounded.

And some things are anyway removed or replaced
without their ever having been made obsolete.

There's no reason given there, for supposing
that even unbounded growth - which would come
from the growth of code that's NOT obsolete -
would in any way add to the maintenance burden
("maintainer capacity" and "gauntlet of the
maintenance").

Lots of holes, if that's the reason you meant
to reference.  But please do point to what
you really mean, to make things clear.

I don't see where Lars or anyone else gave a
reason that would oblige anyone to fix bugs
in such code.

It should also be easy enough for you to
restate the reason, or summarize it, if you
too can't find it.
___

Here's a related question, which might hint at
whether there's reason to suppose that not
removing obsolete code _would_ impose a
maintenance burden:

When was the last maintenance done on obsolete
code?  When was _any_ bug fixed on such code?
IOW, how about measuring past such work, as an
indication of the supposed burden?

This question is different from whether there's
some obligation for performing such maintenance.
IOW, even if we suppose such an obligation,
what's the actual burden to be expected?