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