* backporting bugfixes to the v5-10 branch
@ 2006-07-11 22:24 Andreas Seltenreich
2006-07-17 17:52 ` Reiner Steib
0 siblings, 1 reply; 9+ messages in thread
From: Andreas Seltenreich @ 2006-07-11 22:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: backporting bugfixes to the v5-10 branch
2006-07-11 22:24 backporting bugfixes to the v5-10 branch Andreas Seltenreich
@ 2006-07-17 17:52 ` Reiner Steib
2006-07-20 17:12 ` Andreas Seltenreich
0 siblings, 1 reply; 9+ messages in thread
From: Reiner Steib @ 2006-07-17 17:52 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: backporting bugfixes to the v5-10 branch
2006-07-17 17:52 ` Reiner Steib
@ 2006-07-20 17:12 ` Andreas Seltenreich
2006-08-22 7:24 ` Andreas Seltenreich
2006-08-23 7:20 ` The Agent vs. gnus-find-method-for-group (was: backporting bugfixes to the v5-10 branch) Andreas Seltenreich
0 siblings, 2 replies; 9+ messages in thread
From: Andreas Seltenreich @ 2006-07-20 17:12 UTC (permalink / raw)
Cc: Kevin Greiner
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: backporting bugfixes to the v5-10 branch
2006-07-20 17:12 ` Andreas Seltenreich
@ 2006-08-22 7:24 ` Andreas Seltenreich
2006-08-22 13:59 ` Reiner Steib
2006-08-23 7:20 ` The Agent vs. gnus-find-method-for-group (was: backporting bugfixes to the v5-10 branch) Andreas Seltenreich
1 sibling, 1 reply; 9+ messages in thread
From: Andreas Seltenreich @ 2006-08-22 7:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: backporting bugfixes to the v5-10 branch
2006-08-22 7:24 ` Andreas Seltenreich
@ 2006-08-22 13:59 ` Reiner Steib
2006-08-23 4:20 ` Andreas Seltenreich
0 siblings, 1 reply; 9+ messages in thread
From: Reiner Steib @ 2006-08-22 13:59 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: backporting bugfixes to the v5-10 branch
2006-08-22 13:59 ` Reiner Steib
@ 2006-08-23 4:20 ` Andreas Seltenreich
0 siblings, 0 replies; 9+ messages in thread
From: Andreas Seltenreich @ 2006-08-23 4:20 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* The Agent vs. gnus-find-method-for-group (was: backporting bugfixes to the v5-10 branch)
2006-07-20 17:12 ` Andreas Seltenreich
2006-08-22 7:24 ` Andreas Seltenreich
@ 2006-08-23 7:20 ` Andreas Seltenreich
2006-08-25 12:36 ` hook to insert sign command and forwarded messages gdt
1 sibling, 1 reply; 9+ messages in thread
From: Andreas Seltenreich @ 2006-08-23 7:20 UTC (permalink / raw)
Cc: Kevin Greiner
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* hook to insert sign command and forwarded messages
2006-08-23 7:20 ` The Agent vs. gnus-find-method-for-group (was: backporting bugfixes to the v5-10 branch) Andreas Seltenreich
@ 2006-08-25 12:36 ` gdt
2006-08-28 0:49 ` Katsumi Yamaoka
0 siblings, 1 reply; 9+ messages in thread
From: gdt @ 2006-08-25 12:36 UTC (permalink / raw)
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hook to insert sign command and forwarded messages
2006-08-25 12:36 ` hook to insert sign command and forwarded messages gdt
@ 2006-08-28 0:49 ` Katsumi Yamaoka
0 siblings, 0 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2006-08-28 0:49 UTC (permalink / raw)
Cc: ding
>>>>> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-08-28 0:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-07-11 22:24 backporting bugfixes to the v5-10 branch Andreas Seltenreich
2006-07-17 17:52 ` Reiner Steib
2006-07-20 17:12 ` Andreas Seltenreich
2006-08-22 7:24 ` Andreas Seltenreich
2006-08-22 13:59 ` Reiner Steib
2006-08-23 4:20 ` Andreas Seltenreich
2006-08-23 7:20 ` The Agent vs. gnus-find-method-for-group (was: backporting bugfixes to the v5-10 branch) Andreas Seltenreich
2006-08-25 12:36 ` hook to insert sign command and forwarded messages gdt
2006-08-28 0:49 ` Katsumi Yamaoka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).