Gnus bugfixing is broken.

Gnus bugfixing is broken.

[David Kastrup]

I've used M-x gnus-bug RET to report a bug to bugs@gnus.org, and while
it appears on the local group gnus-bugs (?) on the NNTP server at
news.gnus.org along with several other threads, it would appear that
those other threads have been injected automatically by other channels
(apparently a bug reporting system, since the subject lines contain bug
numbers).

It does not appear like the bug channel fed directly by the gnus-bug
command is actually being read by anybody.

It has now been about two weeks that message-yank-original has stopped
being functional for installations that don't have cl loaded permanently
(namely standard Emacs installations).

Could you please make gnus-bug report somewhere else than what amounts
to /dev/null?  There is nothing to be gained by sabotaging bug reports.

Thanks.

-- 
David Kastrup

Re: Gnus bugfixing is broken.

[Lars Magne Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> It does not appear like the bug channel fed directly by the gnus-bug
> command is actually being read by anybody.

I read it daily.  But I've been busy, so I haven't responded to anything
for a week.

> It has now been about two weeks that message-yank-original has stopped
> being functional for installations that don't have cl loaded permanently
> (namely standard Emacs installations).

You reported it

Date: Tue, 08 Mar 2011 15:26:17 +0100 (6 days, 19 minutes, 18 seconds ago)
Date: Tue, 08 Mar 2011 15:26:17 +0100 (6 days, 19 minutes, 19 seconds ago)
Date: Tue, 08 Mar 2011 15:26:17 +0100 (6 days, 19 minutes, 20 seconds ago)
Date: Tue, 08 Mar 2011 15:26:17 +0100 (6 days, 19 minutes, 21 seconds ago)

to gnus-bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus bugfixing is broken.

[David Kastrup]

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

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

> David Kastrup <dak@gnu.org> writes:
>
>> It does not appear like the bug channel fed directly by the gnus-bug
>> command is actually being read by anybody.
>
> I read it daily.  But I've been busy, so I haven't responded to anything
> for a week.
>
>> It has now been about two weeks that message-yank-original has stopped
>> being functional for installations that don't have cl loaded permanently
>> (namely standard Emacs installations).
>
> You reported it
>
> Date: Tue, 08 Mar 2011 15:26:17 +0100 (6 days, 19 minutes, 18 seconds ago)

"stopped being functional" is not the same as "you reported it".  Sure,
I reported it about a week ago.  It has been several days before that
that it appeared in the upstream git archive of Emacs.  It presumably
has been in Gnus upstream several days before that.

There has been _no_ indication that my report has been read or received
by anybody at all.

The above message by yours is the first such indication (the original
message remains without followup or reply).  It was rather hard to check
for replies/reactions anyway, since the gnus-bug list does not appear on
gmane or other typical mailing list replicators.  One can only look at
news.gnus.org itself.  Finding the information where the gnus bug list
ends up is not easy, either: on
<URL:http://www.gnus.org/resources.html>, you find the sentence

    If you want to report Gnus bugs, you should send them to
    bugs@gnus.org. The bug reports (and responses from the Gnus
    Bugfixing Girls & Boys) can be read from Norway.

The last word in that sentence ("Norway") happens to be a hyperlink with
the news: protocol.  In the unlikely case that your system will resolve
such hyperlinks to your favorite newsreader (an educated guess being
"Gnus"), you'll get there.

Letting your system resolve such links requires a helper application
like


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-url --]
[-- Type: text/x-sh, Size: 72 bytes --]

#!/bin/sh
/usr/local/bin/emacsclient -a "" --eval "(browse-url \"$1\")"

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


installed in your binary path and your system knowing about it.  I
should guess that the ratio of Gnus users for which this is the case is
less than 5%.

So the only visible reaction I get after about a week is a chastisement
for thinking something in the bug reporting process appears to be
broken.

To be honest, I am not exactly convinced otherwise yet.

-- 
David Kastrup

Re: Gnus bugfixing is broken.

[Adam Sjøgren]

On Mon, 14 Mar 2011 16:17:55 +0100, David wrote:

> So the only visible reaction I get after about a week is a chastisement
> for thinking something in the bug reporting process appears to be
> broken.

> To be honest, I am not exactly convinced otherwise yet.

Try looking at it from the other side: You have reported a bug which has
not been fixed within a week, and from that you go directly to declaring
that bugfixing in Gnus in general is broken.

Aren't you taking overgeneralization to a new extreme here?


  Best regards,

    Adam

-- 
 "Money always takes the place of life"                       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Gnus bugfixing is broken.

[Lars Magne Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> To be honest, I am not exactly convinced otherwise yet.

*sad face*

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus bugfixing is broken.

[Sivaram Neelakantan]

On Mon, Mar 14 2011,Adam Sjøgren wrote:

> On Mon, 14 Mar 2011 16:17:55 +0100, David wrote:
>
>> So the only visible reaction I get after about a week is a chastisement
>> for thinking something in the bug reporting process appears to be
>> broken.
>
>> To be honest, I am not exactly convinced otherwise yet.
>
> Try looking at it from the other side: You have reported a bug which has
> not been fixed within a week, and from that you go directly to declaring
> that bugfixing in Gnus in general is broken.
>
> Aren't you taking overgeneralization to a new extreme here?

[snipped 5 lines]

maybe he left out 'bug reporting process *using the suggested email
address* ' is broken.  :-)

Anyways Lars had a looksee, so something is bound to happen.

 sivaram
 -- 

message-yank-original issue (was: Gnus bugfixing is broken.)

[Ted Zlatanov]

On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 

DK> It has now been about two weeks that message-yank-original has stopped
DK> being functional for installations that don't have cl loaded permanently
DK> (namely standard Emacs installations).

I posted a fix on the bug list, can you reply there if it worked?

(In case it gets dropped, the patch is below.)

Ted


diff --git a/lisp/message.el b/lisp/message.el
index 4fa55ef..c939303 100644
--- a/lisp/message.el
+++ b/lisp/message.el
@@ -3792,13 +3792,13 @@ prefix, and don't delete any headers."
 		(goto-char (mark t))
 		(insert-before-markers ?\n)
 		(goto-char pt))))
-	  (case message-cite-reply-position
-	    ('above
+	  (cond
+	    ((eq 'above message-cite-reply-position)
 	     (message-goto-body)
 	     (insert body-text)
 	     (insert (if (bolp) "\n" "\n\n"))
 	     (message-goto-body))
-	    ('below
+	    ((eq 'below message-cite-reply-position)
 	     (message-goto-signature)))
 	  ;; Add a `message-setup-very-last-hook' here?
 	  ;; Add `gnus-article-highlight-citation' here?

Re: message-yank-original issue

[Antoine Levitt]

14/03/11 20:13, Ted Zlatanov
> On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 
>
> DK> It has now been about two weeks that message-yank-original has stopped
> DK> being functional for installations that don't have cl loaded permanently
> DK> (namely standard Emacs installations).
>
> I posted a fix on the bug list, can you reply there if it worked?
>
> (In case it gets dropped, the patch is below.)
>
> Ted
>
>
> diff --git a/lisp/message.el b/lisp/message.el
> index 4fa55ef..c939303 100644
> --- a/lisp/message.el
> +++ b/lisp/message.el
> @@ -3792,13 +3792,13 @@ prefix, and don't delete any headers."
>  		(goto-char (mark t))
>  		(insert-before-markers ?\n)
>  		(goto-char pt))))
> -	  (case message-cite-reply-position
> -	    ('above
> +	  (cond
> +	    ((eq 'above message-cite-reply-position)
>  	     (message-goto-body)
>  	     (insert body-text)
>  	     (insert (if (bolp) "\n" "\n\n"))
>  	     (message-goto-body))
> -	    ('below
> +	    ((eq 'below message-cite-reply-position)
>  	     (message-goto-signature)))
>  	  ;; Add a `message-setup-very-last-hook' here?
>  	  ;; Add `gnus-article-highlight-citation' here?

Woops, this one is my fault. Sorry, I didn't think about that.

Any reason why cl isn't loaded by default, by the way? And is it
considered bad practice for packages to require cl?

Antoine

Re: message-yank-original issue

[Ted Zlatanov]

On Mon, 14 Mar 2011 20:38:06 +0100 Antoine Levitt <antoine.levitt@gmail.com> wrote: 

AL> Woops, this one is my fault. Sorry, I didn't think about that.

Yeah I didn't notice it either.  Is my patch a correct fix?

Also recently users reported on gnu.emacs.help (and I can confirm) that
the cursor in a reply is below the citation line but above the cited
text.  Is that related?  It's funny, I didn't even notice that behavior
until I saw the report...  My fingers took care of the motion on their own.

AL> Any reason why cl isn't loaded by default, by the way? And is it
AL> considered bad practice for packages to require cl?

For non-Gnus code (and message.el recently became a standalone part of
Emacs, loaded without Gnus) it's better to be prudent and stay away from
CL functions and macros.

Ted

Re: message-yank-original issue

[Antoine Levitt]

14/03/11 20:47, Ted Zlatanov
> On Mon, 14 Mar 2011 20:38:06 +0100 Antoine Levitt
> <antoine.levitt@gmail.com> wrote:
>
> AL> Woops, this one is my fault. Sorry, I didn't think about that.
>
> Yeah I didn't notice it either.  Is my patch a correct fix?

I think so, it's functionally equivalent to the old code (I'm always
confused about the = vs eq vs eql vs equal vs equalp bit (do we really
need FIVE subtly different comparison functions?), but both 'equal' and
'eq' are equivalent in this case - although comparison is done with
equal in another part of the code)

>
> Also recently users reported on gnu.emacs.help (and I can confirm) that
> the cursor in a reply is below the citation line but above the cited
> text.  Is that related?  It's funny, I didn't even notice that behavior
> until I saw the report...  My fingers took care of the motion on their
> own.

I'm not sure what you mean. Wasn't this the case before? I always had
this behaviour, and that was part of the motivation for the patch. To be
clear, we're talking about

14/03/11 20:47, Ted Zlatanov
POINT HERE> On Mon, 14 Mar 2011 20:38:06 +0100 Antoine Levitt

right?

Looking at the thread on gnu.emacs.help, it seems to be an user asking
about the option of replying above the quoted text (igniting the troll
with "But normally, we will say hello first, right?" :) ), so I think
what he wants is to set the new variable to 'above.

>
> AL> Any reason why cl isn't loaded by default, by the way? And is it
> AL> considered bad practice for packages to require cl?
>
> For non-Gnus code (and message.el recently became a standalone part of
> Emacs, loaded without Gnus) it's better to be prudent and stay away from
> CL functions and macros.

But what's the rationale behind not loading it as part of the standard
emacs load? Is it a loading time issue? The command

time emacs -nw -Q --eval "(require 'cl)" --eval "(kill-emacs)"

does not appear to be noticeably longer than the same one without cl, on
the two machines I've tried. (but maybe they're both too fast to measure
it)

Re: message-yank-original issue

[Ted Zlatanov]

On Mon, 14 Mar 2011 22:02:03 +0100 Antoine Levitt <antoine.levitt@gmail.com> wrote: 

AL> 14/03/11 20:47, Ted Zlatanov
>> On Mon, 14 Mar 2011 20:38:06 +0100 Antoine Levitt
>> <antoine.levitt@gmail.com> wrote:
>> 
AL> Woops, this one is my fault. Sorry, I didn't think about that.
>> 
>> Yeah I didn't notice it either.  Is my patch a correct fix?

AL> I think so, it's functionally equivalent to the old code (I'm always
AL> confused about the = vs eq vs eql vs equal vs equalp bit (do we really
AL> need FIVE subtly different comparison functions?), but both 'equal' and
AL> 'eq' are equivalent in this case - although comparison is done with
AL> equal in another part of the code)

Heh, yeah, Lisp takes equality very seriously.  Don't forget
`string-equal'.

>> Also recently users reported on gnu.emacs.help (and I can confirm) that
>> the cursor in a reply is below the citation line but above the cited
>> text.  Is that related?  It's funny, I didn't even notice that behavior
>> until I saw the report...  My fingers took care of the motion on their
>> own.

AL> I'm not sure what you mean. Wasn't this the case before? I always had
AL> this behaviour, and that was part of the motivation for the patch. To be
AL> clear, we're talking about

AL> 14/03/11 20:47, Ted Zlatanov
AL> POINT HERE> On Mon, 14 Mar 2011 20:38:06 +0100 Antoine Levitt

AL> right?

Yes.  But maybe I had special code for this...  Never mind me...

AL> Any reason why cl isn't loaded by default, by the way? And is it
AL> considered bad practice for packages to require cl?
>> 
>> For non-Gnus code (and message.el recently became a standalone part of
>> Emacs, loaded without Gnus) it's better to be prudent and stay away from
>> CL functions and macros.

AL> But what's the rationale behind not loading it as part of the standard
AL> emacs load? Is it a loading time issue? The command

AL> time emacs -nw -Q --eval "(require 'cl)" --eval "(kill-emacs)"

AL> does not appear to be noticeably longer than the same one without cl, on
AL> the two machines I've tried. (but maybe they're both too fast to measure
AL> it)

It's been discussed a lot on emacs-devel and even the usage of CL in
general code was discouraged until recently (only cl-macs.el definitions
are OK).  I think CL is not badly needed here so it's hard to justify
it, but if there is a good reason to ask for those functions we will.

Ted

Re: message-yank-original issue

[Michael Welsh Duggan]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> 14/03/11 20:47, Ted Zlatanov:
>
>> For non-Gnus code (and message.el recently became a standalone part of
>> Emacs, loaded without Gnus) it's better to be prudent and stay away from
>> CL functions and macros.
>
> But what's the rationale behind not loading it as part of the standard
> emacs load? Is it a loading time issue? The command
>
> time emacs -nw -Q --eval "(require 'cl)" --eval "(kill-emacs)"
>
> does not appear to be noticeably longer than the same one without cl, on
> the two machines I've tried. (but maybe they're both too fast to measure
> it)

My understanding is that the reason is twofold:

1) The cl functions don't have their own namespace.
2) The cl functions don't follow the same conventions as emacs lisp.
   (Keyword arguments being a good example.

These are what I recall RMS's objections to be, and are not mine.  (I
require cl as the very first non-comment in my .emacs.el.)

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: message-yank-original issue

[Ted Zlatanov]

On Mon, 14 Mar 2011 14:13:15 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 
DK> It has now been about two weeks that message-yank-original has stopped
DK> being functional for installations that don't have cl loaded permanently
DK> (namely standard Emacs installations).

TZ> I posted a fix on the bug list, can you reply there if it worked?

Since I didn't hear back I've pushed this patch.

Ted

Re: message-yank-original issue

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.gnus.general as well.

I hope my Cc to ding is the right channel corresponding to the above
gmane group.

> On Mon, 14 Mar 2011 14:13:15 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 
> DK> It has now been about two weeks that message-yank-original has stopped
> DK> being functional for installations that don't have cl loaded permanently
> DK> (namely standard Emacs installations).
>
> TZ> I posted a fix on the bug list, can you reply there if it worked?
>
> Since I didn't hear back I've pushed this patch.

I am not hourly checking all the channels where I have written about the
lack of response.  And it is not overly likely that other people writing
bug reports will do so either (it is not even easy to figure out for
non-subscribers where those lists are being archived).

At the current point of time, the fix does not appear to have percolated
to the git mirror of Emacs which is what I am using.  I'll probably go
hunting for that patch sometime this day if that does not change and be
reporting back then to wherever I'll find the patch posted.

-- 
David Kastrup

Re: message-yank-original issue

[Ted Zlatanov]

On Tue, 15 Mar 2011 10:48:30 +0100 David Kastrup <dak@gnu.org> wrote: 

DK> Ted Zlatanov <tzz@lifelogs.com> writes:
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.emacs.gnus.general as well.

DK> I hope my Cc to ding is the right channel corresponding to the above
DK> gmane group.

Yes.

>> On Mon, 14 Mar 2011 14:13:15 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>> 
TZ> On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 
DK> It has now been about two weeks that message-yank-original has stopped
DK> being functional for installations that don't have cl loaded permanently
DK> (namely standard Emacs installations).
>> 
TZ> I posted a fix on the bug list, can you reply there if it worked?
>> 
>> Since I didn't hear back I've pushed this patch.

DK> I am not hourly checking all the channels where I have written about the
DK> lack of response.  And it is not overly likely that other people writing
DK> bug reports will do so either (it is not even easy to figure out for
DK> non-subscribers where those lists are being archived).

I didn't mean to chastise or complain, it was just FYI.  I also posted
the patch on the gnus-bug newsgroup/mailing list.  I didn't wait any
longer because it seems like a pretty critical bug for many Emacs users.

DK> At the current point of time, the fix does not appear to have percolated
DK> to the git mirror of Emacs which is what I am using.  I'll probably go
DK> hunting for that patch sometime this day if that does not change and be
DK> reporting back then to wherever I'll find the patch posted.

OK, thank you.

Ted

Re: Gnus bugfixing is broken.

[Ted Zlatanov]

On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 

DK> I've used M-x gnus-bug RET to report a bug to bugs@gnus.org, and while
DK> it appears on the local group gnus-bugs (?) on the NNTP server at
DK> news.gnus.org along with several other threads, it would appear that
DK> those other threads have been injected automatically by other channels
DK> (apparently a bug reporting system, since the subject lines contain bug
DK> numbers).

I think Gnus bugs should be reported directly to the Emacs bug tracker,
as `report-emacs-bug' does.  It's set up to DTRT in most cases.  This
would reduce confusion and make life easier for everyone.

I would also get rid of the gnus-bugs mailing list/newsgroup and the CC
to it from the Emacs bug reports.  bugs@gnus.org can just forward to the
Emacs bug tracker.

Ted

Re: Gnus bugfixing is broken.

[Didier Verna]

Ted Zlatanov <tzz@lifelogs.com> wrote:

> I think Gnus bugs should be reported directly to the Emacs bug
> tracker, as `report-emacs-bug' does. It's set up to DTRT in most
> cases. This would reduce confusion and make life easier for everyone.
>
> I would also get rid of the gnus-bugs mailing list/newsgroup and the
> CC to it from the Emacs bug reports. bugs@gnus.org can just forward to
> the Emacs bug tracker.

  Not sure how, from the political side, reporting Gnus bugs from XEmacs
on the GNU Emacs bug tracker would be seen though.

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: Gnus bugfixing is broken.

[Ted Zlatanov]

On Tue, 15 Mar 2011 14:31:00 +0100 Didier Verna <didier@xemacs.org> wrote: 

dvl> Ted Zlatanov <tzz@lifelogs.com> wrote:
>> I think Gnus bugs should be reported directly to the Emacs bug
>> tracker, as `report-emacs-bug' does. It's set up to DTRT in most
>> cases. This would reduce confusion and make life easier for everyone.
>> 
>> I would also get rid of the gnus-bugs mailing list/newsgroup and the
>> CC to it from the Emacs bug reports. bugs@gnus.org can just forward to
>> the Emacs bug tracker.

dvl>   Not sure how, from the political side, reporting Gnus bugs from XEmacs
dvl> on the GNU Emacs bug tracker would be seen though.

We can ask.  But first Lars must agree or it doesn't matter anyhow.

Ted

Re: Gnus bugfixing is broken.

[Michael Albinus]

Didier Verna <didier@xemacs.org> writes:

>   Not sure how, from the political side, reporting Gnus bugs from XEmacs
> on the GNU Emacs bug tracker would be seen though.

It is not the "GNU Emacs bug tracker". See <http://debbugs.gnu.org>.
Other projects are hosted there as well, like Coreutils and Automake.

Best regards, Michael.

Re: Gnus bugfixing is broken.

[Didier Verna]

Michael Albinus <michael.albinus@gmx.de> wrote:

> Didier Verna <didier@xemacs.org> writes:
>
>>   Not sure how, from the political side, reporting Gnus bugs from XEmacs
>> on the GNU Emacs bug tracker would be seen though.
>
> It is not the "GNU Emacs bug tracker". See <http://debbugs.gnu.org>.
> Other projects are hosted there as well, like Coreutils and Automake.

  Yes, but I think Ted was suggesting to use the "Emacs" project (which
makes sense since Gnus is part of it), not creating a new "Gnus" project.

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: Gnus bugfixing is broken.

[Ted Zlatanov]

On Tue, 15 Mar 2011 15:46:51 +0100 Didier Verna <didier@xemacs.org> wrote: 

dvl> Michael Albinus <michael.albinus@gmx.de> wrote:
>> Didier Verna <didier@xemacs.org> writes:
>> 
>>> Not sure how, from the political side, reporting Gnus bugs from XEmacs
>>> on the GNU Emacs bug tracker would be seen though.
>> 
>> It is not the "GNU Emacs bug tracker". See <http://debbugs.gnu.org>.
>> Other projects are hosted there as well, like Coreutils and Automake.

dvl>   Yes, but I think Ted was suggesting to use the "Emacs" project (which
dvl> makes sense since Gnus is part of it), not creating a new "Gnus" project.

I didn't know we could host Gnus inside the bug tracker as a unique
project until Michael mentioned it.  That seems to me like a good
solution, especially if we can share some bugs between Emacs and Gnus on
the same backend (right now quite a few get reported on the Emacs tracker).

Ted

Re: Gnus bugfixing is broken.

[Michael Albinus]

Didier Verna <didier@xemacs.org> writes:

> Michael Albinus <michael.albinus@gmx.de> wrote:
>
>> Didier Verna <didier@xemacs.org> writes:
>>
>>>   Not sure how, from the political side, reporting Gnus bugs from XEmacs
>>> on the GNU Emacs bug tracker would be seen though.
>>
>> It is not the "GNU Emacs bug tracker". See <http://debbugs.gnu.org>.
>> Other projects are hosted there as well, like Coreutils and Automake.
>
>   Yes, but I think Ted was suggesting to use the "Emacs" project (which
> makes sense since Gnus is part of it), not creating a new "Gnus" project.

IIUC, a bug report belongs to a project by adding the project's name to
the `package' attribute of that bug. There are already bugs which have
set both "emacs" and "gnus"; virtually a project "gnus" does exist
already on that server :-)

The "gnus" project is just not listed on the front page of
debbugs.gnu.org, which would include also mailing addresses and
predefined search masks.

Best regards, Michael.

Re: Gnus bugfixing is broken.

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> dvl>   Not sure how, from the political side, reporting Gnus bugs from XEmacs
> dvl> on the GNU Emacs bug tracker would be seen though.
>
> We can ask.  But first Lars must agree or it doesn't matter anyhow.

Getting rid of `M-x gnus-bug' and just instructing people to use
`M-x report-emacs-bug' instead would make a lot of sense at this point,
I think.

However, as Didier points out, Gnus is also distributed outside of
Emacs.  And I'm not sure whether the Emacs people would appreciate
non-Emacs bug reports that much.

I have no strong feelings about this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: message-yank-original issue

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> For non-Gnus code (and message.el recently became a standalone part of
> Emacs, loaded without Gnus) it's better to be prudent and stay away from
> CL functions and macros.

You can use cl-macs macros in Emacs code (included the Gnus code), but
not the run-time cl.el (and friends) functions.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: message-yank-original issue

[Lars Magne Ingebrigtsen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> But what's the rationale behind not loading it as part of the standard
> emacs load? Is it a loading time issue? The command
>
> time emacs -nw -Q --eval "(require 'cl)" --eval "(kill-emacs)"
>
> does not appear to be noticeably longer than the same one without cl, on
> the two machines I've tried. (but maybe they're both too fast to measure
> it)

It's a political, not a technical issue.  The Emacs maintainers have
historically not favoured Common Lisp, and does not want cl.el to be
loaded unless a user explicitly requests it to be loaded.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: message-yank-original issue

[Ted Zlatanov]

On Tue, 15 Mar 2011 16:29:03 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> For non-Gnus code (and message.el recently became a standalone part of
>> Emacs, loaded without Gnus) it's better to be prudent and stay away from
>> CL functions and macros.

LMI> You can use cl-macs macros in Emacs code (included the Gnus code), but
LMI> not the run-time cl.el (and friends) functions.

I know, but I didn't see a benefit in this specific case.  If you
disagree, go ahead and change it.

Ted

Re: Gnus bugfixing is broken.

[Ted Zlatanov]

On Tue, 15 Mar 2011 16:23:08 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
dvl> Not sure how, from the political side, reporting Gnus bugs from XEmacs
dvl> on the GNU Emacs bug tracker would be seen though.
>> 
>> We can ask.  But first Lars must agree or it doesn't matter anyhow.

LMI> Getting rid of `M-x gnus-bug' and just instructing people to use
LMI> `M-x report-emacs-bug' instead would make a lot of sense at this point,
LMI> I think.

LMI> However, as Didier points out, Gnus is also distributed outside of
LMI> Emacs.  And I'm not sure whether the Emacs people would appreciate
LMI> non-Emacs bug reports that much.

LMI> I have no strong feelings about this.

Since the Gnus code is inside Emacs *and* we get Emacs bug reports
anyhow, I think it makes sense.  Do you want me to ask on emacs-devel or
will you?  It may involve some... heated... discussion.

Ted

Re: message-yank-original issue

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I know, but I didn't see a benefit in this specific case.  If you
> disagree, go ahead and change it.

No, I think using `cond' is better than `case' in most cases (including
this) since more Emacs programmers are familiar with `cond'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus bugfixing is broken.

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Since the Gnus code is inside Emacs *and* we get Emacs bug reports
> anyhow, I think it makes sense.  Do you want me to ask on emacs-devel or
> will you?  It may involve some... heated... discussion.

Go ahead.  And Cc the XEmacs beta list for fun.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus bugfixing is broken.

[Didier Verna]

Lars Magne Ingebrigtsen wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> Since the Gnus code is inside Emacs *and* we get Emacs bug reports
>> anyhow, I think it makes sense.  Do you want me to ask on emacs-devel or
>> will you?  It may involve some... heated... discussion.
>
> Go ahead.  And Cc the XEmacs beta list for fun.  :-)

  Then add a couple of emacs usenet groups and you're all set :-)

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: message-yank-original issue

[Sven Joachim]

On 2011-03-15 10:34 +0100, Ted Zlatanov wrote:

> On Mon, 14 Mar 2011 14:13:15 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 
> DK> It has now been about two weeks that message-yank-original has stopped
> DK> being functional for installations that don't have cl loaded permanently
> DK> (namely standard Emacs installations).
>
> TZ> I posted a fix on the bug list, can you reply there if it worked?
>
> Since I didn't hear back I've pushed this patch.

Alas, this patch was reverted later that day in commit 5edabb7b1 (Author
Stefan and committed by Katsumi, apparently in merging changes between
Gnus and Emacs), so as of now message-yank-original still requires cl to
be loaded at runtime. :-(  Could you please restore the message.el
version from commit 698d90df ?

Regards,
        Sven

Re: message-yank-original issue

[Ted Zlatanov]

On Sat, 26 Mar 2011 20:34:17 +0100 Sven Joachim <svenjoac@gmx.de> wrote: 

SJ> On 2011-03-15 10:34 +0100, Ted Zlatanov wrote:
>> On Mon, 14 Mar 2011 14:13:15 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>> 
TZ> On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 
DK> It has now been about two weeks that message-yank-original has stopped
DK> being functional for installations that don't have cl loaded permanently
DK> (namely standard Emacs installations).
>> 
TZ> I posted a fix on the bug list, can you reply there if it worked?
>> 
>> Since I didn't hear back I've pushed this patch.

SJ> Alas, this patch was reverted later that day in commit 5edabb7b1 (Author
SJ> Stefan and committed by Katsumi, apparently in merging changes between
SJ> Gnus and Emacs), so as of now message-yank-original still requires cl to
SJ> be loaded at runtime. :-(  Could you please restore the message.el
SJ> version from commit 698d90df ?

I'm not sure what's going on with message.el.  It clearly says 

(eval-when-compile
  (require 'cl))

so it should not be erroring out.  Stefan wanted to go back to using
`case' instead of `cond' so I'll defer to him.

Ted

Re: message-yank-original issue

[Sven Joachim]

On 2011-03-28 21:05 +0200, Ted Zlatanov wrote:

> On Sat, 26 Mar 2011 20:34:17 +0100 Sven Joachim <svenjoac@gmx.de> wrote: 
>
> SJ> On 2011-03-15 10:34 +0100, Ted Zlatanov wrote:
>>> On Mon, 14 Mar 2011 14:13:15 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>>> 
> TZ> On Mon, 14 Mar 2011 11:11:47 +0100 David Kastrup <dak@gnu.org> wrote: 
> DK> It has now been about two weeks that message-yank-original has stopped
> DK> being functional for installations that don't have cl loaded permanently
> DK> (namely standard Emacs installations).
>>> 
> TZ> I posted a fix on the bug list, can you reply there if it worked?
>>> 
>>> Since I didn't hear back I've pushed this patch.
>
> SJ> Alas, this patch was reverted later that day in commit 5edabb7b1 (Author
> SJ> Stefan and committed by Katsumi, apparently in merging changes between
> SJ> Gnus and Emacs), so as of now message-yank-original still requires cl to
> SJ> be loaded at runtime. :-(  Could you please restore the message.el
> SJ> version from commit 698d90df ?
>
> I'm not sure what's going on with message.el.  It clearly says 
>
> (eval-when-compile
>   (require 'cl))
>
> so it should not be erroring out.

IIUC, the problem is that the bulk of message-yank-original, including
the (case …) statement, is inside a backquoted list, so the
byte-compiler will leave it alone.

> Stefan wanted to go back to using
> `case' instead of `cond' so I'll defer to him.

Cheers,
       Sven

Re: message-yank-original issue

[Ted Zlatanov]

On Mon, 28 Mar 2011 21:57:26 +0200 Sven Joachim <svenjoac@gmx.de> wrote: 

SJ> On 2011-03-28 21:05 +0200, Ted Zlatanov wrote:
>> I'm not sure what's going on with message.el.  It clearly says 
>> 
>> (eval-when-compile
>> (require 'cl))
>> 
>> so it should not be erroring out.

SJ> IIUC, the problem is that the bulk of message-yank-original, including
SJ> the (case …) statement, is inside a backquoted list, so the
SJ> byte-compiler will leave it alone.

>> Stefan wanted to go back to using
>> `case' instead of `cond' so I'll defer to him.

I see, thanks for explaining.  Stefan, do you want me to fix it or will
you?

Thanks
Ted

Re: message-yank-original issue

[Stefan Monnier]

> I'm not sure what's going on with message.el.  It clearly says 

> (eval-when-compile
>   (require 'cl))

> so it should not be erroring out.  Stefan wanted to go back to using
> `case' instead of `cond' so I'll defer to him.

I see what's going on:

(defun message-yank-original (&optional arg)
[...]
    (eval
     `(let ,message-cite-style
[...]
	  (case message-cite-reply-position
[...]


Now, why on earth is this code using the evil `eval'?


        Stefan

Re: message-yank-original issue

[Stefan Monnier]

> I'm not sure what's going on with message.el.  It clearly says 

> (eval-when-compile
>   (require 'cl))

> so it should not be erroring out.  Stefan wanted to go back to using
> `case' instead of `cond' so I'll defer to him.

How 'bout the patch below, which makes the bulk of the eval'd code
visible to the byte-compiler, as god intended it to be.


        Stefan


=== modified file 'lisp/gnus/message.el'
--- lisp/gnus/message.el	2011-03-18 02:09:58 +0000
+++ lisp/gnus/message.el	2011-03-28 20:38:41 +0000
@@ -3721,22 +3721,9 @@
       (while (re-search-forward citexp nil t)
 	(replace-match (if remove "" "\n"))))))
 
-(defun message-yank-original (&optional arg)
-  "Insert the message being replied to, if any.
-Puts point before the text and mark after.
-Normally indents each nonblank line ARG spaces (default 3).  However,
-if `message-yank-prefix' is non-nil, insert that prefix on each line.
-
-This function uses `message-cite-function' to do the actual citing.
-
-Just \\[universal-argument] as argument means don't indent, insert no
-prefix, and don't delete any headers."
-  (interactive "P")
+(defun message--yank-original-internal (arg)
   (let ((modified (buffer-modified-p))
 	body-text)
-    ;; eval the let forms contained in message-cite-style
-    (eval
-     `(let ,message-cite-style
 	(when (and message-reply-buffer
 		   message-cite-function)
 	  (when (equal message-cite-reply-position 'above)
@@ -3776,7 +3763,23 @@
 	  ;; Add a `message-setup-very-last-hook' here?
 	  ;; Add `gnus-article-highlight-citation' here?
 	  (unless modified
-	    (setq message-checksum (message-checksum))))))))
+        (setq message-checksum (message-checksum))))))
+
+(defun message-yank-original (&optional arg)
+  "Insert the message being replied to, if any.
+Puts point before the text and mark after.
+Normally indents each nonblank line ARG spaces (default 3).  However,
+if `message-yank-prefix' is non-nil, insert that prefix on each line.
+
+This function uses `message-cite-function' to do the actual citing.
+
+Just \\[universal-argument] as argument means don't indent, insert no
+prefix, and don't delete any headers."
+  (interactive "P")
+  ;; eval the let forms contained in message-cite-style
+  (eval
+   `(let ,message-cite-style
+      (message--yank-original-internal ',arg))))
 
 (defun message-yank-buffer (buffer)
   "Insert BUFFER into the current buffer and quote it."

Re: message-yank-original issue

[Antoine Levitt]

28/03/11 22:35, Stefan Monnier
>> I'm not sure what's going on with message.el.  It clearly says 
>
>> (eval-when-compile
>>   (require 'cl))
>
>> so it should not be erroring out.  Stefan wanted to go back to using
>> `case' instead of `cond' so I'll defer to him.
>
> I see what's going on:
>
> (defun message-yank-original (&optional arg)
> [...]
>     (eval
>      `(let ,message-cite-style
> [...]
> 	  (case message-cite-reply-position
> [...]
>
>
> Now, why on earth is this code using the evil `eval'?
>
>
>         Stefan

Ah, that's my fault. I didn't know how to do it any other way
(message-cite-style contains a let-style list of attributes, so this
seemed like a natural way to do it). I used eval and mentioned the code
might use some improvment, but nobody touched it. What's the preferred
way to do this?

Re: message-yank-original issue

[Ted Zlatanov]

On Mon, 28 Mar 2011 16:41:38 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> How 'bout the patch below, which makes the bulk of the eval'd code
SM> visible to the byte-compiler, as god intended it to be.

Looks good, committed to Gnus.

On Tue, 29 Mar 2011 07:37:08 +0200 Antoine Levitt <antoine.levitt@gmail.com> wrote: 

AL> I used eval and mentioned the code might use some improvment, but
AL> nobody touched it. What's the preferred way to do this?

The way Stefan did it is usually OK.  You could have also maybe done it
with macros.  It's kind of an ugly construct but that's not your fault :)

Thanks
Ted

Re: message-yank-original issue

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 28 Mar 2011 16:41:38 -0400 Stefan Monnier
> <monnier@IRO.UMontreal.CA> wrote:
>
> SM> How 'bout the patch below, which makes the bulk of the eval'd code
> SM> visible to the byte-compiler, as god intended it to be.
>
> Looks good, committed to Gnus.

Disclaimer: have not actually analyzed any code to any reasonable degree
and am just brainstorming.

Well, the original idea as far as I can see was to eval a bunch of
let-bindings and let the inner construct be evaluated with this set of
bindings in effect.

Byte-compiling the inner stuff in the lexical binding branch would
appear to defeat that intent.

Probably a good idea to overthink the whole message-variable concept and
its implementation in gnus.

-- 
David Kastrup

Gnus compatibility with the lexical binding branch (was: message-yank-original issue)

[Ted Zlatanov]

On Tue, 29 Mar 2011 17:08:07 +0200 David Kastrup <dak@gnu.org> wrote: 

DK> Well, the original idea as far as I can see was to eval a bunch of
DK> let-bindings and let the inner construct be evaluated with this set of
DK> bindings in effect.

DK> Byte-compiling the inner stuff in the lexical binding branch would
DK> appear to defeat that intent.

DK> Probably a good idea to overthink the whole message-variable concept and
DK> its implementation in gnus.

I'm not familiar with the lexical binding branch.  Is there a developer
guide for ensuring compatibility with that branch?  And are you (and
Stefan) asking the Gnus developers to invest time in that compatibility?

The reason I ask is that Gnus is full of creative solutions using eval
and macros so I'd like to make sure we don't approach this as a single
fix for the lexical binding branch that suddenly sets the expectation
that the rest of Gnus has to be compatible as well.

Ted

Re: Gnus compatibility with the lexical binding branch

[Stefan Monnier]

> I'm not familiar with the lexical binding branch.  Is there a developer
> guide for ensuring compatibility with that branch?  And are you (and
> Stefan) asking the Gnus developers to invest time in that compatibility?

It's the other way: the branch has to ensure compatibility.  So there's
nothing to worry about for you.  But if you intend to use the
lexical-binding mode for some of Gnus's code, you'll have to adjust
a few things (mostly make sure all uses of dynamic scoping are duly
declared via defvar before the first use).


        Stefan

Re: Gnus compatibility with the lexical binding branch

[Ted Zlatanov]

On Tue, 29 Mar 2011 16:16:29 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> I'm not familiar with the lexical binding branch.  Is there a developer
>> guide for ensuring compatibility with that branch?  And are you (and
>> Stefan) asking the Gnus developers to invest time in that compatibility?

SM> It's the other way: the branch has to ensure compatibility.  So there's
SM> nothing to worry about for you.  But if you intend to use the
SM> lexical-binding mode for some of Gnus's code, you'll have to adjust
SM> a few things (mostly make sure all uses of dynamic scoping are duly
SM> declared via defvar before the first use).

Is there an example of how to do this properly, how to test that it's
correct, and is there any way to catch it at the byte-compile stage?

Ted

Re: Gnus compatibility with the lexical binding branch

[Stefan Monnier]

> Is there an example of how to do this properly, how to test that it's
> correct, and is there any way to catch it at the byte-compile stage?

Example, no, and neither "tests that it's correct", but the Texinfo doc
includes a discussion of how to do it (using byte-compiler messages to
catch likely problems).


        Stefan

Re: Gnus compatibility with the lexical binding branch

[Ted Zlatanov]

On Tue, 29 Mar 2011 20:42:20 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Is there an example of how to do this properly, how to test that it's
>> correct, and is there any way to catch it at the byte-compile stage?

SM> Example, no, and neither "tests that it's correct", but the Texinfo doc
SM> includes a discussion of how to do it (using byte-compiler messages to
SM> catch likely problems).

I looked at (info "(elisp) Lexical Binding") and 
(info "(elisp) Converting to Lexical Binding") and it was educational,
though a few examples would have been nice to explain how it all works,
especially what the resulting `closure' cons cell looks like.  Would you
like me to write something up?

(info "(elisp) Extent") incorrectly says that Emacs Lisp does not have
closures so it probably should be fixed.  I don't know the details well
enough to offer a patch.

Ted