How to open a summary buffer reliable?

How to open a summary buffer reliable?

[Tassilo Horn]

Hi,

for following org-mode links to articles in Gnus, I need a way to open a
summary buffer.  Currently I use

        (gnus-group-read-group 1 nil group),

but that fails if the user deleted the last message in the group.
Replacing the 1 with a t isn't too good either, cause then the user
could give a number smaller than the deleted last articles and summary
won't be entered.

So is there another way to do that?  I'd be fine to open an empty
summary.  Directly after entering I select the linked article with

          (gnus-summary-goto-article article nil t)

anyway.

Bye,
Tassilo

Re: How to open a summary buffer reliable?

[Reiner Steib]

On Wed, Dec 10 2008, Tassilo Horn wrote:

> for following org-mode links to articles in Gnus, I need a way to open a
> summary buffer.  

> Currently I use
>
>         (gnus-group-read-group 1 nil group),
[...]
> Directly after entering I select the linked article with
>
>           (gnus-summary-goto-article article nil t)
>
> anyway.

I'm not sure if that there is a 100% reliable way (e.g. for empty
groups I'm not aware of any possibility).  Are you sure that you
really need to enter the group?  Maybe it someone can come up with an
idea if you describe what you want to achieve in org-mode finally.  (I
don't use org-mode myself (yet), so my questions might be silly.)

Maybe also gnus-group-quick-select-group and
gnus-group-select-group-ephemerally are useful.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: How to open a summary buffer reliable?

[Tassilo Horn]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

Hi Reiner,

> I'm not sure if that there is a 100% reliable way (e.g. for empty
> groups I'm not aware of any possibility).

There cannot be a (working) link to a message in an empty group, so
that's no issue here.

> Are you sure that you really need to enter the group?  Maybe it
> someone can come up with an idea if you describe what you want to
> achieve in org-mode finally.  (I don't use org-mode myself (yet), so
> my questions might be silly.)

I have a group name (i.e. "nnimap+Foo:bar.baz") and a message-id.  Now I
want to open a summary buffer which contains the article with that
message-id, and the article should be displayed in an article buffer.

The message-id is optional.  If none is given only the group's summary
should be shown.  In that case the "how many articles" question is ok,
of course.

> Maybe also gnus-group-quick-select-group and

Nice (because it's quick), but it has the same problem as the "slow"
version.

> gnus-group-select-group-ephemerally are useful.

No, that one's not good.  The user should be able to modify the linked
article.  (Maybe someone makes "delete that message on christmas"
links.)

Bye,
Tassilo

Re: How to open a summary buffer reliable?

[David Engster]

Tassilo Horn <tassilo@member.fsf.org> writes:
> for following org-mode links to articles in Gnus, I need a way to open a
> summary buffer.  Currently I use
>
>         (gnus-group-read-group 1 nil group),
>
> but that fails if the user deleted the last message in the group.

If you rescan the group before entering, Gnus should notice that the
article got deleted. You can do this by using gnus-activate-group with
`scan' being non-nil. 

Alternatively, you could request (1- gnus-large-newsgroup) articles so
that the user does not get asked.

-David

Re: How to open a summary buffer reliable?

[Tassilo Horn]

David Engster <deng@randomsample.de> writes:

Hi David,

> If you rescan the group before entering, Gnus should notice that the
> article got deleted. You can do this by using gnus-activate-group with
> `scan' being non-nil.

Hey, that seems to work!

> Alternatively, you could request (1- gnus-large-newsgroup) articles so
> that the user does not get asked.

Yeah, but I thing it's preferable to load as few articles as possible,
ideally only the linked one.

Thanks a lot,
Tassilo

Re: How to open a summary buffer reliable?

[Tassilo Horn]

Tassilo Horn <tassilo@member.fsf.org> writes:

>> If you rescan the group before entering, Gnus should notice that the
>> article got deleted. You can do this by using gnus-activate-group
>> with `scan' being non-nil.
>
> Hey, that seems to work!

I was a bit too quick.  It does work for nnimap groups, but I get an
error for nnml groups.

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("^[^:]+:" nil)
  gnus-request-article("<20080825064634.61290@gmx.net>" nil)
  gnus-request-head("<20080825064634.61290@gmx.net>" nil)
  gnus-read-header("<20080825064634.61290@gmx.net>")
  gnus-summary-insert-subject("<20080825064634.61290@gmx.net>")
  byte-code("[snipped control chars]" [gnus-override-method --cl-dolist-temp-- message-id number gnus-refer-article-methods nil gnus-check-server gnus-summary-insert-subject gnus-summary-select-article throw found t gnus-message 3 "Couldn't fetch article %s"] 6)
  gnus-summary-refer-article("<20080825064634.61290@gmx.net>")
  gnus-summary-goto-article("<20080825064634.61290@gmx.net>" nil t)
  (cond ((and group article) (gnus-activate-group group t) (gnus-group-read-group 1 nil group) (gnus-summary-goto-article article nil t)) (group (gnus-group-jump-to-group group)))
  org-gnus-follow-link("nnml+Popmail:misc" "<20080825064634.61290@gmx.net>")
  (let (group article) (if (not ...) (error "Error in Gnus link")) (setq group (match-string 1 path) article (match-string 3 path)) (when group (setq group ...)) (when article (setq article ...)) (org-gnus-follow-link group article))
  org-gnus-open(#("nnml+Popmail:misc#<20080825064634.61290@gmx.net>" 0 48 (org-attr nil)))
  org-open-at-point(nil)
  call-interactively(org-open-at-point nil nil)
--8<---------------cut here---------------end--------------->8---

Doing things manually after (gnus-activate-group "nnml+Foo:bar" t) a
`C-u 1 RET' won't enter that group, too.  So I guess the error comes
from the fact that the group's summary wasn't created.

So is that a bug in nnml or is it correct that only nnimap supports it?
Ideally I'd love to see that work for all backends supporting deletion.

Bye,
Tassilo

Re: How to open a summary buffer reliable?

[David Engster]

Tassilo Horn <tassilo@member.fsf.org> writes:
>>> If you rescan the group before entering, Gnus should notice that the
>>> article got deleted. You can do this by using gnus-activate-group
>>> with `scan' being non-nil.
>>
>> Hey, that seems to work!
>
> I was a bit too quick.  It does work for nnimap groups, but I get an
> error for nnml groups.
[...]
> Doing things manually after (gnus-activate-group "nnml+Foo:bar" t) a
> `C-u 1 RET' won't enter that group, too.  So I guess the error comes
> from the fact that the group's summary wasn't created.
> So is that a bug in nnml or is it correct that only nnimap supports it?

I guess the beloved gnus-fixup-nnimap-unread-after-getting-new-news
makes this work with nnimap, but not with nnml. I don't know how other
back ends behave in this regard.

> Ideally I'd love to see that work for all backends supporting deletion.

This is all related to Gnus not knowing the actual article numbers. We
discussed how this could be solved in August, based on Vitaly
Mayatskikh's patches. Unfortunately, I didn't have time since then to
work on this...

nnml is tricky since it tries to avoid rebuilding the active
information, this is why it usually recognizes this situation only after
restarting Gnus. You can force rebuilding the active file by using
nnml-generate-nov-databases-directory (which can be costly for large
groups). This function expects a directory, not the group name, so you
would have to extract that first. And then you would have to put this
information in gnus-active-hashtb, maybe also in the cache via
gnus-cache-possibly-update-active (maybe they're the same, I don't
really know).

Looks like work; maybe someone else knows how to do this easier?

-David

Re: How to open a summary buffer reliable?

[Tassilo Horn]

David Engster <deng@randomsample.de> writes:

>> So is that a bug in nnml or is it correct that only nnimap supports
>> it?
>
> I guess the beloved gnus-fixup-nnimap-unread-after-getting-new-news
> makes this work with nnimap, but not with nnml. I don't know how other
> back ends behave in this regard.

Ok.

>> Ideally I'd love to see that work for all backends supporting
>> deletion.
>
> This is all related to Gnus not knowing the actual article numbers.

Yes, I've thought that.

> nnml is tricky since it tries to avoid rebuilding the active
> information, this is why it usually recognizes this situation only
> after restarting Gnus. You can force rebuilding the active file by
> using nnml-generate-nov-databases-directory (which can be costly for
> large groups). This function expects a directory, not the group name,
> so you would have to extract that first. And then you would have to
> put this information in gnus-active-hashtb, maybe also in the cache
> via gnus-cache-possibly-update-active (maybe they're the same, I don't
> really know).
>
> Looks like work; maybe someone else knows how to do this easier?

That's what I'm doing now:

--8<---------------cut here---------------start------------->8---
	 (gnus-activate-group group t)
	 (unless (gnus-group-read-group 1 nil group)
	   ;; Try again with a bigger number of messages.
	   (gnus-group-read-group (1- gnus-large-newsgroup) nil group))
	 (gnus-summary-goto-article article nil t))
--8<---------------cut here---------------end--------------->8---

Ok, it won't work if the user deleted the last (1- gnus-large-newsgroup)
articles, but how common is that?

I think I can live with that workaround unless somebody finds a proper
solution.

Bye,
Tassilo