Gnus development mailing list
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@lexort.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: ding@gnus.org, emacs-devel@gnu.org
Subject: Re: Gnus cleanup
Date: Tue, 09 Feb 2016 19:50:45 -0500	[thread overview]
Message-ID: <smud1s5jsm2.fsf@linuxpal.mit.edu> (raw)
In-Reply-To: <87h9hied21.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 09 Feb 2016 15:13:26 +1100")

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


Lars Ingebrigtsen <larsi@gnus.org> writes:

> In Emacs, we usually mark functions as obsolete for a few years before
> removing them, but I kinda feel like it's rather unlikely that there
> will be any other usages of gnus-window-inside-pixel-edges after I clean
> up the Gnus sources.

I'm someone who doesn't want to run emacs-current (because I want a
release), and I have some interest in running -current gnus, although
less so these days given how stable it is.  From my point of view, what
would be useful is retaining compat functions for the latest emacs 24
formal release, until emacs 25 is released.  I gather you don't want to
do that, but I think it would open up the ability to use current gnus to
a much wider audience for very little trouble, and that would help with
testing.

But, from where I sit, removing the compat functions from the gnus
sources within emacs-current doesn't hurt at all, once you are taking
out the calls to those functions.

It may be that there is almost nothing needed by gnus in emacs-25 not
available in emacs-24, or that there is some generic compat library to
provide the missing functions, and it will be easy enough to run emacs
24 with -current gnus.

I'll refrain from commenting on this in the future....

Sent from my Emacs 24.3.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 180 bytes --]

  parent reply	other threads:[~2016-02-10  0:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09  4:13 Lars Ingebrigtsen
2016-02-09  8:35 ` Michael Albinus
2016-02-09  8:35 ` Eric S Fraga
2016-02-09 11:42 ` Malcolm Purvis
2016-02-09 15:30 ` Stefan Monnier
2016-02-09 23:08   ` Lars Ingebrigtsen
2016-02-10  0:50 ` Greg Troxel [this message]
2016-02-12  4:19 ` Lars Ingebrigtsen
2016-02-13  0:22   ` Frank Haun
2016-02-13  1:57   ` Eric Abrahamsen
2016-02-13  3:17     ` Eric Abrahamsen
2016-02-13  3:43       ` Lars Ingebrigtsen
2016-02-13  4:26         ` Eric Abrahamsen
2016-02-13  4:59           ` Lars Ingebrigtsen
2016-02-13 12:00   ` Frank Haun
2016-02-13 15:37     ` Richard Stallman
2016-02-14  2:35     ` Lars Ingebrigtsen
2016-02-14  3:13       ` Adam Sjøgren
2016-02-14 13:12       ` Frank Haun
2016-02-17 21:10       ` Frank Haun
2016-02-18 12:29         ` Frank Haun
2016-03-07 13:52   ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=smud1s5jsm2.fsf@linuxpal.mit.edu \
    --to=gdt@lexort.com \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).