* gnus-summary-catchup turns ticked into unread
@ 2007-07-02 16:09 Luc Van Eycken
2007-07-03 10:25 ` Katsumi Yamaoka
0 siblings, 1 reply; 8+ messages in thread
From: Luc Van Eycken @ 2007-07-02 16:09 UTC (permalink / raw)
To: bug-gnu-emacs, bugs
Hi,
If I have a newsgroup with ticked persistent articles and I leave this
group with the "c" key (gnus-summary-catchup-and-exit), all ticked articles
are turned into unread non-ticked articles. It is a regression from Emacs 21,
but I also believe this is a bug since it seems to contradict the info
documentation.
As far as I can see, it is due to the addition of gnus-newsgroup-unfetched
inside the function gnus-summary-catchup (gnus-sum.el line 10517).
Since this is a Gnus 5.11 addition, I assume that removing it again is not
the correct solution.
Best regards,
Luc Van Eycken
\f
In GNU Emacs 22.1.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2007-06-19 on achouffe
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--prefix=/freeware/emacs' '--exec-prefix=/freeware/emacs/linux-x86_64''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
show-paren-mode: t
recentf-mode: t
auto-insert-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
------------------ GNUS Environment follows ------------------
(setq gnus-default-nntp-server "")
(setq gnus-interactive-catchup nil)
(setq gnus-interactive-exit nil)
(setq gnus-group-change-level-function 'gnus-topic-change-level)
(setq gnus-summary-gather-subject-limit 'fuzzy)
(setq gnus-thread-hide-subtree t)
(setq gnus-thread-indent-level 2)
(setq gnus-auto-select-first nil)
(setq gnus-auto-select-subject
'(lambda nil
(gnus-summary-first-subject t)
(gnus-summary-position-point)))
(setq gnus-auto-select-next 'quietly)
(setq gnus-auto-center-summary nil)
(setq gnus-break-pages nil)
(setq gnus-summary-mode-hook
'(gnus-agent-mode ffap-gnus-hook))
(setq gnus-group-catchup-group-hook
'(gnus-topic-update-topic))
(setq gnus-exit-gnus-hook
'(mm-destroy-postponed-undisplay-list))
(setq gnus-prompt-before-saving t)
(setq gnus-default-article-saver 'gnus-summary-save-in-file)
(setq gnus-article-mode-hook
'(ffap-gnus-hook))
(setq gnus-check-bogus-newsgroups t)
(setq gnus-setup-news-hook
'(gnus-agent-queue-setup gnus-fixup-nnimap-unread-after-getting-new-news))
(setq gnus-group-mode-hook
'(gnus-agent-mode gnus-topic-mode))
(setq gnus-server-mode-hook
'(gnus-agent-mode))
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: gnus-summary-catchup turns ticked into unread 2007-07-02 16:09 gnus-summary-catchup turns ticked into unread Luc Van Eycken @ 2007-07-03 10:25 ` Katsumi Yamaoka 2007-07-04 10:10 ` Katsumi Yamaoka 0 siblings, 1 reply; 8+ messages in thread From: Katsumi Yamaoka @ 2007-07-03 10:25 UTC (permalink / raw) To: Luc Van Eycken; +Cc: bug-gnu-emacs, bugs [-- Attachment #1: Type: text/plain, Size: 1155 bytes --] >>>>> In <20070702160929.C21251C8115@galatea.esat.kuleuven.be> >>>>> Luc Van Eycken wrote: > If I have a newsgroup with ticked persistent articles and I leave this > group with the "c" key (gnus-summary-catchup-and-exit), all ticked articles > are turned into unread non-ticked articles. It is a regression from Emacs 21, > but I also believe this is a bug since it seems to contradict the info > documentation. That's a coincidence! When I was wandering in the Agent code today, I encountered the same trouble and reached to the same place in gnus-sum.el. > As far as I can see, it is due to the addition of gnus-newsgroup-unfetched > inside the function gnus-summary-catchup (gnus-sum.el line 10517). > Since this is a Gnus 5.11 addition, I assume that removing it again is not > the correct solution. I think regarding unfetched articles as unread articles is correct. The problem is that cached articles are not counted as fetched articles, or Gnus forgot that those cached articles used to have been fetched. I'm not quite sure how it happens because I'm new to the Agent. But I briefly checked that the patch attached below does the trick. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 561 bytes --] --- gnus-sum.el~ 2007-06-06 15:39:11 +0000 +++ gnus-sum.el 2007-07-03 10:22:57 +0000 @@ -10514,7 +10514,8 @@ (gnus-sorted-nunion (gnus-sorted-intersection gnus-newsgroup-unreads gnus-newsgroup-downloadable) - gnus-newsgroup-unfetched))) + (gnus-sorted-difference gnus-newsgroup-unfetched + gnus-newsgroup-cached)))) ;; We actually mark all articles as canceled, which we ;; have to do when using auto-expiry or adaptive scoring. (gnus-summary-show-all-threads) [-- Attachment #3: Type: text/plain, Size: 108 bytes --] I am going to install it (or other) in the Gnus CVS repository after learning the Agent further. Regards, [-- Attachment #4: Type: text/plain, Size: 149 bytes --] _______________________________________________ bug-gnu-emacs mailing list bug-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread 2007-07-03 10:25 ` Katsumi Yamaoka @ 2007-07-04 10:10 ` Katsumi Yamaoka [not found] ` <E1I6GBH-0006d2-HI@fencepost.gnu.org> 0 siblings, 1 reply; 8+ messages in thread From: Katsumi Yamaoka @ 2007-07-04 10:10 UTC (permalink / raw) To: Luc Van Eycken; +Cc: bug-gnu-emacs, bugs >>>>>> In <20070702160929.C21251C8115@galatea.esat.kuleuven.be> >>>>>> Luc Van Eycken wrote: >> If I have a newsgroup with ticked persistent articles and I leave this >> group with the "c" key (gnus-summary-catchup-and-exit), all ticked articles >> are turned into unread non-ticked articles. I've installed the fix to the Gnus CVS repository. It will be merged into the Emacs CVS when Miles Bader comes back from the vacation. The details and a patch for Gnus v5.11 are here: http://article.gmane.org/gmane.emacs.gnus.general/64874 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <E1I6GBH-0006d2-HI@fencepost.gnu.org>]
[parent not found: <b4mejjn1usy.fsf@jpl.org>]
[parent not found: <E1I6Y2D-00062v-Iq@fencepost.gnu.org>]
[parent not found: <b4mr6nhjgq1.fsf@jpl.org>]
[parent not found: <E1I8Nlq-0000oX-F6@fencepost.gnu.org>]
[parent not found: <b4mps2zzivn.fsf@jpl.org>]
* Re: gnus-summary-catchup turns ticked into unread [not found] ` <b4mps2zzivn.fsf@jpl.org> @ 2007-08-06 14:22 ` Richard Stallman 2007-08-14 0:28 ` Richard Stallman 1 sibling, 0 replies; 8+ messages in thread From: Richard Stallman @ 2007-08-06 14:22 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: emacs-devel The function definition for the XEmacs version of pop-to-buffer is as follows. There's no difference between XEmacs 21.4 and 21.5. The optional ON-FRAME is boolean, so there seems no way to keep the compatibility. (defun pop-to-buffer (bufname &optional not-this-window-p on-frame) ... If optional third arg is non-nil, it is the frame to pop to this buffer on. I am sure that few callers pass the argument NORECORD to pop-to-buffer. So I think an incompatible change would be ok, adding the ON-FRAME argument before NORECORD. What do others think? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread [not found] ` <b4mps2zzivn.fsf@jpl.org> 2007-08-06 14:22 ` Richard Stallman @ 2007-08-14 0:28 ` Richard Stallman 2007-08-16 1:54 ` Katsumi Yamaoka 1 sibling, 1 reply; 8+ messages in thread From: Richard Stallman @ 2007-08-14 0:28 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: emacs-devel [I sent this message a week ago but did not get a response. Could we get the discussion moving again?] The function definition for the XEmacs version of pop-to-buffer is as follows. There's no difference between XEmacs 21.4 and 21.5. The optional ON-FRAME is boolean, so there seems no way to keep the compatibility. (defun pop-to-buffer (bufname &optional not-this-window-p on-frame) ... If optional third arg is non-nil, it is the frame to pop to this buffer on. I am sure that few callers pass the argument NORECORD to pop-to-buffer. So I think an incompatible change would be ok, adding the ON-FRAME argument before NORECORD. What do others think? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread 2007-08-14 0:28 ` Richard Stallman @ 2007-08-16 1:54 ` Katsumi Yamaoka 2007-08-16 18:39 ` Richard Stallman 0 siblings, 1 reply; 8+ messages in thread From: Katsumi Yamaoka @ 2007-08-16 1:54 UTC (permalink / raw) To: rms; +Cc: emacs-devel >>>>> Richard Stallman wrote: > [I sent this message a week ago but did not get a response. > Could we get the discussion moving again?] > The function definition for the XEmacs version of pop-to-buffer > is as follows. There's no difference between XEmacs 21.4 and 21.5. > The optional ON-FRAME is boolean, so there seems no way to keep > the compatibility. > (defun pop-to-buffer (bufname &optional not-this-window-p on-frame) > ... > If optional third arg is non-nil, it is the frame to pop to this > buffer on. > I am sure that few callers pass the argument NORECORD to > pop-to-buffer. So I think an incompatible change would be ok, adding > the ON-FRAME argument before NORECORD. > What do others think? I worry that changing the arguments list of such a generic function in Emacs causes further confusion. For instance, since Gnus supports Emacs 21, 22, 23 and XEmacs, source codes that use `pop-to-buffer' and need to use the NORECORD argument will have to get more complicated. We might, if anything, give up using that argument, since it doesn't seem to be very important in the codes in question actually. It also might suggest that such arguments that are not indispensable and are incompatible with versions of Emacsen will be doomed to be not used. So, I think we have nothing to do for `pop-to-buffer'. Regards, ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread 2007-08-16 1:54 ` Katsumi Yamaoka @ 2007-08-16 18:39 ` Richard Stallman 2007-08-17 1:22 ` Katsumi Yamaoka 0 siblings, 1 reply; 8+ messages in thread From: Richard Stallman @ 2007-08-16 18:39 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: emacs-devel I worry that changing the arguments list of such a generic function in Emacs causes further confusion. I think that compatibility in the long term will do more good than the short-term confusion. We might, if anything, give up using that argument, since it doesn't seem to be very important in the codes in question actually. That means that Gnus can easily avoid being affected the confusion. Right? So I conclude it is ok to change this. It also might suggest that such arguments that are not indispensable and are incompatible with versions of Emacsen will be doomed to be not used. I think that an arg which is compatible between future Emacs versions and XEmacs could be used easily enough, when there is a need to use it. So I tend to think we should go ahead with this change, unless there is some other reason not to. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gnus-summary-catchup turns ticked into unread 2007-08-16 18:39 ` Richard Stallman @ 2007-08-17 1:22 ` Katsumi Yamaoka 0 siblings, 0 replies; 8+ messages in thread From: Katsumi Yamaoka @ 2007-08-17 1:22 UTC (permalink / raw) To: rms; +Cc: emacs-devel >>>>> Richard Stallman wrote: > I worry that changing the arguments list of such a generic function > in Emacs causes further confusion. > I think that compatibility in the long term will do more good > than the short-term confusion. > We might, if anything, give up using that argument, since it doesn't > seem to be very important in the codes in question actually. > That means that Gnus can easily avoid being affected the confusion. > Right? Indeed. I agreed with you, and made changes in Gnus so as not to use the NORECORD argument in `pop-to-buffer's. (The changes will be merged into Emacs soon.) > So I conclude it is ok to change this. > It also > might suggest that such arguments that are not indispensable and are > incompatible with versions of Emacsen will be doomed to be not used. > I think that an arg which is compatible between future Emacs versions > and XEmacs could be used easily enough, when there is a need to use it. You're right. It's much better than we do nothing. > So I tend to think we should go ahead with this change, > unless there is some other reason not to. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-08-17 1:22 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-02 16:09 gnus-summary-catchup turns ticked into unread Luc Van Eycken
2007-07-03 10:25 ` Katsumi Yamaoka
2007-07-04 10:10 ` Katsumi Yamaoka
[not found] ` <E1I6GBH-0006d2-HI@fencepost.gnu.org>
[not found] ` <b4mejjn1usy.fsf@jpl.org>
[not found] ` <E1I6Y2D-00062v-Iq@fencepost.gnu.org>
[not found] ` <b4mr6nhjgq1.fsf@jpl.org>
[not found] ` <E1I8Nlq-0000oX-F6@fencepost.gnu.org>
[not found] ` <b4mps2zzivn.fsf@jpl.org>
2007-08-06 14:22 ` Richard Stallman
2007-08-14 0:28 ` Richard Stallman
2007-08-16 1:54 ` Katsumi Yamaoka
2007-08-16 18:39 ` Richard Stallman
2007-08-17 1:22 ` Katsumi Yamaoka
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.