emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Behavior of Gnus when called from an hyperlink


From: Sébastien Vauban
Subject: [Orgmode] Re: Behavior of Gnus when called from an hyperlink
Date: Sat, 17 Jul 2010 21:59:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Hi Nick and Tassilo,

Nick Dokos wrote:
> Tassilo Horn <address@hidden> wrote:
>> Sébastien Vauban <address@hidden> writes:
>> 
>>> If I understand well, it wasted all the time evaluating
>>>
>>> --8<---------------cut here---------------start------------->8---
>>>     (nth 1 gnus-command-method)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I can't understand anything from the above... Someone does?
>>
>> Not really. Picking the second element out of a list must not take 5
>> minutes! What's the value of `gnus-command-method' when this happens? One
>> SPC before the hang, that variable is evaluated and its contents are
>> printed to *Messages*.
>
> try single stepping to that point and evaluate the various expressions
> that enter into the computation. For example,
>
>>>      ;; Use `head' function.
>>>      ((fboundp head)
>>>       (setq res (funcall head article (gnus-group-real-name group)
>>>   ->                     (nth 1 gnus-command-method))))
>
> put the cursor after the closing paren of the (nth 1 gnus-command-method)
> form and type C-x C-e, after the closing paren of (gnus-group-real-name
> group) and do the same and after the closing paren of the (funcall ...) and
> do the same. Also perhaps after the head variable (between head and article)
> and do the same. Tassilo is right of course that (nth 1 gnus-command-method)
> should be trivial (unless nth has been redefined somehow and is trying to
> prove the Riemann hypothesis instead :-) ) -- but the cursor might be off by
> one and it's really the funcall that's taking all the time.

By carefully reading the article just sent by Erik (in another thread) about
Edebug, becoming aware of the cursor movements under stepping, I now can say
without error what *really* eats the time.

I effectively saw every parameter evaluated, every one after the other. Here
are the results:

- head :: nnimap-request-head
- article :: "<address@hidden>"
- (gnus-group-real-name group) :: "INBOX.mc"
- gnus-command-method :: (nnimap "mc"
                              (nnimap-address "mail.missioncriticalit.com")
                              (nnir-search-engine imap))
- (nth 1 gnus-command-method) :: "mc"
- (funcall nnimap-request-head "<address@hidden>" "INBOX.mc" "mc")
  results... after 5 mins... in ("INBOX.mc" . 28606)

So, that's not `nth' that took the time (as previously thought), but the
`funcall'.

What does the jury thinks of that?

Thanks a lot for your remote assistance!
  Seb

-- 
Sébastien Vauban




reply via email to

[Prev in Thread] Current Thread [Next in Thread]