Moving Gnus development to Emacs?

Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

(Excuse the crossposting.)

Back in the olden days, there were basically two reasons for doing the
Gnus development outside of Emacs: 1) Emacs was releasing very slowly,
and Gnus very fast, and 2) XEmacs was an important target for
development.

1) is not true any more.  And XEmacs isn't as vital as it used to be.

And the SXEmacs peeps just started maintaining their own Gnus repo,
which means that this might be a good opportunity to discontinue the
git.gnus.org repo and just continue development on the Emacs trunk
instead.

Emacs has developed rapidly during the last few years, and the
interfaces between Emacs, older versions of Emacs, and XEmacs are
growing more divergent.  This means that basically any change we do in
Gnus fails to build on all build targets.  And this, in turn, means that
any change we do in Gnus is 2x as much work as it should be, and this
leaves the code looking like an exercise in obfuscated programming.
Sometimes.  :-)

So: I want to know how all y'all would feel if I closed git.gnus.org and
started bringing the Gnus code base in the Emacs trunk up to modern
Emacs standards.  That would mean removing basically all compat code.

No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

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

Re: Moving Gnus development to Emacs

[Steve Youngs]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > (Excuse the crossposting.)

No problem.  Apologies for my list bouncing you. I've tweaked my mailman
settings so subsequent messages shouldn't get discarded (fingers crossed)

  > Back in the olden days, there were basically two reasons for doing
  > the Gnus development outside of Emacs: 1) Emacs was releasing very
  > slowly, and Gnus very fast, and 2) XEmacs was an important target
  > for development.

  > 1) is not true any more.  And XEmacs isn't as vital as it used to be.

Yep, I'll certainly give you that.  The advantage/benefits I see to
having the Gnus code base reside outside of Emacs is that (S)XEmacs Gnus
hackers don't need to have a copy of Emacs checked out just to hack
Gnus.  And I'm sure that there are plenty who'd like to hack/use dev
Gnus from stable Emacs.

  > And the SXEmacs peeps just started maintaining their own Gnus repo,

Wow, news gets around fast. :-)  I gotta admit though that I wasn't
planning on doing anything large scale with that.  Just the odd tweaks
to keep it build-able and run-able. (partially motivated by apparent
stagnation in XEmacs packages)

  > which means that this might be a good opportunity to discontinue the
  > git.gnus.org repo and just continue development on the Emacs trunk
  > instead.

  > Emacs has developed rapidly during the last few years, and the
  > interfaces between Emacs, older versions of Emacs, and XEmacs are
  > growing more divergent.  This means that basically any change we do in
  > Gnus fails to build on all build targets.  And this, in turn, means that
  > any change we do in Gnus is 2x as much work as it should be, and this
  > leaves the code looking like an exercise in obfuscated programming.
  > Sometimes.  :-)

But this has nothing to do with _where_ the canonical source repo is,
and everything to do with _which_ emacsen you want to support.

  > So: I want to know how all y'all would feel if I closed git.gnus.org and
  > started bringing the Gnus code base in the Emacs trunk up to modern
  > Emacs standards.

I'd feel sad, but I guess I could live with it.  I'm not sure how I
could keep my Gnus repo tracking your development if your stuff isn't in
its own repo, but I'll figure something out.

  > That would mean removing basically all compat code.

OK, from where I sit, this would totally suck. :-(  And anyone not
wanting to use dev Emacs would just have to put it all back in.

Any chance I could talk you out of it?  Is there a compromise?  Would it
be possible/acceptable to leave in the existing compat code but not
update it or use it for any new features from this point on? (I realise
this wouldn't be possible every time)

Or perhaps only remove the stuff that is currently proving to be trouble
spots for you (analogous to "If it ain't broke, don't fix it")?

I don't mind having to bring my own glue to get the lastest and greatest
shiny new feature working, but I don't want to glue stuff that has been
working fine for me for the last 15 to 20 years.

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve@sxemacs.org>---|

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

Re: Moving Gnus development to Emacs

[Ivan Shmakov]

>>>>> Steve Youngs <steve@sxemacs.org> writes:
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

[…]

 > The advantage/benefits I see to having the Gnus code base reside
 > outside of Emacs is that (S)XEmacs Gnus hackers don't need to have a
 > copy of Emacs checked out just to hack Gnus.  And I'm sure that there
 > are plenty who'd like to hack/use dev Gnus from stable Emacs.

	The converse is also true: moving Gnus into a separate Git
	submodule would allow those of the Emacs developers not
	interested in Gnus /not/ to check it out.  And while I’m not in
	that group, there’re several large Emacs packages which I’d
	find convenient /not/ to have in the checkouts I work with.

	Sadly, there seem to be a general consensus among the GNU
	developers to avoid any use whatsoever of Git submodules.
	The issues with this approach include the impossibility for a
	single commit to span several submodules; and I guess having the
	tests run on the whole Emacs tree helps to weed out the changes
	that should not be.

 >> Emacs has developed rapidly during the last few years, and the
 >> interfaces between Emacs, older versions of Emacs, and XEmacs are
 >> growing more divergent.  This means that basically any change we do
 >> in Gnus fails to build on all build targets.  And this, in turn,
 >> means that any change we do in Gnus is 2x as much work as it should
 >> be, and this leaves the code looking like an exercise in obfuscated
 >> programming.  Sometimes.  :-)

 > But this has nothing to do with _where_ the canonical source repo is,
 > and everything to do with _which_ emacsen you want to support.

	Yes.

[…]

 >> That would mean removing basically all compat code.

 > OK, from where I sit, this would totally suck. :-(  And anyone not
 > wanting to use dev Emacs would just have to put it all back in.

	Given that two concurent branches of Emacs are generally
	maintained (master and emacs-25 currently), there’s a fair
	chance that the users of the latest point release will still be
	entitled to try the latest Gnus – from the respective branch.
	But yes, all the major features would likely only be available
	for the ‘master’ (Gnus, Emacs) version.

 > Any chance I could talk you out of it?  Is there a compromise?  Would
 > it be possible/acceptable to leave in the existing compat code but
 > not update it or use it for any new features from this point on?  (I
 > realise this wouldn't be possible every time)

	Whatever this discussion will end on, I guess it’d still be
	possible to move the compatibility code into the XEmacs Gnus
	“port” and maintain it there.

[…]

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Re: Moving Gnus development to Emacs?

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 30 Dec 2015 12:43:12 +0100
> Cc: yamaoka@jpl.org, sxemacs-devel@sxemacs.org, emacs-devel@gnu.org
> 
> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

What next?  Emacs without any bugs?

Re: Moving Gnus development to Emacs?

[raman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

This would be nice!> (Excuse the crossposting.)
>
> Back in the olden days, there were basically two reasons for doing the
> Gnus development outside of Emacs: 1) Emacs was releasing very slowly,
> and Gnus very fast, and 2) XEmacs was an important target for
> development.
>
> 1) is not true any more.  And XEmacs isn't as vital as it used to be.
>
> And the SXEmacs peeps just started maintaining their own Gnus repo,
> which means that this might be a good opportunity to discontinue the
> git.gnus.org repo and just continue development on the Emacs trunk
> instead.
>
> Emacs has developed rapidly during the last few years, and the
> interfaces between Emacs, older versions of Emacs, and XEmacs are
> growing more divergent.  This means that basically any change we do in
> Gnus fails to build on all build targets.  And this, in turn, means that
> any change we do in Gnus is 2x as much work as it should be, and this
> leaves the code looking like an exercise in obfuscated programming.
> Sometimes.  :-)
>
> So: I want to know how all y'all would feel if I closed git.gnus.org and
> started bringing the Gnus code base in the Emacs trunk up to modern
> Emacs standards.  That would mean removing basically all compat code.
>
> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

-- 

Re: Moving Gnus development to Emacs?

[Nikolaus Rath]

On Dec 30 2015, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> So: I want to know how all y'all would feel if I closed git.gnus.org and
> started bringing the Gnus code base in the Emacs trunk up to modern
> Emacs standards.  That would mean removing basically all compat code.

Yes please!

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: Moving Gnus development to Emacs?

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> So: I want to know how all y'all would feel if I closed git.gnus.org and
> started bringing the Gnus code base in the Emacs trunk up to modern Emacs
> standards. That would mean removing basically all compat code.

Sounds great to me.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Moving Gnus development to Emacs?

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!

That's great.  I'm ok to move the gnus-doc-ja repo to github or
something when closing git.gnus.org.

Re: Moving Gnus development to Emacs?

[Julien Danjou]

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

On Wed, Dec 30 2015, Lars Magne Ingebrigtsen wrote:

> So: I want to know how all y'all would feel if I closed git.gnus.org and
> started bringing the Gnus code base in the Emacs trunk up to modern
> Emacs standards.  That would mean removing basically all compat code.

No objection sir.

-- 
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info

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

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Wed, 30 Dec 2015 12:43:12 +0100
* Also sprach Lars Magne Ingebrigtsen <larsi@gnus.org>:

> So: I want to know how all y'all would feel if I closed git.gnus.org
> and started bringing the Gnus code base in the Emacs trunk up to
> modern Emacs standards. That would mean removing basically all compat
> code.
>
> No more `mm-string-as-unibyte'. No more `gnus-invisible-p'. Freedom!
+1
Great idea to me.

Re: Moving Gnus development to Emacs?

[David Engster]

Lars Magne Ingebrigtsen writes:
> So: I want to know how all y'all would feel if I closed git.gnus.org and
> started bringing the Gnus code base in the Emacs trunk up to modern
> Emacs standards.  That would mean removing basically all compat code.

No objections from me (I'm currently doing the same for CEDET, for
pretty much the same reasons), but just to clarify: this means that we
only care about the current Emacs version and do not do separate
releases anymore? I'm mostly worried about how this will affect the
T-shirt release process.

-David

Re: Moving Gnus development to Emacs?

[Michael Albinus]

David Engster <deng@randomsample.de> writes:

> No objections from me (I'm currently doing the same for CEDET, for
> pretty much the same reasons), but just to clarify: this means that we
> only care about the current Emacs version and do not do separate
> releases anymore? I'm mostly worried about how this will affect the
> T-shirt release process.

Tramp will also remove the XEmacs compat code (and the compat code for
Emacs 22, to be precise). But the development will still be outside
Emacs, in order to support older Emacsen but master, and in order to
release more frequently than Emacs. One idea is to add Tramp also to
ELPA, as subtree. People could get than a newer version of Tramp than
the built-in.

This decision is not T-shirt driven, I fear the market for Tramp
T-shirts is much too small.

> -David

Best regards, Michael.

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Thu, 31 Dec 2015 12:43:06 +0100
* Also sprach Michael Albinus <michael.albinus@gmx.de>:

> David Engster <deng@randomsample.de> writes:
>
>> No objections from me (I'm currently doing the same for CEDET, for
>> pretty much the same reasons), but just to clarify: this means that
>> we only care about the current Emacs version and do not do separate
>> releases anymore? I'm mostly worried about how this will affect the
>> T-shirt release process.
>
> Tramp will also remove the XEmacs compat code (and the compat code for
> Emacs 22, to be precise). But the development will still be outside
> Emacs, in order to support older Emacsen but master, and in order to
> release more frequently than Emacs. One idea is to add Tramp also to
> ELPA, as subtree. People could get than a newer version of Tramp than
> the built-in.

John talked about new trend to move more codes into ELPA.
Maybe it's THE RIGHT WAY, to make emacs as emacs-core (with only bare
functions) and all others packges (core as ELPA, third party as Melpa
etc, or even PPA). If package.el becomes APT like, that'll be cool,
really cool.

Re: Moving Gnus development to Emacs?

[Eli Zaretskii]

> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Date: Thu, 31 Dec 2015 09:46:41 +0900
> Cc: yamaoka@jpl.org, sxemacs-devel@sxemacs.org, emacs-devel@gnu.org
> 
> I'm ok to move the gnus-doc-ja repo to github or something when
> closing git.gnus.org.

Why cannot gnus-doc-ja be part of Emacs as well?

Re: Moving Gnus development to Emacs?

[Xue Fuqiao]

On Thu, Dec 31, 2015 at 8:29 PM, CHENG Gao <chenggao@royau.me> wrote:

> John talked about new trend to move more codes into ELPA.
> Maybe it's THE RIGHT WAY, to make emacs as emacs-core (with only bare
> functions) and all others packges (core as ELPA, third party as Melpa
> etc, or even PPA).

FYI - there were some discussions about this proposal earlier this year:

* https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00212.html
* https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00146.html

IIRC Atom is using this kind of architecture.  It has a really basic
core, and most of its features are available as packages, including some
very "basic" features, like settings-view (similar to `M-x customize' in
Emacs), find-and-replace, status-bar (similar to mode line in Emacs),
tabs (GUI tabs, not the tab character), language modes, etc.

But this approach also has its downside.  See the links above for some
related discussions.

> If package.el becomes APT like, that'll be cool, really cool.

What does this mean?  Command-line tools like `apt', `apt-get' or
`apt-cache' (or `apm' in Atom)?  If so, I think a simple wrapper script
to `emacs --batch' is enough.

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Thu, 31 Dec 2015 22:35:24 +0800
* Also sprach Xue Fuqiao <xfq.free@gmail.com>:

> On Thu, Dec 31, 2015 at 8:29 PM, CHENG Gao <chenggao@royau.me> wrote:
>
>> John talked about new trend to move more codes into ELPA. Maybe it's
>> THE RIGHT WAY, to make emacs as emacs-core (with only bare
>> functions) and all others packges (core as ELPA, third party as
>> Melpa etc, or even PPA).
>
> FYI - there were some discussions about this proposal earlier this
> year:
>
> * https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00212.html
> * https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00146.html
>
> IIRC Atom is using this kind of architecture. It has a really basic
> core, and most of its features are available as packages, including
> some very "basic" features, like settings-view (similar to `M-x
> customize' in Emacs), find-and-replace, status-bar (similar to mode
> line in Emacs), tabs (GUI tabs, not the tab character), language
> modes, etc.
>
> But this approach also has its downside. See the links above for some
> related discussions.

Thanks for the info. Yes I know Atom does this, and also VS Code recently.

>> If package.el becomes APT like, that'll be cool, really cool.
>
> What does this mean? Command-line tools like `apt', `apt-get' or
> `apt-cache' (or `apm' in Atom)? If so, I think a simple wrapper script
> to `emacs --batch' is enough.

I don't mean this. Sorry for my ambiguous expression.
Mainly I mean package.el can do dependency check and install proper
dependent packages. Also can handle different Emacs versions since
packages may stop supporting some Emacs versions or not yet catch up with
latest version. But it may be too complicated.

Re: Moving Gnus development to Emacs?

[Uwe Brauer]

>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

   > (Excuse the crossposting.)

[...]


   > 1) is not true any more.  And XEmacs isn't as vital as it used to be.

I see, you left xemacs-beta out in your newsgroup field...


   > So: I want to know how all y'all would feel if I closed
   > git.gnus.org and started bringing the Gnus code base in the Emacs
   > trunk up to modern Emacs standards. That would mean removing
   > basically all compat code.

Although I switched mostly to GNU emacs, that decision is a bit sad.
Could you at least tag the last Xemacs compat version, before removing
that code?

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

> No objections from me (I'm currently doing the same for CEDET, for
> pretty much the same reasons), but just to clarify: this means that we
> only care about the current Emacs version and do not do separate
> releases anymore?

Yup.

> I'm mostly worried about how this will affect the T-shirt release
> process.

I could still do code words and t-shirts.  Even though it's be cheating
slightly.  :-)

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

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Uwe Brauer <oub@mat.ucm.es> writes:

> Although I switched mostly to GNU emacs, that decision is a bit sad.
> Could you at least tag the last Xemacs compat version, before removing
> that code?

I'll do one final release before closing git.gnus.org.  If that's what I
decide to do.  :-)

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

Re: Moving Gnus development to Emacs?

[Xue Fuqiao]

On Thu, Dec 31, 2015 at 10:52 PM, CHENG Gao <chenggao@royau.me> wrote:

>>> If package.el becomes APT like, that'll be cool, really cool.
>>
>> What does this mean? Command-line tools like `apt', `apt-get' or
>> `apt-cache' (or `apm' in Atom)? If so, I think a simple wrapper script
>> to `emacs --batch' is enough.
>
> I don't mean this. Sorry for my ambiguous expression.
> Mainly I mean package.el can do dependency check and install proper
> dependent packages. Also can handle different Emacs versions since
> packages may stop supporting some Emacs versions or not yet catch up with
> latest version. But it may be too complicated.

Thanks for the clarification.

Although I'm not quite familiar with both package.el and APT, AIUI
package.el can already do dependency check and handle different Emacs
versions.  You can use the "Package-Requires" header, for example:

   ;; Package-Requires: ((emacs "24.1") (cl-lib "0.5") (async "1.6"))

In Emacs 25, you can also use the command `package-autoremove' to remove
all packages which were installed strictly as dependencies but are no
longer needed, similar to `apt-get autoremove'.

Maybe I'm missing something, would you please explain?

PS: perhaps we should change the subject line of this subthread.

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Fri, 1 Jan 2016 08:10:34 +0800
* Also sprach Xue Fuqiao <xfq.free@gmail.com>:

> On Thu, Dec 31, 2015 at 10:52 PM, CHENG Gao <chenggao@royau.me> wrote:
>
>>>> If package.el becomes APT like, that'll be cool, really cool.
>>> What does this mean? Command-line tools like `apt', `apt-get' or
>>> `apt-cache' (or `apm' in Atom)? If so, I think a simple wrapper
>>> script to `emacs --batch' is enough.
>> I don't mean this. Sorry for my ambiguous expression. Mainly I mean
>> package.el can do dependency check and install proper dependent
>> packages. Also can handle different Emacs versions since packages
>> may stop supporting some Emacs versions or not yet catch up with
>> latest version. But it may be too complicated.
>
> Thanks for the clarification.
>
> Although I'm not quite familiar with both package.el and APT, AIUI
> package.el can already do dependency check and handle different Emacs
> versions. You can use the "Package-Requires" header, for example:
>
>    ;; Package-Requires: ((emacs "24.1") (cl-lib "0.5") (async "1.6"))
>
> In Emacs 25, you can also use the command `package-autoremove' to
> remove all packages which were installed strictly as dependencies but
> are no longer needed, similar to `apt-get autoremove'.
>
> Maybe I'm missing something, would you please explain?
>
> PS: perhaps we should change the subject line of this subthread.

Thanks for your detailed explanation. Good to know.
I read all posts in URLs you gave, and some others about use-package and
req-package etc. Seems future is expectable.

PS: Or I just stop here, be quiet and learn more.

Re: Moving Gnus development to Emacs

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

>   > That would mean removing basically all compat code.
>
> OK, from where I sit, this would totally suck. :-(  And anyone not
> wanting to use dev Emacs would just have to put it all back in.
>
> Any chance I could talk you out of it?  Is there a compromise?  Would it
> be possible/acceptable to leave in the existing compat code but not
> update it or use it for any new features from this point on? (I realise
> this wouldn't be possible every time)

Having different programming styles in the same functions is just
awkward.  One talks about `gnus-union' and the other talks about
`cl-union' (or whatever).  Somebody who tries to fix a bug will have to
examine `gnus-union' to see whether it does something weird, and then
discover that it's just the normal `cl-union'.

It's doable, of course, but it's not very readable.

> I don't mind having to bring my own glue to get the lastest and greatest
> shiny new feature working, but I don't want to glue stuff that has been
> working fine for me for the last 15 to 20 years.

Well, Gnus will still be working for you, but new features will have to
be ported gingerly, I'm afraid...

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

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

After the discussion here, I think I've decided to move Gnus development
to Emacs and Emacsify the code for greater readability.

If {S,}XEmacs wants to keep tracking Gnus development, this
unfortunately means that the onus is on the {S,}XEmacs maintainers to
add an ever-growing number of Emacs compat functions, and expand
function call lists to keep up with Emacs function call lists.

(As well as adding seq/map/cllib/etc.)

The major stumbling block is, of course, lexical binding, but we'll see
how much of that creeps into Gnus after a while.  Gnus is quite async in
some respects, and having proper closures makes that a lot more
readable, but on the other hand, Gnus (ab)uses dynamic scope
extensively, so...

I wrote up the decision here, with added images:

http://lars.ingebrigtsen.no/2016/01/01/its-about-ethics-in-gnus-development/

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

Re: Moving Gnus development to Emacs?

[Bill Wohler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> After the discussion here, I think I've decided to move Gnus development
> to Emacs and Emacsify the code for greater readability.

We moved MH-E to Emacs a few years ago. One welcome consequence of this
is that we have had more developers improving the code.

Lars, will you continue to have separate Gnus version numbers? Will you
move the bug tracker?

MH-E still maintains separate version numbers and we're still using
SourceForge for our bug tracking and a Git repository for MH-E files
that may not be appropriate for the Emacs repository (contrib, Debian
files, maintainers guide, web pages, tests, files for independent MH-E
releases).

Have you also considered moving Gnus to ELPA someday?

> If {S,}XEmacs wants to keep tracking Gnus development, this
> unfortunately means that the onus is on the {S,}XEmacs maintainers to
> add an ever-growing number of Emacs compat functions, and expand
> function call lists to keep up with Emacs function call lists.

We still have a small file with compatibility functions for older
Emacsen and XEmacs. It would be better if XEmacs provided the
compatibility so each package wouldn't have to.

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Bill Wohler <wohler@newt.com> writes:

> Lars, will you continue to have separate Gnus version numbers? Will you
> move the bug tracker?

Gnus doesn't really have a bug tracker, per se, but just a Gnus bug
mailing list.  I won't be closing that address, but I'll be removing the
`gnus-bug' command and tell people to report all Gnus bugs with `M-x
report-emacs-bug' (which is how the majority of Gnus bugs are reported
today, anyway).

I think I'll have to keep doing Gnus version numbers -- otherwise, how
can I do t-shirts?

> Have you also considered moving Gnus to ELPA someday?

I think it's nice that Gnus just "is there" in Emacs...

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

Re: Moving Gnus development to Emacs?

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think I'll have to keep doing Gnus version numbers -- otherwise, how can I
> do t-shirts?

I still have my Gnus mug from 1998.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Moving Gnus development to Emacs?

[Steve Youngs]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  > After the discussion here, I think I've decided to move Gnus development
  > to Emacs and Emacsify the code for greater readability.

Are you going to keep git.gnus.org live for a period of time after the
move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?
Also, it'd be very much appreciated if you could let me know when the
last commit goes in at git.gnus.org.

  > If {S,}XEmacs wants to keep tracking Gnus development, this
  > unfortunately means that the onus is on the {S,}XEmacs maintainers to
  > add an ever-growing number of Emacs compat functions, and expand
  > function call lists to keep up with Emacs function call lists.

  > (As well as adding seq/map/cllib/etc.)

Yep, working on it. :)

  > The major stumbling block is, of course, lexical binding, but we'll see
  > how much of that creeps into Gnus after a while.  Gnus is quite async in
  > some respects, and having proper closures makes that a lot more
  > readable, but on the other hand, Gnus (ab)uses dynamic scope
  > extensively, so...

Gnus is far from unique in that (ab)use, even my own code does it a lot
more than I'd care to admit to.  But yeah, lexical scope is well and
truly on the SXEmacs radar.  Might have to bump it up a few notches on
the todo list. :-)

  > I wrote up the decision here, with added images:

  > http://lars.ingebrigtsen.no/2016/01/01/its-about-ethics-in-gnus-development/

It must be true, there's cats and memes involved.

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
|         Fill in the blank, yes, it's THAT good!          |
|------------------------------------<steve@sxemacs.org>---|

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

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

> Are you going to keep git.gnus.org live for a period of time after the
> move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?

Sure.  There's probably some way to switch it to read-only, I guess?

> Also, it'd be very much appreciated if you could let me know when the
> last commit goes in at git.gnus.org.

Will do.

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

Re: Moving Gnus development to Emacs?

[CHENG Gao]

*On Wed, 06 Jan 2016 08:18:19 +0100
* Also sprach Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steve Youngs <steve@sxemacs.org> writes:
>
>> Are you going to keep git.gnus.org live for a period of time after the
>> move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?
>
> Sure.  There's probably some way to switch it to read-only, I guess?
>
>> Also, it'd be very much appreciated if you could let me know when the
>> last commit goes in at git.gnus.org.
>
> Will do.

Maybe have a new release and then move to ELPA.

By convention it should be a "lgnus. "Last" for "l" comes to my mind
irresistably.

Re: Moving Gnus development to Emacs?

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steve Youngs <steve@sxemacs.org> writes:
>
>> Are you going to keep git.gnus.org live for a period of time after the
>> move so us slow-coaches can grab the last of the (S)XEmacs capable Gnus?
>
> Sure.  There's probably some way to switch it to read-only, I guess?

If you swich off all authenticated access then nobody will be able to
push any more.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving Gnus development to Emacs?

[Ted Zlatanov]

On Sat, 02 Jan 2016 18:39:46 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> After the discussion here, I think I've decided to move Gnus development
LMI> to Emacs and Emacsify the code for greater readability.

Sorry for the late comment here, but I'm in favor.

Ted

Re: Moving Gnus development to Emacs?

[Greg Troxel]

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


Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> After the discussion here, I think I've decided to move Gnus development
> to Emacs and Emacsify the code for greater readability.

I see your point, but I think it's really unfortunate to not maintain
compatibility for at least the current actual release of emacs.  I
really don't like to run development snapshots of most things -- only a
few things that I decide it's worth the stability risk.  So basically
I'm suggesting maintaining compat for emacs 24 now, and when 25 is
released, maintaining 25 compat on the head of development.

This will make it easier for more people to track gnus development,
which I think will help gnus.


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