Re: /srv/bzr/emacs/trunk r102179: Silence gnus-util.el compilation.

Re: /srv/bzr/emacs/trunk r102179: Silence gnus-util.el compilation.

[Glenn Morris]

Stefan Monnier wrote:

>> -(autoload 'iswitchb-read-buffer "iswitchb")
>> +(declare-function iswitchb-read-buffer "iswitchb"
>> +		  (prompt &optional default require-match start matches-set))
>> +(defvar iswitchb-temp-buflist)
>> +
>>  (defun gnus-iswitchb-completing-read (prompt collection &optional require-match
>>                                              initial-input history def)
>>    "`iswitchb' based completing-read function."
>> +  (require 'iswitchb)
>>    (let ((iswitchb-make-buflist-hook
>>           (lambda ()
>>             (setq iswitchb-temp-buflist
>
> I'm not convinced that declare-function+require is better than autoload.
> What was the problem with autoload?

It might load iswitchb while an iswitchb variable was let bound. Eg:

  (let ((iswitchb-make-buflist-hook t))
    (require 'iswitchb))

  C-h v iswitchb-make-buflist-hook
  It is void as a variable.

PS could you reply to emacs-devel rather than emacs-diffs in these cases?
(I don't know why emacs-diffs is even configured to accept postings
other than from Savannah.)

Re: /srv/bzr/emacs/trunk r102179: Silence gnus-util.el compilation.

[Stefan Monnier]

>>> -(autoload 'iswitchb-read-buffer "iswitchb")
>>> +(declare-function iswitchb-read-buffer "iswitchb"
>>> +		  (prompt &optional default require-match start matches-set))
>>> +(defvar iswitchb-temp-buflist)
>>> +
>>> (defun gnus-iswitchb-completing-read (prompt collection &optional require-match
>>> initial-input history def)
>>> "`iswitchb' based completing-read function."
>>> +  (require 'iswitchb)
>>> (let ((iswitchb-make-buflist-hook
>>> (lambda ()
>>> (setq iswitchb-temp-buflist
>> 
>> I'm not convinced that declare-function+require is better than autoload.
>> What was the problem with autoload?
> It might load iswitchb while an iswitchb variable was let bound. Eg:

I see, thanks.  Then it would have been good to add a comment before the
`require' reminding future readers why we did it this way.

> PS could you reply to emacs-devel rather than emacs-diffs in these cases?
> (I don't know why emacs-diffs is even configured to accept postings
> other than from Savannah.)

Yes, I get bitten by this all the time.  Indeed emacs-diffs should
refuse such postings.


        Stefan

Avoiding replies on emacs-diffs (was: /srv/bzr/emacs/trunk r102179: Silence gnus-util.el compilation.)

[Reiner Steib]

On Mon, Nov 01 2010, Stefan Monnier wrote:

>> PS could you reply to emacs-devel rather than emacs-diffs in these cases?
>> (I don't know why emacs-diffs is even configured to accept postings
>> other than from Savannah.)
>
> Yes, I get bitten by this all the time.  Indeed emacs-diffs should
> refuse such postings.

Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Avoiding replies on emacs-diffs

[Karl Fogel]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
>On Mon, Nov 01 2010, Stefan Monnier wrote:
>>> PS could you reply to emacs-devel rather than emacs-diffs in these cases?
>>> (I don't know why emacs-diffs is even configured to accept postings
>>> other than from Savannah.)
>>
>> Yes, I get bitten by this all the time.  Indeed emacs-diffs should
>> refuse such postings.
>
>Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.

Also: just set the 'Reply-to' header on emacs-diffs@ mails to go to
emacs-devel@?

Note this is not subject to the usual objections to Reply-to munging.
It's always okay for the sender of a message to set Reply-to, and in
this case, the sender is the version control system itself -- it sets
Reply-to in order to indicate that the appropriate place for replies is
the development mailing list, not the diffs list.

(http://producingoss.com/en/vc.html#commit-emails has more pontification)

-Karl

Re: Avoiding replies on emacs-diffs

[Stephen J. Turnbull]

Karl Fogel writes:
 > Reiner Steib <reinersteib+gmane@imap.cc> writes:
 > >On Mon, Nov 01 2010, Stefan Monnier wrote:
 > >>> PS could you reply to emacs-devel rather than emacs-diffs in these cases?
 > >>> (I don't know why emacs-diffs is even configured to accept postings
 > >>> other than from Savannah.)
 > >>
 > >> Yes, I get bitten by this all the time.  Indeed emacs-diffs should
 > >> refuse such postings.
 > >
 > >Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.
 > 
 > Also: just set the 'Reply-to' header on emacs-diffs@ mails to go to
 > emacs-devel@?

Yeah, MFT is just plain beside-the-point here.  (Besides being ignored
by most MUAs in use, and even by a number of popular free software MUAs.)
Reply-To is pretty universally respected.

Re: Avoiding replies on emacs-diffs

[Reiner Steib]

On Thu, Nov 04 2010, Stephen J. Turnbull wrote:

> Karl Fogel writes:
>  > Reiner Steib <reinersteib+gmane@imap.cc> writes:
>  > >Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.
>  > 
>  > Also: just set the 'Reply-to' header on emacs-diffs@ mails to go to
>  > emacs-devel@?
>
> Yeah, MFT is just plain beside-the-point here.  (Besides being ignored
> by most MUAs in use, and even by a number of popular free software MUAs.)

It is respected by the default mail composition mode in Emacs. :-)

> Reply-To is pretty universally respected.

While I don't like Reply-To munging in "normal" lists, I agree to
Karl's arguments for emacs-diffs.

Is it possible to set M-F-T and Reply-To to emacs-diffs _and_ the
committer's address?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Avoiding replies on emacs-diffs

[Stephen J. Turnbull]

Reiner Steib writes:

 > Is it possible to set M-F-T and Reply-To to emacs-diffs _and_ the
 > committer's address?

Yes.  It's legal for Reply-To to contain multiple addresses, and
Mailman in fact has a mode that adds a specified address or addresses
to Reply-To if Reply is already present.  However, if it's a good idea
to add a setting for MFT too, then that will have to be done either in
the commit 'bot or in a custom Mailman Handler.  (I assume emacs-diffs
is a Mailman list, for user convenience.)  I don't know the
Mail-Followup-To spec, but I assume it permits multiple addresses,
too.

Re: Avoiding replies on emacs-diffs

[Stefan Monnier]

>>>> PS could you reply to emacs-devel rather than emacs-diffs in these cases?
>>>> (I don't know why emacs-diffs is even configured to accept postings
>>>> other than from Savannah.)
>>> Yes, I get bitten by this all the time.  Indeed emacs-diffs should
>>> refuse such postings.
>> Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.
> Also: just set the 'Reply-to' header on emacs-diffs@ mails to go to
> emacs-devel@?

That would suck, just as much as other uses of reply-to: it would make
it unnecessarily difficult to reply personally to the committer.


        Stefan

Re: Avoiding replies on emacs-diffs

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>> PS could you reply to emacs-devel rather than emacs-diffs in these cases?
>>>>> (I don't know why emacs-diffs is even configured to accept postings
>>>>> other than from Savannah.)
>>>> Yes, I get bitten by this all the time.  Indeed emacs-diffs should
>>>> refuse such postings.
>>> Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.
>> Also: just set the 'Reply-to' header on emacs-diffs@ mails to go to
>> emacs-devel@?
>
>That would suck, just as much as other uses of reply-to: it would make
>it unnecessarily difficult to reply personally to the committer.

Well, it's more complicated than that, I think...

There are two separate but related issues:

  1) The "can't find my way back home" problem, which is why Reply-to
     munging is often objected to when performed on mails people
     actually posted.  We don't have this problem here, though.

  2) The "reader wants to reply to just the author" problem, which is
     related to (1) in that if you can't even find out the author's
     preferred Reply-to address, there's no way you can reply to the
     author.

But that's not the (2) we're talking about here.  Our (2) is simply a
matter of removing the emacs-devel@ address when following up.  Replying
to just the author should be no more difficult than it is now, since the
commit email is already not an email posted by the committer and cannot
be relied on to have an existing Reply-to header with the committer's
preferred email address anyway.

Another way to look at it:

A commit email is an email *from the version control system* to the
maintainer group, announcing a change.  That's why it makes sense for
the maintainer group to be the default forum for replies.  Problem (1)
doesn't apply here at all, and problem (2) doesn't really apply either,
since we already have problem (2) and this doesn't make it worse, and
anyway it's not really a problem because commits are public events to
which public followup (if any) is normally appropriate.

Since most of the time we want discussion of a change to happen among
the maintainer group, having the version control system set that as the
default is reasonable.  (It would be totally different if emacs-diffs@
were a mailing list that humans posted heterogenous messages to
directly, of course.)

This is all based on experience, for what it's worth.  I've worked on
projects that actually do this with their commit emails, and it's been
great.  People seem to like it, and I don't recall hearing any
complaints about it.

-Karl

Re: Avoiding replies on emacs-diffs

[Stephen J. Turnbull]

Stefan Monnier writes:

 > That would suck, just as much as other uses of reply-to: it would make
 > it unnecessarily difficult to reply personally to the committer.

You could put the committer in there too.  Committers who don't want
the implied dupes (they're all on emacs-devel, right?) can set nodupes
in their Mailman options.

M-F-T is non-standard *for email*, and unimplemented in many
email-oriented MUAs.  It's not strong enough.

The fallback is to just prohibit posting from anyone but the commit
'bot.  But then it's "unnecessarily difficult" to followup to the
appropriate list for exactly the people who have the most inflexible
MUAs.

BTW, AFAICS the only people who *need* to reply personally to
committers are you and Yidong (for "Don't *do* that, you nitwit!
Revert and do it *yesterday*!" messages :-) and I suppose you can
write a function to grovel From out of the header....

I don't like policy-by-mail-header any more than you do, but we have
to work with the crappy MUAs that users love to use.  Even Emacsers.

Re: Avoiding replies on emacs-diffs

[Stefan Monnier]

> The fallback is to just prohibit posting from anyone but the commit 'bot.

That's actually not a fallback, but just a good idea in general.


        Stefan

Re: Avoiding replies on emacs-diffs

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> The fallback is to just prohibit posting from anyone but the commit 'bot.
>
>That's actually not a fallback, but just a good idea in general.

Agreed -- whichever way we go with Reply-to, there's no reason to have
devel discussions on emacs-diffs@.  If human mails to the diffs list
bounce, then people will be motivated to send to emacs-devel@ instead,
with whatever UI gestures that may entail.

Re: Avoiding replies on emacs-diffs

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> Yes, I get bitten by this all the time.  Indeed emacs-diffs should
>> refuse such postings.
>
> Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.

Probably it would help, but it also will likely be the cause of endless
bickering on this mailing list (for whatever reason, MTF: is a Major
Religious Issue)...

-Miles

-- 
Inhumanity, n. One of the signal and characteristic qualities of humanity.

loading foo.el while foo-var is let-bound [was Re: /srv/bzr/emacs/trunk r102179: Silence gnus-util.el compilation.]

[Glenn Morris]

>   (let ((iswitchb-make-buflist-hook t))
>     (require 'iswitchb))
>
>   C-h v iswitchb-make-buflist-hook
>   It is void as a variable.


BTW, is there any prospect of warning about/dealing with this kind of
of thing?

Re: loading foo.el while foo-var is let-bound

[Stefan Monnier]

>> (let ((iswitchb-make-buflist-hook t))
>> (require 'iswitchb))
>> 
>> C-h v iswitchb-make-buflist-hook
>> It is void as a variable.

> BTW, is there any prospect of warning about/dealing with this kind of
> of thing?

Hmm... indeed we have a bug: the Fdefvar code tries to catch it and emit
a warning, but Fdefvar is not called in the above case.


        Stefan