Hi, When I exit a group, the unread count in the topic it is under doesn't update. If I collapse the topic, the count gets updated. That's cool. Is there a way to get Gnus to update the counts automatically on group exit as well? The speed of Emacs these days makes me think I don't mind Gnus doing the the extra work. Best regards, Adam -- "Sunday morning when the rain begins to fall Adam Sjøgren I believe I have seen the end of it all" asjo@koldfront.dk
Adam Sjøgren <asjo@koldfront.dk> writes:
> Hi,
>
>
> When I exit a group, the unread count in the topic it is under doesn't
> update.
>
> If I collapse the topic, the count gets updated. That's cool.
>
> Is there a way to get Gnus to update the counts automatically on group
> exit as well?
It looks to me like you could add a function to
`gnus-summary-exit-hook', which calls
`gnus-topic-update-topics-containing-group' on the value of
`gnus-newsgroup-name'. At that stage in summary exit,
`gnus-newsgroup-name' won't have been cleared yet, so it should still
hold the name of the group you're coming out of.
Eric writes: >> Is there a way to get Gnus to update the counts automatically on group >> exit as well? > It looks to me like you could add a function to > `gnus-summary-exit-hook', which calls > `gnus-topic-update-topics-containing-group' on the value of > `gnus-newsgroup-name'. At that stage in summary exit, > `gnus-newsgroup-name' won't have been cleared yet, so it should still > hold the name of the group you're coming out of. Any reason for Gnus not to do that by default? I hacked this together before reading your suggestion: (defun asjo-update-topics () (let ((pos (point))) (beginning-of-buffer) (gnus-topic-read-group) (gnus-topic-read-group) (goto-char pos))) (add-hook 'gnus-summary-exit-hook 'asjo-update-topics) Which just toggles the top-level topic, which has the side effect of updating the counts. I couldn't make save-mark-and-excursion work, so I did the point + goto-char dance, which is a little icky. I will see if I can get your suggestion going after dinner :-) Thanks! Best regards, Adam -- "Our voodoo-dolls are full of hopes" Adam Sjøgren asjo@koldfront.dk
Adam writes: > Eric writes: > >> It looks to me like you could add a function to >> `gnus-summary-exit-hook', which calls >> `gnus-topic-update-topics-containing-group' on the value of >> `gnus-newsgroup-name'. At that stage in summary exit, >> `gnus-newsgroup-name' won't have been cleared yet, so it should still >> hold the name of the group you're coming out of. [...] > I will see if I can get your suggestion going after dinner :-) This is what I did: (defun asjo-update-topics () (gnus-topic-update-topics-containing-group gnus-newsgroup-name)) (add-hook 'gnus-summary-exit-hook 'asjo-update-topics) But simpler than my hack - but nothing is updated. When I edebug-defun it, I can see that gnus-newsgroup-name is indeed the full newsgroup name, e.g. "nntp+gm:gmane.emacs.gnus.user", but the topic counts aren't updated. Best regards, Adam -- "The code is more what you'd call 'guidelines', Adam Sjøgren than actual rules." asjo@koldfront.dk
Adam Sjøgren <asjo@koldfront.dk> writes: > Eric writes: > >>> Is there a way to get Gnus to update the counts automatically on group >>> exit as well? > >> It looks to me like you could add a function to >> `gnus-summary-exit-hook', which calls >> `gnus-topic-update-topics-containing-group' on the value of >> `gnus-newsgroup-name'. At that stage in summary exit, >> `gnus-newsgroup-name' won't have been cleared yet, so it should still >> hold the name of the group you're coming out of. > > Any reason for Gnus not to do that by default? I can't think of any reason off the top of my head. It's not like it's such a costly procedure. gnus-topic is a little fiddly about how it hooks into the rest of the Gnus machinery, but it shouldn't be hard to figure out. > I will see if I can get your suggestion going after dinner :-) It ought to work without the hacky dance, but I'll be curious to hear!
Adam Sjøgren <asjo@koldfront.dk> writes:
> Adam writes:
>
>> Eric writes:
>>
>>> It looks to me like you could add a function to
>>> `gnus-summary-exit-hook', which calls
>>> `gnus-topic-update-topics-containing-group' on the value of
>>> `gnus-newsgroup-name'. At that stage in summary exit,
>>> `gnus-newsgroup-name' won't have been cleared yet, so it should still
>>> hold the name of the group you're coming out of.
>
> [...]
>
>> I will see if I can get your suggestion going after dinner :-)
>
> This is what I did:
>
> (defun asjo-update-topics ()
> (gnus-topic-update-topics-containing-group gnus-newsgroup-name))
>
> (add-hook 'gnus-summary-exit-hook 'asjo-update-topics)
>
> But simpler than my hack - but nothing is updated.
>
> When I edebug-defun it, I can see that gnus-newsgroup-name is indeed the
> full newsgroup name, e.g. "nntp+gm:gmane.emacs.gnus.user", but the topic
> counts aren't updated.
And if I'd looked at that function before recommending it, I would have
immediately seen that it's buggy! That and `gnus-topic-update-topic'
check to see if the major-mode is 'gnus-topic-mode, which of course it
never is, because gnus-topic-mode is a minor mode.
In fact, gnus-topic.el already thinks it's doing what you want --
updating topic lines on group exit -- but because of the bug in
`gnus-topic-update-topic', the update never happens.
Lars added that major-mode check as part of a larger commit last year, I
have to assume it was a mistake. I'll remove the checks now.
Eric
Eric writes: > In fact, gnus-topic.el already thinks it's doing what you want -- > updating topic lines on group exit -- but because of the bug in > `gnus-topic-update-topic', the update never happens. Oooh, cool, I didn't remember that it used to work ;-) > Lars added that major-mode check as part of a larger commit last year, I > have to assume it was a mistake. I'll remove the checks now. Nice piece of debugging! However, I think you broke something? When I try to q out of a group I now get: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p t) gnus-topic-find-groups("feedwork" 5 nil t) gnus-topic-update-topic-line("feedwork") gnus-topic-update-topics-containing-group("nntp+fb:feedbase.blog.inspiredpython") gnus-group-update-group("nntp+fb:feedbase.blog.inspiredpython" nil t) gnus-summary-update-info() gnus-summary-exit() funcall-interactively(gnus-summary-exit) command-execute(gnus-summary-exit) (when toggle-debug-on-error is on, and I have removed my hook). Best regards, Adam -- "The world is short of delimiters," says Don. Adam Sjøgren asjo@koldfront.dk
Eric writes:
> I'll remove the checks now.
The line the error is triggered in is:
(defun gnus-topic-update-topic-line (topic-name &optional reads)
(let* ((top (gnus-topic-find-topology topic-name))
(type (cadr top))
(children (cddr top))
(entries (gnus-topic-find-groups
(car type) (car gnus-group-list-mode)
(cdr gnus-group-list-mode)))
(all-groups (gnus-topic-find-groups
(car type) (car gnus-group-list-mode)
(cdr gnus-group-list-mode) t)) <------ HERE
(parent (gnus-topic-parent-topic topic-name))
gnus-topic-find-groups: Wrong type argument: number-or-marker-p, t
gnus-group-list-mode is (5) here, so the cdr is nil, and
gnus-topic-find-groups doesn't like that, apparently. I didn't have time
to step through that to pinpoint it further.
Best regards,
Adam
--
"*We* focus on doing nothing at all!" Adam Sjøgren
asjo@koldfront.dk
Adam Sjøgren <asjo@koldfront.dk> writes:
> Eric writes:
>
>> I'll remove the checks now.
>
> The line the error is triggered in is:
>
> (defun gnus-topic-update-topic-line (topic-name &optional reads)
> (let* ((top (gnus-topic-find-topology topic-name))
> (type (cadr top))
> (children (cddr top))
> (entries (gnus-topic-find-groups
> (car type) (car gnus-group-list-mode)
> (cdr gnus-group-list-mode)))
> (all-groups (gnus-topic-find-groups
> (car type) (car gnus-group-list-mode)
> (cdr gnus-group-list-mode) t)) <------ HERE
> (parent (gnus-topic-parent-topic topic-name))
>
> gnus-topic-find-groups: Wrong type argument: number-or-marker-p, t
>
> gnus-group-list-mode is (5) here, so the cdr is nil, and
> gnus-topic-find-groups doesn't like that, apparently. I didn't have time
> to step through that to pinpoint it further.
Looks like Dick Chiang has already opened a bug report containing the
fix, so expect this to work Real Soon Now.
Eric writes:
> Looks like Dick Chiang has already opened a bug report containing the
> fix, so expect this to work Real Soon Now.
That fixed it - great, thanks!
Best regards,
Adam
--
"Referring to glorified travelling salesmen Adam Sjøgren
as ``road warriors'' is an insult to asjo@koldfront.dk
gun-toting nomadic mercenaries everywhere."