gnus-summary-catchup turns ticked into unread

gnus-summary-catchup turns ticked into unread

[Luc Van Eycken]

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

Re: gnus-summary-catchup turns ticked into unread

[Katsumi Yamaoka]

[-- 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

Re: gnus-summary-catchup turns ticked into unread

[Katsumi Yamaoka]

>>>>>> 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

Re: gnus-summary-catchup turns ticked into unread

[Richard Stallman]

    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?

Re: gnus-summary-catchup turns ticked into unread

[Richard Stallman]

[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?

Re: gnus-summary-catchup turns ticked into unread

[Katsumi Yamaoka]

>>>>> 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,

Re: gnus-summary-catchup turns ticked into unread

[Richard Stallman]

    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.

Re: gnus-summary-catchup turns ticked into unread

[Katsumi Yamaoka]

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