Re: How to open a summary buffer reliable?

[Tassilo Horn <tassilo@member.fsf.org>]

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