gnus-summary-refer-parent-article bug

gnus-summary-refer-parent-article bug

[Dave Abrahams]

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


When gnus-summary-refer-parent-article is invoked on some articles, I
keep getting this backtrace:


[-- Attachment #2: BOOM --]
[-- Type: application/emacs-lisp, Size: 15526 bytes --]

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


Does anyone know what's up here?

TIA,
Dave

Re: gnus-summary-refer-parent-article bug

[Alan Schmitt]

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

On 2016-01-17 23:26, Dave Abrahams <dave@boostpro.com> writes:

> When gnus-summary-refer-parent-article is invoked on some articles, I
> keep getting this backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   =(nil 32)

I think this is the same bug I reported a couple weeks ago:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353
http://thread.gmane.org/gmane.emacs.gnus.general/86583

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 17, 2016, Mauna Loa Obs.): 402.86 ppm

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

Re: gnus-summary-refer-parent-article bug

[Dave Abrahams]

on Mon Jan 18 2016, Alan Schmitt <alan.schmitt-AT-polytechnique.org> wrote:

> On 2016-01-17 23:26, Dave Abrahams <dave@boostpro.com> writes:
>
>> When gnus-summary-refer-parent-article is invoked on some articles, I
>> keep getting this backtrace:
>>
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>   =(nil 32)
>
> I think this is the same bug I reported a couple weeks ago:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353
> http://thread.gmane.org/gmane.emacs.gnus.general/86583

You're quite right; thanks for working out the fix, too!

-Dave

Re: gnus-summary-refer-parent-article bug

[Katsumi Yamaoka]

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

On Mon, 18 Jan 2016 07:47:46 -0800, Dave Abrahams wrote:
> on Mon Jan 18 2016, Alan Schmitt <alan.schmitt-AT-polytechnique.org> wrote:
>> I think this is the same bug I reported a couple weeks ago:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353
>> http://thread.gmane.org/gmane.emacs.gnus.general/86583

> You're quite right; thanks for working out the fix, too!

Could you try the patch below?  Probably this is the right fix
because:

,---- (info "(gnus)Optional Back End Functions")
|‘(nnchoke-request-update-mark GROUP ARTICLE MARK)’
|
|     If the user tries to set a mark that the back end doesn’t like,
|     this function may change the mark.  Gnus will use whatever this
|     function returns as the mark for ARTICLE instead of the original
|     MARK.
|     If the back end doesn’t care, it must return the original MARK,
|     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     and not ‘nil’ or any other type of garbage.
|     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     The only use for this I can see is what ‘nnvirtual’ does with it—if
|     a component group is auto-expirable, marking an article as read in
|     the virtual group should result in the article being marked as
|     expirable.
|
|     There should be no result data from this function.
`----


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 584 bytes --]

--- nnir.el~	2016-01-04 22:05:27.318335700 +0000
+++ nnir.el	2016-01-19 00:24:05.129707800 +0000
@@ -822,8 +822,10 @@
 (deffoo nnir-request-update-mark (group article mark)
   (let ((artgroup (nnir-article-group article))
 	(artnumber (nnir-article-number article)))
-    (when (and artgroup artnumber)
-      (gnus-request-update-mark artgroup artnumber mark))))
+    (or (and artgroup
+	     artnumber
+	     (gnus-request-update-mark artgroup artnumber mark))
+	mark)))
 
 (deffoo nnir-request-set-mark (group actions &optional server)
   (nnir-possibly-change-group group server)

Re: gnus-summary-refer-parent-article bug

[Dave Abrahams]

on Mon Jan 18 2016, Katsumi Yamaoka <yamaoka-AT-jpl.org> wrote:

> On Mon, 18 Jan 2016 07:47:46 -0800, Dave Abrahams wrote:
>> on Mon Jan 18 2016, Alan Schmitt <alan.schmitt-AT-polytechnique.org> wrote:
>>> I think this is the same bug I reported a couple weeks ago:
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353
>>> http://thread.gmane.org/gmane.emacs.gnus.general/86583
>
>> You're quite right; thanks for working out the fix, too!
>
> Could you try the patch below?  Probably this is the right fix
> because:
>
> ,---- (info "(gnus)Optional Back End Functions")
> |‘(nnchoke-request-update-mark GROUP ARTICLE MARK)’
> |
> |     If the user tries to set a mark that the back end doesn’t like,
> |     this function may change the mark.  Gnus will use whatever this
> |     function returns as the mark for ARTICLE instead of the original
> |     MARK.
> |     If the back end doesn’t care, it must return the original MARK,
> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |     and not ‘nil’ or any other type of garbage.
> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |     The only use for this I can see is what ‘nnvirtual’ does with it—if
> |     a component group is auto-expirable, marking an article as read in
> |     the virtual group should result in the article being marked as
> |     expirable.
> |
> |     There should be no result data from this function.
> `----
>
> --- nnir.el~	2016-01-04 22:05:27.318335700 +0000
> +++ nnir.el	2016-01-19 00:24:05.129707800 +0000
> @@ -822,8 +822,10 @@
>  (deffoo nnir-request-update-mark (group article mark)
>    (let ((artgroup (nnir-article-group article))
>  	(artnumber (nnir-article-number article)))
> -    (when (and artgroup artnumber)
> -      (gnus-request-update-mark artgroup artnumber mark))))
> +    (or (and artgroup
> +	     artnumber
> +	     (gnus-request-update-mark artgroup artnumber mark))
> +	mark)))
>
>  (deffoo nnir-request-set-mark (group actions &optional server)
>    (nnir-possibly-change-group group server)

Seems to work OK, thanks

-Dave

Re: gnus-summary-refer-parent-article bug

[Katsumi Yamaoka]

On Tue, 19 Jan 2016 07:59:21 -0800, Dave Abrahams <dave@boostpro.com> wrote:
> Seems to work OK, thanks

Thanks for verifying.  Committed to the emacs-25 branch.

Re: gnus-summary-refer-parent-article bug

[Alan Schmitt]

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

Hello,

On 2016-01-20 07:10, Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Tue, 19 Jan 2016 07:59:21 -0800, Dave Abrahams <dave@boostpro.com> wrote:
>> Seems to work OK, thanks
>
> Thanks for verifying.  Committed to the emacs-25 branch.

Thanks a lot for this patch. Did you push the branch? I cannot see it
here http://git.gnus.org/cgit/gnus.git/log/, and I would like to use it.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 18, 2016, Mauna Loa Obs.): 402.66 ppm

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

Re: gnus-summary-refer-parent-article bug

[Katsumi Yamaoka]

On Wed, 20 Jan 2016 12:04:37 +0100, Alan Schmitt wrote:
> Thanks a lot for this patch. Did you push the branch? I cannot see it
> here http://git.gnus.org/cgit/gnus.git/log/, and I would like to use it.

Sorry, I'll never modify the Gnus git repo any more (except for
an irregular case) honoring Lars' message:

<http://thread.gmane.org/gmane.emacs.devel/197168>

The latest Gnus is in the emacs-25 branch of the Emacs git repo
now; it will be merged to the Emacs trunk sooner or later.

Regards,

Re: gnus-summary-refer-parent-article bug

[Katsumi Yamaoka]

On Thu, 21 Jan 2016 08:04:35 +0900, Katsumi Yamaoka wrote:
> The latest Gnus is in the emacs-25 branch of the Emacs git repo
> now; it will be merged to the Emacs trunk sooner or later.

FYI.  Things that have not yet been merged from the emacs-25
branch to the trunk at this time are in:

http://www.jpl.org/ftp/pub/tmp/MaGnus-to-Emacs-trunk-unfinished.patch

Re: gnus-summary-refer-parent-article bug

[Eric Abrahamsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Thu, 21 Jan 2016 08:04:35 +0900, Katsumi Yamaoka wrote:
>> The latest Gnus is in the emacs-25 branch of the Emacs git repo
>> now; it will be merged to the Emacs trunk sooner or later.
>
> FYI.  Things that have not yet been merged from the emacs-25
> branch to the trunk at this time are in:
>
> http://www.jpl.org/ftp/pub/tmp/MaGnus-to-Emacs-trunk-unfinished.patch

So git.gnus.org is already abandoned? It should probably be set
read-only, then -- I didn't realize we'd already made the shift...

Re: gnus-summary-refer-parent-article bug

[Alan Schmitt]

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

On 2016-01-21 08:04, Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Wed, 20 Jan 2016 12:04:37 +0100, Alan Schmitt wrote:
>> Thanks a lot for this patch. Did you push the branch? I cannot see it
>> here http://git.gnus.org/cgit/gnus.git/log/, and I would like to use it.
>
> Sorry, I'll never modify the Gnus git repo any more (except for
> an irregular case) honoring Lars' message:
>
> <http://thread.gmane.org/gmane.emacs.devel/197168>
>
> The latest Gnus is in the emacs-25 branch of the Emacs git repo
> now; it will be merged to the Emacs trunk sooner or later.

Ah. Is it possible to upgrade gnus without waiting for emacs 25? The
only instructions I could find to use the latest gnus use the obsolete
repository.

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 20, 2016, Mauna Loa Obs.): 402.30 ppm

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

Re: Moving Gnus development to Emacs?

[Katsumi Yamaoka]

On Thu, 21 Jan 2016 11:21:06 +0100, Alan Schmitt wrote:
> Ah. Is it possible to upgrade gnus without waiting for emacs 25? The
> only instructions I could find to use the latest gnus use the obsolete
> repository.

Ok, for the moment I've made the Gnus git repo up-to-date except
for tls.el[1].  Could you test it?

Lars, I can synch the Gnus git repo and the Emacs git repo until
the next (the last?) Gnus release.  Is it ok?

[1] In Emacs, tls.el requires gnutls.el of the bleeding-edge.

Re: Moving Gnus development to Emacs?

[Alan Schmitt]

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

On 2016-01-22 11:37, Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Thu, 21 Jan 2016 11:21:06 +0100, Alan Schmitt wrote:
>> Ah. Is it possible to upgrade gnus without waiting for emacs 25? The
>> only instructions I could find to use the latest gnus use the obsolete
>> repository.
>
> Ok, for the moment I've made the Gnus git repo up-to-date except
> for tls.el[1].  Could you test it?

I could pull this version, and I confirm it fixes my problem. I guess
I should close the bug report I opened about this
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353). What is the
correct way to do it? Should I reference the commit hash?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 20, 2016, Mauna Loa Obs.): 402.30 ppm

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

Re: Moving Gnus development to Emacs?

[Katsumi Yamaoka]

On Fri, 22 Jan 2016 08:53:15 +0100, Alan Schmitt wrote:
> I guess I should close the bug report I opened about this
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353). What is the
> correct way to do it? Should I reference the commit hash?

Send a mail to <22353-done@@debbugs.gnu.org> with a short comment.

BTW, why I'm unable to find the bug#22353 thread in the news group
gmane.emacs.bugs?

Re: Moving Gnus development to Emacs?

[Michael Albinus]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> BTW, why I'm unable to find the bug#22353 thread in the news group
> gmane.emacs.bugs?

Because it belongs to the package "gnus" instead of package "emacs".

Best regards, Michael.

Re: Moving Gnus development to Emacs?

[Alan Schmitt]

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

On 2016-01-22 18:45, Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Fri, 22 Jan 2016 08:53:15 +0100, Alan Schmitt wrote:
>> I guess I should close the bug report I opened about this
>> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22353). What is the
>> correct way to do it? Should I reference the commit hash?
>
> Send a mail to <22353-done@@debbugs.gnu.org> with a short comment.

Thank you, I just did that.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 20, 2016, Mauna Loa Obs.): 402.30 ppm

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

Re: Moving Gnus development to Emacs?

[Katsumi Yamaoka]

On Fri, 22 Jan 2016 12:28:37 +0100, Michael Albinus wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> BTW, why I'm unable to find the bug#22353 thread in the news group
>> gmane.emacs.bugs?

> Because it belongs to the package "gnus" instead of package "emacs".

Ah, I see.  Thanks.  I found it in the page
<http://debbugs.gnu.org/db/si/donenormal.html>
and also:
<http://debbugs.gnu.org/db/si/pendingnormal.html>
<http://debbugs.gnu.org/db/si/forwardednormal.html>

But many of them will likely be left unseen, so a better way for
at least Gnus would be to post it here or as an Emacs bug, I think.

Re: Moving Gnus development to Emacs?

[Katsumi Yamaoka]

On Fri, 22 Jan 2016 11:37:04 +0900, Katsumi Yamaoka wrote:
> Lars, I can synch the Gnus git repo and the Emacs git repo until
> the next (the last?) Gnus release.  Is it ok?

On Wed, 30 Dec 2015 12:43:12 +0100, Lars Magne Ingebrigtsen wrote:
> Emacs has developed rapidly during the last few years,

It's not a matter for me who build Emacs as a daily routine.  It
takes only several minutes.  Though it sometimes stops my work
with a sudden bug.  But no matter what, the most troublesome for
me is to tweak Gnus so as to work with old Emacsen.

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

Keeping the backward compatibility of Gnus for old Emacsen is
not only troublesome but also it will lower the Gnus performance.
If you don't want to put up with bugs till the next Emacs release
what I do would be one of ways.

Regards,

Re: Moving Gnus development to Emacs?

[Mike Kupfer]

Katsumi Yamaoka wrote:

> But many of them will likely be left unseen, so a better way for
> at least Gnus would be to post it here or as an Emacs bug, I think.

Hmm, I used

  M-x gnus-bug

back in December to file #22157.  It went to debbugs.gnu.org under the
"gnus" package.  If bug reports should go somewhere else, gnus-bug
should be changed to do the right thing.

cheers,
mike

Re: Moving Gnus development to Emacs?

[Katsumi Yamaoka]

On Sun, 24 Jan 2016 17:58:11 -0800, Mike Kupfer wrote:
> Katsumi Yamaoka wrote:
>> But many of them will likely be left unseen, so a better way for
>> at least Gnus would be to post it here or as an Emacs bug, I think.

> Hmm, I used

>   M-x gnus-bug

> back in December to file #22157.  It went to debbugs.gnu.org under the
> "gnus" package.  If bug reports should go somewhere else, gnus-bug
> should be changed to do the right thing.

Otherwise, reports should appear in a gmane newsgroup (or a
mailing list).

Re: Moving Gnus development to Emacs?

[Alan Schmitt]

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

On 2016-01-24 17:58, Mike Kupfer <m.kupfer@acm.org> writes:

> Katsumi Yamaoka wrote:
>
>> But many of them will likely be left unseen, so a better way for
>> at least Gnus would be to post it here or as an Emacs bug, I think.
>
> Hmm, I used
>
>   M-x gnus-bug
>
> back in December to file #22157.  It went to debbugs.gnu.org under the
> "gnus" package.  If bug reports should go somewhere else, gnus-bug
> should be changed to do the right thing.

This is also what I did for this bug.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 24, 2016, Mauna Loa Obs.): 402.49 ppm

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

Re: Moving Gnus development to Emacs?

[Lars Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Thu, 21 Jan 2016 11:21:06 +0100, Alan Schmitt wrote:
>> Ah. Is it possible to upgrade gnus without waiting for emacs 25? The
>> only instructions I could find to use the latest gnus use the obsolete
>> repository.
>
> Ok, for the moment I've made the Gnus git repo up-to-date except
> for tls.el[1].  Could you test it?
>
> Lars, I can synch the Gnus git repo and the Emacs git repo until
> the next (the last?) Gnus release.  Is it ok?

I forgot to answer, but yes please.  :-)  But now the last Gnus release
has been done, and I've made the repo read-only (I think).

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

Re: Moving Gnus development to Emacs?

[Adam Sjøgren]

Lars writes:

> I forgot to answer, but yes please.  :-)  But now the last Gnus release
> has been done, and I've made the repo read-only (I think).

I think you may have made it a little too read-only:

  $ git pull --rebase
  fatal: unable to access 'https://git.gnus.org/gnus.git/': The requested URL returned error: 500
  $ 


  Best regards,

    Adam

-- 
 "I am still twitching at the idea that you need to           Adam Sjøgren
  load code into the kernel in order to re-map a         asjo@koldfront.dk
  mouse button."

Re: Moving Gnus development to Emacs?

[Adam Sjøgren]

Adam writes:

> I think you may have made it a little too read-only:

Never mind, just pull from http instead of https, and it's fine.


  Best regards,

    Adam

-- 
 "Eternal evil                                                Adam Sjøgren
  Yeah it stares behind the desk"                        asjo@koldfront.dk

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

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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@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.

(FWIW this would be much easier for the {S,}XEmacs mainainers, if they
could do this on a separate branch in the Gnus repository.  It would be
the same lisp code issues but less git hassle...)

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?

[Göktuğ Kayaalp]

On Thu, Dec 31 2015 at 12:15:32 PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> 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.
>>
>> No more `mm-string-as-unibyte'.  No more `gnus-invisible-p'.  Freedom!
> How much more work would it be to keep the external repo, but split the
> different versions into different branches? Ie, an "emacs-master" branch
> (which gets bundled into Emacs releases), an "Xemacs" branch, and an
> "SXEmacs" branch (whatever that is).
> […]

Hi all, I'm a n00b to the list,  however I wanted to add my two cents to
the discussion.  Sorry if I say sth. silly.

If my memory is  good enough, I recall the new  GNU Emacs maintainer say
on a  recent interview [1] that  he wish to « modularise »  Emacs source
tree, i.e. move non-essential bits to their own projects.

I think vanilla  emacs bundles too many things, so  I back such attempt.
Installing packages in Emacs is very  easy today, one command is enough.
No need to bundle tetris, doctor,  etc., nor Org and Gnus.  Abrahamsen's
suggestion of branches seems good.  Alternatively, given that many Emacs
modules  begin   with  a  suit   of  /polyfills/,  maybe   a  standalone
/backports.el/ module should be created, so  that all the Elisp devs can
target  only  the  latest  release  without guilt.   Also  Gnus  can  be
developed  that way,  without  need to  maintain  /ports/ for  different
emacsen,  should a  good common  backports package  be available.   Gnus
releases target  the latest GNU  Emacs release,  and users of  older GNU
versions and  other emacsen  maintain the backports  package to  get the
cool  stuff.   This would  help  all  the  Emacs community.   Maybe  the
possiblity of this should be discussed on emacs-tangents.

[1] Sacha Chua's Emacs Chat with John Wiegley
    Video: <https://www.youtube.com/watch?v=nUjgKoOYxos>

All the best,
-gk

-- 
İ. Göktuğ Kayaalp.
http://gkayaalp.com/

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?

[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?

[Benjamin Slade]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Jay Belanger <jay.p.belanger@gmail.com> writes:
>> And these two issues can be dealt with regardless of where the Gnus
>> development occurs; moving it to the Emacs trunk means only people 
>> running git Emacs can use/work on the latest Gnus.
>
> True, but building git Emacs is so ridiculously easy on modern GNU/Linux
> systems that that's what I'd recommend anyway:
>
> $ sudo apt-get build-dep emacs24
> $ git clone git://git.savannah.gnu.org/emacs.git
> $ cd emacs
> $ make
>
> That's less work than fetching Gnus, compiling and adjusting
> `load-path'...

I end up not running git Emacs myself because there end up being lots of
bits that don't work. But it's nice to be able to run git versions of
particular packages (like Gnus).

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> That way everyone can be responsible for keeping their own version of
> Gnus working with their own project, and can drop compatibility with
> other people's projects. It's not like Gnus development is roaring ahead
> at such a pace that the various branches are going to get significantly
> left behind, right?

It requires that somebody does the job, though.  I think that probably
the SXEmacs people are up to it, and that's probably what they're going
to do.

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

Re: Moving Gnus development to Emacs?

[Lars Magne Ingebrigtsen]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> Not including new compat code is one thing, but why remove what is
> already there?

It's a maintainability issue.  You kinda have to be a Gnus expert to fix
even rather trivial bugs in Gnus now because there's so much
back-and-forth between various compat functions that (sometimes) vaguely
do not work as you'd expect.

> How is the Gnus code base not up to modern standards?

`when-let', seq-*, `pcase', cllib, and of course the big incompatible
thing that's difficult to fix with compat functions: Lexical binding.

> And these two issues can be dealt with regardless of where the Gnus
> development occurs; moving it to the Emacs trunk means only people 
> running git Emacs can use/work on the latest Gnus.

True, but building git Emacs is so ridiculously easy on modern GNU/Linux
systems that that's what I'd recommend anyway:

$ sudo apt-get build-dep emacs24
$ git clone git://git.savannah.gnu.org/emacs.git
$ cd emacs
$ make

That's less work than fetching Gnus, compiling and adjusting
`load-path'...

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

Re: Moving Gnus development to Emacs?

[Adam Sjøgren]

Lars writes:

> David Engster <deng@randomsample.de> writes:

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

Protest! It most certainly would not be. At all. Ahem.


  Not biased,

    Adam

-- 
 "God must've been punting angels left and right."            Adam Sjøgren
                                                         asjo@koldfront.dk

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?

[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?

[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?

[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?

[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?

[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?

[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?

[Eric Abrahamsen]

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

> (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!

How much more work would it be to keep the external repo, but split the
different versions into different branches? Ie, an "emacs-master" branch
(which gets bundled into Emacs releases), an "Xemacs" branch, and an
"SXEmacs" branch (whatever that is).

That way everyone can be responsible for keeping their own version of
Gnus working with their own project, and can drop compatibility with
other people's projects. It's not like Gnus development is roaring ahead
at such a pace that the various branches are going to get significantly
left behind, right?

I'm probably letting my Git-ignorance show, but it seems like a single
independent repo where various people maintain their various branches
might end up being the cleanest solution.

E

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?

[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?

[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?

[Nikolaus Rath]

On Dec 30 2015, Jay Belanger <jay.p.belanger@gmail.com> wrote:
> Not including new compat code is one thing, but why remove what is
> already there?

Because it makes it way easier for people new to the code to contribute.

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?

[Jay Belanger]

raman <raman@google.com> writes:
...
> This would be nice!> (Excuse the crossposting.)

Why?

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

These are three different issues, right?

Not including new compat code is one thing, but why remove what is
already there?

How is the Gnus code base not up to modern standards?  Why would 
bring it up to snuff require removing compat code?

And these two issues can be dealt with regardless of where the Gnus
development occurs; moving it to the Emacs trunk means only people 
running git Emacs can use/work on the latest Gnus.

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?

[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!

-- 

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