backporting bugfixes to the v5-10 branch

backporting bugfixes to the v5-10 branch

[Andreas Seltenreich]

I just reviewed the v5-10 branch with respect to my recent bugfixes in
the trunk, and the following would be applicable to the stable branch,
too:
	* nnweb.el (nnweb-google-parse-1): Update regexp for author and date.
	(nnweb-google-search): Respect nnweb-max-hits as upper bound.

	* gnus-srvr.el (gnus-browse-unsubscribe-group): Don't subscribe
	unsubscribed groups as if they were killed ones.  It causes duplicate
	entries in gnus-newsrc-alist.

	* mm-url.el (mm-url-insert-file-contents): Don't set Connection: Close.

Any objections to backporting them?

I'm not sure what to do with the change to gnus-find-method-for-group:

	* gnus.el (gnus-find-method-for-group): On killed/unknown groups, try
	looking up the method using GROUP's prefix before inventing a new one.
	It is used on killed/unknown groups in various places where returning
	an all-new method isn't expected by the caller.

While I can reproduce all of the bugs listed in
<news:87fyhttsum.fsf@gate450.dyndns.org> on a stable Gnus, the fix
depends on the macro gnus-group-server, which doesn't exists on the
v5-10 branch.  Maybe just inling its code is more appropriate than
adding the macro to v5-10?  I'm afraid the alternative to changing
gnus-find-method-for-group would be to locate all places where it
could be called on killed groups, and possibly fixing those.

regards,
andreas

Re: backporting bugfixes to the v5-10 branch

[Reiner Steib]

On Wed, Jul 12 2006, Andreas Seltenreich wrote:

> I just reviewed the v5-10 branch with respect to my recent bugfixes in
> the trunk, and the following would be applicable to the stable branch,
> too:
> 	* nnweb.el (nnweb-google-parse-1): Update regexp for author and date.
> 	(nnweb-google-search): Respect nnweb-max-hits as upper bound.
>
> 	* gnus-srvr.el (gnus-browse-unsubscribe-group): Don't subscribe
> 	unsubscribed groups as if they were killed ones.  It causes duplicate
> 	entries in gnus-newsrc-alist.
>
> 	* mm-url.el (mm-url-insert-file-contents): Don't set Connection: Close.
>
> Any objections to backporting them?

Feel free to backport to v5-10 if you consider the fixes stable
enough.

> I'm not sure what to do with the change to gnus-find-method-for-group:
>
> 	* gnus.el (gnus-find-method-for-group): On killed/unknown groups, try
> 	looking up the method using GROUP's prefix before inventing a new one.
> 	It is used on killed/unknown groups in various places where returning
> 	an all-new method isn't expected by the caller.
>
> While I can reproduce all of the bugs listed in
> <news:87fyhttsum.fsf@gate450.dyndns.org> on a stable Gnus, 

... and the fix as well, I guess?

> the fix depends on the macro gnus-group-server, which doesn't exists
> on the v5-10 branch.  Maybe just inling its code is more appropriate
> than adding the macro to v5-10?

I'd suggest to add the macro to v5-10 as well.  It makes the code more
readable and simplifies comparing the different branches.

> I'm afraid the alternative to changing gnus-find-method-for-group
> would be to locate all places where it could be called on killed
> groups, and possibly fixing those.

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

Re: backporting bugfixes to the v5-10 branch

[Andreas Seltenreich]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Jul 12 2006, Andreas Seltenreich wrote:
>
>> I'm not sure what to do with the change to gnus-find-method-for-group:
>>
>> 	* gnus.el (gnus-find-method-for-group): On killed/unknown groups, try
>> 	looking up the method using GROUP's prefix before inventing a new one.
>> 	It is used on killed/unknown groups in various places where returning
>> 	an all-new method isn't expected by the caller.
>>
>> While I can reproduce all of the bugs listed in
>> <news:87fyhttsum.fsf@gate450.dyndns.org> on a stable Gnus, 
>
> ... and the fix as well, I guess?

Ack, I was unable to trigger the bugs anymore on v5-10 with the fix
merged in.

>> the fix depends on the macro gnus-group-server, which doesn't exists
>> on the v5-10 branch.  Maybe just inling its code is more appropriate
>> than adding the macro to v5-10?
>
> I'd suggest to add the macro to v5-10 as well.  It makes the code more
> readable and simplifies comparing the different branches.

Good point.

>> I'm afraid the alternative to changing gnus-find-method-for-group
>> would be to locate all places where it could be called on killed
>> groups, and possibly fixing those.

Btw, testing with the agent enabled revealed two places where
g-f-m-f-g is called on groups after their prefix has been stripped,
causing the native method to be returned.  I don't think this is
intentional, is it?

Debugger entered: ("g-f-m-f-g called on unknown group")
[...]
  gnus-find-method-for-group("mailings.pgsql.general")
  gnus-agent-get-local("mailings.pgsql.general")
  gnus-agent-possibly-alter-active("mailings.pgsql.general" (1 . 6325))
  gnus-agent-regenerate-group("nnpg+lists:mailings.pgsql.general" nil)
  gnus-agent-regenerate(nil)
  call-interactively(gnus-agent-regenerate)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

Debugger entered: ("g-f-m-f-g called on unknown group")
[...]
  gnus-find-method-for-group("mailings.pgsql.general")
  gnus-group-name-charset(nil "mailings.pgsql.general")
  gnus-group-decoded-name("mailings.pgsql.general")
  gnus-agent-group-pathname("mailings.pgsql.general")
  gnus-agent-article-name(".overview" "mailings.pgsql.general")
  nnagent-retrieve-headers((1113 1114) "mailings.pgsql.general" "lists" nil)
  gnus-retrieve-headers((1113 1114) "nnpg+lists:mailings.pgsql.general" nil)
  gnus-cache-retrieve-headers((1113 1114) "nnpg+lists:mailings.pgsql.general" nil)
  gnus-retrieve-headers((1113 1114) "nnpg+lists:mailings.pgsql.general" nil)
  gnus-fetch-headers((1113 1114))
  gnus-select-newsgroup("nnpg+lists:mailings.pgsql.general" nil nil)
  gnus-summary-read-group-1("nnpg+lists:mailings.pgsql.general" nil t nil nil nil)
  gnus-summary-read-group("nnpg+lists:mailings.pgsql.general" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  gnus-topic-select-group(nil)
  call-interactively(gnus-topic-select-group)

regards,
andreas

Re: backporting bugfixes to the v5-10 branch

[Andreas Seltenreich]

Andreas Seltenreich writes:

> Reiner Steib writes:
>
>> On Wed, Jul 12 2006, Andreas Seltenreich wrote:
>>
>>> I'm not sure what to do with the change to gnus-find-method-for-group:
>>>
>>> 	* gnus.el (gnus-find-method-for-group): On killed/unknown groups, try
>>> 	looking up the method using GROUP's prefix before inventing a new one.
>>> 	It is used on killed/unknown groups in various places where returning
>>> 	an all-new method isn't expected by the caller.
>>>
>>> While I can reproduce all of the bugs listed in
>>> <news:87fyhttsum.fsf@gate450.dyndns.org> on a stable Gnus, 
>>
>> ... and the fix as well, I guess?
>
> Ack, I was unable to trigger the bugs anymore on v5-10 with the fix
> merged in.
[...]
> Btw, testing with the agent enabled revealed two places where
> g-f-m-f-g is called on groups after their prefix has been stripped,
> causing the native method to be returned.  I don't think this is
> intentional, is it?
>
> [backtraces]

While I'm very confident that the change to g-f-m-f-g won't cause any
regressions, I do not /know/ that it won't.  Especially with respect
to the agent.  With Emacs pretest approaching, I'm still reluctant to
commit it to v5-10, and unless someone raises a more knowledgeable
opinion, I'll leave it on the trunk.

regards,
andreas

Re: backporting bugfixes to the v5-10 branch

[Reiner Steib]

On Tue, Aug 22 2006, Andreas Seltenreich wrote:

> Andreas Seltenreich writes:
>> Reiner Steib writes:
>>> On Wed, Jul 12 2006, Andreas Seltenreich wrote:
>>>
>>>> I'm not sure what to do with the change to gnus-find-method-for-group:
>>>>
>>>> 	* gnus.el (gnus-find-method-for-group): On killed/unknown groups, try
>>>> 	looking up the method using GROUP's prefix before inventing a new one.
>>>> 	It is used on killed/unknown groups in various places where returning
>>>> 	an all-new method isn't expected by the caller.
>>>>
>>>> While I can reproduce all of the bugs listed in
>>>> <news:87fyhttsum.fsf@gate450.dyndns.org> on a stable Gnus, 
>>>
>>> ... and the fix as well, I guess?
>>
>> Ack, I was unable to trigger the bugs anymore on v5-10 with the fix
>> merged in.
> [...]
>> Btw, testing with the agent enabled revealed two places where
>> g-f-m-f-g is called on groups after their prefix has been stripped,
>> causing the native method to be returned.  I don't think this is
>> intentional, is it?
>>
>> [backtraces]

Is this problem related to your change or not?  Could you please
summarize this problem again, Cc-ing Kevin Greiner and ask for his
advise/opinion.

> While I'm very confident that the change to g-f-m-f-g won't cause any
> regressions, I do not /know/ that it won't.  Especially with respect
> to the agent.  

I don't have time to look at the code, but as the code is installed
the trunk since 2006-06-25, it probably is sufficient testing (as the
agent is enabled by default) by now to be installed in the trunk as
well.

> With Emacs pretest approaching, I'm still reluctant to commit it to
> v5-10, and unless someone raises a more knowledgeable opinion, I'll
> leave it on the trunk.

After all, your changes fixed some problems still present in
v5-10/Emacs CVS, so I'd say install it in v5-10 now.

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

Re: backporting bugfixes to the v5-10 branch

[Andreas Seltenreich]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Tue, Aug 22 2006, Andreas Seltenreich wrote:
>
>> Andreas Seltenreich writes:
>>> Reiner Steib writes:
>>>> On Wed, Jul 12 2006, Andreas Seltenreich wrote:
>>>>
>>>>> I'm not sure what to do with the change to gnus-find-method-for-group:
>>>>>
>>>>> 	* gnus.el (gnus-find-method-for-group): On killed/unknown groups, try
>>>>> 	looking up the method using GROUP's prefix before inventing a new one.
>>>>> 	It is used on killed/unknown groups in various places where returning
>>>>> 	an all-new method isn't expected by the caller.
>>>>>
>>>>> While I can reproduce all of the bugs listed in
>>>>> <news:87fyhttsum.fsf@gate450.dyndns.org> on a stable Gnus, 
>>>>
>>>> ... and the fix as well, I guess?
>>>
>>> Ack, I was unable to trigger the bugs anymore on v5-10 with the fix
>>> merged in.
>> [...]
>>> Btw, testing with the agent enabled revealed two places where
>>> g-f-m-f-g is called on groups after their prefix has been stripped,
>>> causing the native method to be returned.  I don't think this is
>>> intentional, is it?
>>>
>>> [backtraces]
>
> Is this problem related to your change or not?

Negative, the new g-f-m-f-g doesn't change semantics in this case (no
prefix & no newsrc entry => primary method).

> Could you please summarize this problem again, Cc-ing Kevin Greiner
> and ask for his advise/opinion.

Will do so in a separate mail.

>> While I'm very confident that the change to g-f-m-f-g won't cause any
>> regressions, I do not /know/ that it won't.  Especially with respect
>> to the agent.  
>
> I don't have time to look at the code, but as the code is installed
> the trunk since 2006-06-25, it probably is sufficient testing (as the
> agent is enabled by default) by now to be installed in the trunk as
> well.
>
>> With Emacs pretest approaching, I'm still reluctant to commit it to
>> v5-10, and unless someone raises a more knowledgeable opinion, I'll
>> leave it on the trunk.
>
> After all, your changes fixed some problems still present in
> v5-10/Emacs CVS, so I'd say install it in v5-10 now.

Ok, I'll install it after some more testing.

regards,
andreas

The Agent vs. gnus-find-method-for-group (was: backporting bugfixes to the v5-10 branch)

[Andreas Seltenreich]

Andreas Seltenreich writes:

> Btw, testing with the agent enabled revealed two places where
> g-f-m-f-g is called on groups after their prefix has been stripped,
> causing the native method to be returned.  I don't think this is
> intentional, is it?

I didn't dig very deep into this, and am far from understanding how
the agent does its magic, but nevertheless some updates:

> Debugger entered: ("g-f-m-f-g called on unknown group")
> [...]
>   gnus-find-method-for-group("mailings.pgsql.general")
>   gnus-agent-get-local("mailings.pgsql.general")
>   gnus-agent-possibly-alter-active("mailings.pgsql.general" (1 . 6325))
>   gnus-agent-regenerate-group("nnpg+lists:mailings.pgsql.general" nil)
>   gnus-agent-regenerate(nil)
>   call-interactively(gnus-agent-regenerate)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)

ISTM this causes the agent to look for the group's data in the native
method's directory (via gnus-agent-load-local).

There seems to be provision for passing the method as separate
argument to gnus-agent-get-local to avoid a call to g-f-m-f-g on
prefix-stripped groups in both, v5-10 and trunk:

--8<---------------cut here---------------start------------->8---
2004-10-18  Kevin Greiner

	* gnus-agent.el [...]
        [...]
	(gnus-agent-get-local): Add optional parameters to avoid calling
	gnus-group-real-name and gnus-find-method-for-group.
--8<---------------cut here---------------end--------------->8---

Maybe gnus-command-method should be passed as a third argument in
gnus-agent-possibly-alter-active?

Curiously, I'm unable to observe any adverse effects when regenerating
groups or moving/copying articles, so maybe I'm missing something...

Thanks,
andreas

hook to insert sign command and forwarded messages

[gdt]

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


I have the following hook:

      (add-hook
       'message-setup-hook
       (lambda ()
	 (message-goto-body)
	 (mml-secure-message-sign-pgpmime)))

This works fine for most things.  But when I forward a message (C-c
C-f), the <#secure..> line is after the #mml markup around the
message.  I just added message-goto-body to try to fix this, thinking
my hook would run after the message was inserted.

So, I'm not sure what's wrong.  Candidates are:

 mml-secure-message-sign-pgpmime should insert at beginning (seems
 like it does, and message-goto-body ensures that)

 insertion of forwarded message should be after any secure tags

 hook should be run after the insertion

 ?

-- 
    Greg Troxel <gdt@work.lexort.com>

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: hook to insert sign command and forwarded messages

[Katsumi Yamaoka]

>>>>> In <smulkpduh4t.fsf_-_@linuxpal.mit.edu>
>>>>>	gdt@work.lexort.com wrote:

> I have the following hook:

>       (add-hook
>        'message-setup-hook
>        (lambda ()
> 	 (message-goto-body)
> 	 (mml-secure-message-sign-pgpmime)))

> This works fine for most things.  But when I forward a message (C-c
> C-f), the <#secure..> line is after the #mml markup around the
> message.  I just added message-goto-body to try to fix this, thinking
> my hook would run after the message was inserted.

> So, I'm not sure what's wrong.  Candidates are:

>  mml-secure-message-sign-pgpmime should insert at beginning (seems
>  like it does, and message-goto-body ensures that)

Yes, it does.  However, now the `message-forward' function inserts
a forwarded part after `message-setup-hook' is run.

>  insertion of forwarded message should be after any secure tags

We can do it.

>  hook should be run after the insertion

We can do it.  How about this?

(defadvice message-forward (around run-message-setup-hook-last activate)
  "Run `message-setup-hook' last."
  (let ((message-setup-hook nil))
    ad-do-it)
  (run-hooks 'message-setup-hook))

Although we can change the `message-forward' function so as to
work like this, I'm not sure it never causes any harm to all
users.