Tassilo Horn writes:
> Well, as a last resort that could be done, but I'm in favor of
> delegating the issue to the Gnus devs. The problem will bite you in
> normal Gnus usage, too. (Ok, at least when searching for/restricting
> with a given message id. Scoring is also a candidate using
> mess
David Maus writes:
Hi David,
>>I'm not sure, but I think the gnus registry caches message-ids and
>>other information. Maybe, that could speed things up a bit.
>
> After toying arround with Gnus at the weekend: Yes, there is .overview
> in ~/News/agent/nnimap/// that contains UIDs and (among
>
Tassilo Horn wrote:
>Sébastien Vauban
>writes:
>>> This is the point where I conclude that there can't be done anything
>>> about it except modifying Gnus' cache mechanism.[2]
>>
>> Do you think that would happen? Are there people aware of this, and
>> willing to do such a change?
>I'm not sure
Hi Tassilo and Giovanni,
Tassilo Horn wrote:
> On Friday 23 July 2010 10:54:24 Giovanni Ridolfi wrote:
>>> And I like being able to restrict the message list incrementally by
>>> simply entering parts of the author name or subject. Gnus cannot do
>>> that.
>>
>> may be ths can help:
>>
>> 1. cur
On Friday 23 July 2010 10:54:24 Giovanni Ridolfi wrote:
> > And I like being able to restrict the message list incrementally by
> > simply entering parts of the author name or subject. Gnus cannot do
> > that.
> may be ths can help:
>
> 1. cursor in the "Summary message" buffer
>
> # let's rest
Tassilo Horn writes:
> And I like being able to restrict the message list incrementally by
> simply entering parts of the author name or subject. Gnus cannot do
> that.
may be ths can help:
1. cursor in the "Summary message" buffer
# let's restrict to headers:
2. / h $the-header-you-like
Sébastien Vauban
writes:
Hi Sébastien,
>>> Even if feasable, doing your way seems to add a layer of complexity
>>> to the installation... Would you have config to share, would I go
>>> that way?
>>
>> Sure, but be aware that I don't use that setup anymore.
>
> Thanks a lot for the detailed infor
Hi Matt,
Matt Lundin wrote:
> Tassilo Horn writes:
>> Sébastien Vauban writes:
>>
>>> Even if feasable, doing your way seems to add a layer of complexity to the
>>> installation... Would you have config to share, would I go that way?
>>
>> Here's my .offlineimaprc. It synched from 2 different a
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban writes:
>
>> Even if feasable, doing your way seems to add a layer of complexity to the
>> installation... Would you have config to share, would I go that way?
>
> Sure, but be aware that I don't use that setup anymore.
Thanks a lot for the deta
Sébastien Vauban
writes:
> Hi Bernt,
>
> Bernt Hansen wrote:
>> Mirroring your mail server with offline imap or some other tool and linking
>> to the local mirror might help your access times. I've never used that
>> myself but others have reported success with this.
>
> I am (or was) a bit rel
Tassilo Horn writes:
> Sébastien Vauban
> writes:
>
>> Even if feasable, doing your way seems to add a layer of complexity to
>> the installation... Would you have config to share, would I go that
>> way?
>
> Sure, but be aware that I don't use that setup anymore.
>
> Here's my .offlineimaprc.
Sébastien Vauban
writes:
>> This is the point where I conclude that there can't be done anything
>> about it except modifying Gnus' cache mechanism.[2]
>
> Do you think that would happen? Are there people aware of this, and
> willing to do such a change?
I'm not sure, but I think the gnus regis
Sébastien Vauban
writes:
> Even if feasable, doing your way seems to add a layer of complexity to
> the installation... Would you have config to share, would I go that
> way?
Sure, but be aware that I don't use that setup anymore.
Here's my .offlineimaprc. It synched from 2 different accounts
Hi David,
David Maus wrote:
> Sébastien Vauban wrote:
>> What would be your pieces of advice in such a case? Do I need to test
>> something extra? Get a local imap server? Others (like asking for fixing
>> the search on our Courier mail server)?
>
> Well, IMO there might be nothing to "fix" on the
Hi Tassilo,
Tassilo Horn wrote:
> Bernt Hansen writes:
>> Mirroring your mail server with offline imap or some other tool and linking
>> to the local mirror might help your access times.
>
> If Sébastien's admins tell him that they cannot get the search faster, that
> would be a good investment.
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban writes:
>
>>> My main account uses Courier on Debian, too and search for a particular
>>> message id within ~7000 messages is quite fast.
>>
>> In my case, the culprit seems well to be our mail server, then.
>
> Yes, but not you've learned much a
Hi Bernt,
Bernt Hansen wrote:
> Sébastien Vauban writes:
>> David Maus wrote:
>>> Tassilo Horn wrote:
>> [...@mundaneum] />nc -vv mail imap
>>
>> Did twice the same request. Did take twice 5 mins...
>>
>> In my case, the culprit seems well to be our mail server, then.
>>
>> Maybe a problem is that
Bernt Hansen writes:
Hi Bernt,
> I have an IMAP server on my local 100MB/sec network and one of my
> (spam) folders has 148200 messages in it. If I link to one of those
> messages in Gnus, close Gnus, and access the link from org-mode it
> finds the email in 13 seconds (8 seconds if Gnus is alr
Sébastien Vauban
writes:
> Hi David, Tassilo and Nick,
>
> David Maus wrote:
>> Tassilo Horn wrote:
> [...@mundaneum] />nc -vv mail imap
> Did twice the same request. Did take twice 5 mins...
> In my case, the culprit seems well to be our mail server, then.
>
>> Couldn't find this information
Sébastien Vauban
writes:
Hi Sébastien,
>> My main account uses Courier on Debian, too and search for a
>> particular message id within ~7000 messages is quite fast.
>
> In my case, the culprit seems well to be our mail server, then.
Yes, but not you've learned much about profiling and debugging
Sébastien Vauban wrote:
>What would be your pieces of advice in such a case? Do I need to test
>something extra? Get a local imap server? Others (like asking for fixing the
>search on our Courier mail server)?
Well, IMO there might be nothing to "fix" on the server side.
Although a user might expe
Hi David, Tassilo and Nick,
David Maus wrote:
> Tassilo Horn wrote:
>> Please check, if that function is that slow for all message-ids or if
>> that's only for some. The function has a "FIXME: Should this try to use
>> CHARSET? -- fx", and maybe this answer has to be answered with Yes!
>
> I think
Tassilo Horn wrote:
>> I guess I will have to dive that side (not now -- going to sleep).
>> Don't know if that gives hints yet, or not...
>Please check, if that function is that slow for all message-ids or if
>that's only for some. The function has a "FIXME: Should this try to use
>CHARSET? --
Sébastien Vauban
writes:
Hi Sébastien,
> The function `nnimap-request-article-part' gets called several times.
>
> --8<---cut here---start->8---
> (defun nnimap-request-article-part (article part prop &optional
> group
Nick, Tassilo,
> Nick Dokos wrote:
>> =?utf-8?Q?S=C3=A9bastien_Vauban?= wrote:
>>
>>> - (funcall nnimap-request-head
>>> "<871vbxzo6@mundaneum.com>" "INBOX.mc"
>>> "mc") results... after 5 mins... in ("INBOX.mc" . 28606)
>>>
>>> What does the jury thinks of that?
>>
>> You've got a few mor
Hi Nick,
Nick Dokos wrote:
> =?utf-8?Q?S=C3=A9bastien_Vauban?= wrote:
>
>> - (funcall nnimap-request-head "<871vbxzo6@mundaneum.com>" "INBOX.mc"
>> "mc") results... after 5 mins... in ("INBOX.mc" . 28606)
>>
>> What does the jury thinks of that?
>
> You've got a few more layers of elisp to
=?utf-8?Q?S=C3=A9bastien_Vauban?= wrote:
> 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, ev
Hi Nick and Tassilo,
Nick Dokos wrote:
> Tassilo Horn wrote:
>> Sébastien Vauban writes:
>>
>>> If I understand well, it wasted all the time evaluating
>>>
>>> --8<---cut here---start->8---
>>> (nth 1 gnus-command-method)
>>> --8<---cut here--
Tassilo Horn wrote:
> Sébastien Vauban
> writes:
>
> Hi Sébastien,
>
> > When stepping with SPC, the "arrow mark" (in the left fringe) stayed 5
> > mins on line 487:
> >
> > --8<---cut here---start->8---
> > ;; Use `head' function.
> > ((fboundp he
Sébastien Vauban
writes:
Hi Sébastien,
> When stepping with SPC, the "arrow mark" (in the left fringe) stayed 5
> mins on line 487:
>
> --8<---cut here---start->8---
> ;; Use `head' function.
> ((fboundp head)
> (setq res (funcall head article
Hi Tassilo,
> Tassilo Horn wrote:
>> Sébastien Vauban writes:
>>
>>> I've followed Nick's procedure, hoping to get even more details:
>>>
>>> --8<---cut here---start->8---
>>> Function Name Call Count Elapsed Time Average Time
>>> ...
>>> gnus-
Hi Nick,
Nick Dokos wrote:
> Sébastien Vauban wrote:
>> Tassilo Horn wrote:
>>> Sébastien Vauban writes:
>>>
I've followed Nick's procedure, hoping to get even more details:
--8<---cut here---start->8---
Function Name Call
Sébastien Vauban wrote:
> Hi Tassilo,
>
> Tassilo Horn wrote:
> > Sébastien Vauban writes:
> >
> >> I've followed Nick's procedure, hoping to get even more details:
> >>
> >> --8<---cut here---start->8---
> >> Function Name Call Count Elapse
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban writes:
>
>> I've followed Nick's procedure, hoping to get even more details:
>>
>> --8<---cut here---start->8---
>> Function Name Call Count Elapsed Time Average Time
>> ...
>> gnus-request-h
Sébastien Vauban
writes:
Hi Sébastien,
> I've followed Nick's procedure, hoping to get even more details:
>
> --8<---cut here---start->8---
> Function Name Call Count Elapsed Time Average Time
> ...
> gnus-request-head 1
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban writes:
>
> that is takes so long for one group but the other group on the same server
> is fast is really strange, and currently I don't understand what might cause
> that... :-(
>
>>> Profile the gnus code as it processes the two requests? The
Carsten Dominik writes:
> do we have an agreement that the default frame setup for gnus should
> be org-gnus-no-new-news?
Yes.
-Bernt
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://list
Carsten Dominik writes:
> do we have an agreement that the default frame setup for gnus should be
> org-gnus-no-new-news?
+1 (FWIW)
--
Bastien
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
On 2010-07-02 05:44 +0100, Carsten Dominik wrote:
> Hi,
>
> do we have an agreement that the default frame setup for gnus should
> be org-gnus-no-new-news?
>
> - Carsten
I vote for it.
Leo
___
Emacs-orgmode mailing list
Please use `Reply All' to send r
Hi,
do we have an agreement that the default frame setup for gnus should
be org-gnus-no-new-news?
- Carsten
On Jun 30, 2010, at 12:12 PM, Noorul Islam K M wrote:
Carsten Dominik writes:
On Jun 28, 2010, at 1:36 PM, Leo wrote:
On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
(setq org-l
Carsten Dominik writes:
> On Jun 28, 2010, at 1:36 PM, Leo wrote:
>
>> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>>> (gnus . org-gnus-no-new-news)
>>> (file . find-file-other-win
Sébastien Vauban
writes:
Hi Sébastien,
that is takes so long for one group but the other group on the same
server is fast is really strange, and currently I don't understand what
might cause that... :-(
>> Profile the gnus code as it processes the two requests? The
>> differences should be tell
Sébastien Vauban wrote:
> >> I really don't understand the problem.
> >
> > Profile the gnus code as it processes the two requests? The differences
> > should
> > be telling.
>
> Could you just give me a hint (function name or so) or a place to look for
> some info on how to do that?
>
I 've
Hi Nick,
Nick Dokos wrote:
> Sébastien Vauban wrote:
>
>> > (setq gnus-use-cache nil)
>>
>> I've updated it to `t'.
>>
>> ...
>>
>> Rest stayed as it was.
>>
>> I've read the couple of mails I was linking to. I've restarted Emacs (and
>> Gnus) a couple of times.
>>
>> No change.
>>
>> It st
Sébastien Vauban wrote:
> > (setq gnus-use-cache nil)
>
> I've updated it to `t'.
>
> ...
>
> Rest stayed as it was.
>
> I've read the couple of mails I was linking to. I've restarted Emacs (and
> Gnus) a couple of times.
>
> No change.
>
> It still takes around 5 mins to find the mail in m
Carsten Dominik writes:
> On Jun 28, 2010, at 1:36 PM, Leo wrote:
>
>> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>>> (gnus . org-gnus-no-new-news)
>>> (file . find-file-other-wi
Hi Tassilo,
Sébastien Vauban wrote:
> Tassilo Horn wrote:
>> Sébastien Vauban
>> writes:
>>>
>>> - a new buffer is opened (group where the mail belongs to), but it takes
>>> ages (in minutes) for the mail to be found and opened -- when it is.
>>
>> I've just tried it with a nntp group and link
Carsten Dominik writes:
> On Jun 28, 2010, at 1:36 PM, Leo wrote:
>
>> On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
>>> (setq org-link-frame-setup '((vm . vm-visit-folder)
>>> (gnus . org-gnus-no-new-news)
>>> (file . find-file-other-win
Hi Tassilo,
Tassilo Horn wrote:
> Sébastien Vauban writes:
>>
>> - a new frame is opened
>>
>> Besides that I more or less hate frames, it becomes annoying when used in
>> my StumpWM config: I now have *two* Emacs full screen, and I loose my
>> "single window of control" view.
>
> That's be
On Jun 28, 2010, at 1:36 PM, Leo wrote:
On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
(setq org-link-frame-setup '((vm . vm-visit-folder)
(gnus . org-gnus-no-new-news)
(file . find-file-other-window)))
Nice.
I have also found creati
On 2010-06-28 11:19 +0100, Tassilo Horn wrote:
> (setq org-link-frame-setup '((vm . vm-visit-folder)
> (gnus . org-gnus-no-new-news)
> (file . find-file-other-window)))
Nice.
I have also found creating new frame a bit annoying because I
Sébastien Vauban
writes:
Hi Sébastien,
> - a new frame is opened
>
> Besides that I more or less hate frames, it becomes annoying when
> used in my StumpWM config: I now have *two* Emacs full screen, and I
> loose my "single window of control" view.
That's because the default value of org
52 matches
Mail list logo
