Re: A T does not work in nnml ...

[Steinar Bang <sb@dod.no>]

>>>>> Steinar Bang <sb@dod.no>:

> Perhaps I should just set an edebug breakpoint in gnus-fetch-headers?
> Or will that also be called when setting up the nnir group and confuse
> things?

New emacs and new gnus-slave and then edebug instrumented
gnus-fetch-headers. 

It is called twice, first from gnus-warp-to-article (which returns.
That's why I get the single article I get in the target group after C-g):

  gnus-fetch-headers((13688))
  gnus-select-newsgroup("nntp+news.gmane.org:gmane.discuss" t (13688))
  gnus-summary-read-group-1("nntp+news.gmane.org:gmane.discuss" t t #<buffer *Summary nnir:((query . "gwene") (unique-id . "87vd492dr5.fsf"))*> nil (13688))
  nnir-warp-to-article()
  gnus-warp-to-article()
  gnus-summary-refer-thread(nil)
  call-interactively(gnus-summary-refer-thread nil nil)

Then it's called from the end of gnus-summary-refer-thread where it gets
stuck: 
  gnus-fetch-headers((13765) 200 t)
  gnus-summary-refer-thread(nil)
  call-interactively(gnus-summary-refer-thread nil nil)

This time it gets stuck in the last line here:
	    (gnus-get-newsgroup-headers-xover
	     articles force-new dependencies gnus-newsgroup-name t)

I guess gnus-get-newsgroup-headers-xover is the next candidate for an
edebug instrumentation...