bug#36765: 27.0.50; gnus-group-split-setup should delay until Gnus has finished starting up

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> I think a simple solution would be to change the above to:
>>>
>>> (add-hook (if auto-update
>>> 	      'nnmail-pre-get-new-mail-hook
>>> 	    'gnus-started-hook)
>>> 	  'gnus-group-split-update)
>>>
>>> Ie, if auto-update isn't passed, only run the update once, at start time.
>>
>> I think that makes sense -- if it doesn't have to be called from
>> nnmail-pre-get-new-mail-hook; I'm not too familiar with that code.
>
> I think the idea is that if `auto-update' is nil, the update should only
> happen once, at start-up time. If it's t, it should happen every time
> before we check new mail (which will include start-up time, I think).
>
> Anyway, let me make sure this solves the user's error first.

Okay, I've heard back from the user. I think the proper solution is:

(add-hook (if auto-update
	      'gnus-get-top-new-news-hook
	    'gnus-read-newsrc-el-hook)
	  #'gnus-group-split-update)

The reasoning being:

The original 'nnmail-pre-get-new-mail-hook runs for all mail backends
*except* nnimap, so the update won't fire if the user only has nnimap
backends. 'gnus-get-top-new-news-hook should do just as well.

Originally I put the non-auto-update on the 'gnus-started-hook, but that
means the update happens *after* the first check for mail, which isn't
ideal. There's also the 'gnus-startup-hook, but that happens before the
newsrc-hashtb is built, so we'd get the same error.
'gnus-read-newsrc-el-hook seems to be the only hook that runs after the
hash table is built, but before new news is fetched.

WDYT?