NNSelect Failing

NNSelect Failing

[T.V Raman]

So as an example:

In the groups buffer,
If I search for
from: rms after: 2020/01/01
for the emacs-devel mail archive (personal gmail) using imap, emacs
28.0.50 no longer returns anything; more generally, all queries report
a message of the form:

Group nnselect:nnselect-p91v9d01j5e.fsf contains no messages

-- 

Thanks,

--Raman
♉ Id: kg:/m/0285kf1  🦮

-- 

Thanks,

--Raman
♉ Id: kg:/m/0285kf1  🦮

Re: NNSelect Failing

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> So as an example:
>
> In the groups buffer,
> If I search for
> from: rms after: 2020/01/01

If this is the exact query you're issuing, there shouldn't be spaces
after the colons.

Or maybe first make sure it works with `gnus-search-use-parsed-queries'
set to nil, and plain IMAP search strings?

> for the emacs-devel mail archive (personal gmail) using imap, emacs
> 28.0.50 no longer returns anything; more generally, all queries report
> a message of the form:
>
> Group nnselect:nnselect-p91v9d01j5e.fsf contains no messages

There's an ongoing issue wherein nnselect downgrades all errors to
warnings, and returns this result if anything goes wrong. If you turn
gnus-verbose up a bit (I think above 3) and try again, there might be
real errors in *Messages*.

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1211 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

the search query syntax I used is correct, it matches what gmail uses
and has worked flawlessly for many years until last week. Were there any
changes made since our last exchange of messages a couple of weeks or so
ago?
> "T.V Raman" <raman@google.com> writes:
>
>> So as an example:
>>
>> In the groups buffer,
>> If I search for
>> from: rms after: 2020/01/01
>
> If this is the exact query you're issuing, there shouldn't be spaces
> after the colons.
>
> Or maybe first make sure it works with `gnus-search-use-parsed-queries'
> set to nil, and plain IMAP search strings?
>
>> for the emacs-devel mail archive (personal gmail) using imap, emacs
>> 28.0.50 no longer returns anything; more generally, all queries report
>> a message of the form:
>>
>> Group nnselect:nnselect-p91v9d01j5e.fsf contains no messages
>
> There's an ongoing issue wherein nnselect downgrades all errors to
> warnings, and returns this result if anything goes wrong. If you turn
> gnus-verbose up a bit (I think above 3) and try again, there might be
> real errors in *Messages*.
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1245 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> "T.V Raman" <raman@google.com> writes:
p.s. gnus-verbose is presently 6.

Also in what you wrote, <cite>
> Or maybe first make sure it works with `gnus-search-use-parsed-queries'
> set to nil, and plain IMAP search strings?
</cite>
What exactly did you intend to say re plain imap string?

>
>> So as an example:
>>
>> In the groups buffer,
>> If I search for
>> from: rms after: 2020/01/01
>
> If this is the exact query you're issuing, there shouldn't be spaces
> after the colons.
>
> Or maybe first make sure it works with `gnus-search-use-parsed-queries'
> set to nil, and plain IMAP search strings?
>
>> for the emacs-devel mail archive (personal gmail) using imap, emacs
>> 28.0.50 no longer returns anything; more generally, all queries report
>> a message of the form:
>>
>> Group nnselect:nnselect-p91v9d01j5e.fsf contains no messages
>
> There's an ongoing issue wherein nnselect downgrades all errors to
> warnings, and returns this result if anything goes wrong. If you turn
> gnus-verbose up a bit (I think above 3) and try again, there might be
> real errors in *Messages*.
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> "T.V Raman" <raman@google.com> writes:
> p.s. gnus-verbose is presently 6.
>
> Also in what you wrote, <cite>
>> Or maybe first make sure it works with `gnus-search-use-parsed-queries'
>> set to nil, and plain IMAP search strings?
> </cite>
> What exactly did you intend to say re plain imap string?

Sorry, I wasn't sure whether you were searching with parsed queries
(`gnus-search-use-parsed-queries' -> t) or not.

Nothing has changed since our last exchange, no. Do you have
`nnir-imap-default-search-key' set to "gmail"? I may need to check for
that and leave the query alone.

Re: NNSelect Failing

[T.V Raman via Emacs development discussions.]

Yes on 
`nnir-imap-default-search-key' set to "gmail

Eric Abrahamsen writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > Eric Abrahamsen <eric@ericabrahamsen.net> writes:
 > >
 > >> "T.V Raman" <raman@google.com> writes:
 > > p.s. gnus-verbose is presently 6.
 > >
 > > Also in what you wrote, <cite>
 > >> Or maybe first make sure it works with `gnus-search-use-parsed-queries'
 > >> set to nil, and plain IMAP search strings?
 > > </cite>
 > > What exactly did you intend to say re plain imap string?
 > 
 > Sorry, I wasn't sure whether you were searching with parsed queries
 > (`gnus-search-use-parsed-queries' -> t) or not.
 > 
 > Nothing has changed since our last exchange, no. Do you have
 > `nnir-imap-default-search-key' set to "gmail"? I may need to check for
 > that and leave the query alone.

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: NNSelect Failing

[Eric Abrahamsen]

"T.V Raman" via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Yes on 
> `nnir-imap-default-search-key' set to "gmail

Okay, I'm going to need to restore a bit more of nnir's behavior than I
thought. This might take me a day or so to think through; in the
meantime you should be able to get a working search by prepending
the string "x-gm-raw " to your search queries. I'll followup here when
I've done a proper fix.

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 6122 bytes --]

I'm going to attach my gm-nnir.el module here so you can use it in
testing.

That module though short took a lot of tweaking to get working when I
originally wrote it, so it might also be useful when testing as you make
changes.

;;; gm-nnir.el --- Searching GMail Using NNIR  -*- lexical-binding: t; -*-
;;;$Id: gmaps.el 8157 2013-02-19 01:31:05Z tv.raman.tv $
;;; $Author: raman $
;;; Description:  GMail Search -> IMap -> NNIR -> Gnus
;;; Keywords: GMail, IMap, gnus
;;{{{  LCD Archive entry:

;;; LCD Archive Entry:
;;; gcal| T. V. Raman |tv.raman.tv@gmail.com
;;; An emacs interface to Reader|
;;; $Date: 2006/09/28 17:47:44 $ |
;;;  $Revision: 1.30 $ |
;;; Location undetermined
;;; License: GPL
;;;

;;}}}
;;{{{ Copyright:

;;; Copyright (c) 2006 and later, Google Inc.
;;; All rights reserved.

;;; Redistribution and use in source and binary forms, with or without modification,
;;; are permitted provided that the following conditions are met:

;;;     * Redistributions of source code must retain the above copyright notice,
;;;       this list of conditions and the following disclaimer.
;;;     * Redistributions in binary form must reproduce the above copyright notice,
;;;       this list of conditions and the following disclaimer in the documentation
;;;       and/or other materials provided with the distribution.
;;;     * The name of the author may not be used to endorse or promote products
;;;       derived from this software without specific prior written permission.

;;; THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
;;; AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
;;; IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
;;; ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
;;; LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
;;; CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
;;; GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
;;; HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
;;; STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
;;; WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
;;; SUCH DAMAGE.

;;}}}
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;{{{  introduction

;;; Commentary:
;;; Makes search GMail more convenient.
;;; IMap search operators, GMail search extensions.
;;; Code:

;;}}}
;;{{{  Required modules

(require 'cl-lib)
(cl-declaim  (optimize  (safety 0) (speed 3)))

(require 'nnir)
(require 'gnus-group)
;;}}}
;;{{{ IMap Search Operators:

;;; this list is extracted from the IMap RFC 3501
;;; And adds X-GM_RAW  for GMail specific search extensions.
;;; (mapcar 'split-string (split-string (buffer-substring-no-properties  (point-min) (point-max)) "\n"))
;;; with imap-search as the current buffer.

(defvar gm-nnir-search-criteria
  '(("BCC" "<string>")
    ("BEFORE" "<date>")
    ("BODY" "<string>")
    ("CC" "<string>")
    ("FROM" "<string>")
    ("HEADER" "<field-name>" "<string>")
    ("KEYWORD" "<flag>")
    ("LARGER" "<n>")
    ("NOT" "<search-key>")
    ("ON" "<date>")
    ("SENTBEFORE" "<date>")
    ("SENTON" "<date>")
    ("SENTSINCE" "<date>")
    ("SINCE" "<date>")
    ("SMALLER" "<n>")
    ("SUBJECT" "<string>")
    ("TEXT" "<string>")
    ("TO" "<string>")
    ("X-GM-RAW" "<string>")
    ("DELETED")
    ("DRAFT")
    ("FLAGGED")
    ("NEW")
    ("RECENT")
    ("UNANSWERED")
    ("UNDELETED")
    ("unseen")
    nil)  
  "IMap search criteria with argument specs.")

(defun gm-nnir-read-imap-clause ()
  "Read one IMap search clause with smart prompts."
  (cl-declare (special gm-nnir-search-criteria))
  (let*
      ((completion-ignore-case t)
       (key (upcase (completing-read "Search Clause" gm-nnir-search-criteria)))
       (args
        (when (cdr (assoc key gm-nnir-search-criteria))
          (read-from-minibuffer (mapconcat #'identity (cdr (assoc key gm-nnir-search-criteria))
                                           " ")))))
    (if (> (length key) 0)
        (format
         "%s %s" key
         (if args (format "\"%s\"" args) ""))
      "")))

(defun gm-nnir-read-imap-query ()
  "Return query built from a set of clauses."
  (let ((query nil)
        (clause (gm-nnir-read-imap-clause)))
    (while (> (length clause) 0)
      (push clause query)
      (setq clause (gm-nnir-read-imap-clause)))
    (mapconcat #'identity query " ")))

;;}}}
;;{{{ NNIR Engine For GMail 

;;; GMail Search Commands 
;;;###autoload
(defun gm-nnir-group-make-nnir-group (q)
  "GMail equivalent of gnus-group-make-nnir-group.
This uses standard IMap search operators."
  (interactive (list  (gm-nnir-read-imap-query)))
  (let ((nnir-imap-default-search-key "imap"))
    (cond
     ((gnus-group-group-name)           ; Search current group 
      (gnus-group-make-nnir-group
       nil                              ; no extra parms needed
       `(nnir-specs (nnir-query-spec (query  ,q)))))
     (t (error "Not on a group")))))

;;;###autoload
(defun gm-nnir-group-make-gmail-group (query)
  "Use GMail search syntax exclusively.
See https://support.google.com/mail/answer/7190?hl=en for syntax.
 note: nnimap-address etc are available as local vars if needed in these functions."
  (interactive "sGMail Query: ")  
  (let ((nnir-imap-default-search-key "imap")
        (q (format "X-GM-RAW \"%s\"" query)))
    (cond
     ((gnus-group-group-name)           ; Search current group
      (gnus-group-make-nnir-group
       nil                              ; no extra params needed
       `(nnir-specs (nnir-query-spec (query ,q)))))
     (t (error "Not on a group.")))))

;;}}}
(provide 'gm-nnir)
;;{{{ end of file

;;; local variables:
;;; folded-file: t
;;; byte-compile-warnings: (not obsolete)
;;; end:

;;}}}

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> I'm going to attach my gm-nnir.el module here so you can use it in
> testing.

Turns out it was a relatively simple bug that was preventing your
library from working, so that's already fixed.

I have a larger patch underway for providing the previous behavior of
setting `nnir-imap-default-search-key' to "gmail". But if you're using
your own functions here, that won't have much effect on you.

I know your library is working perfectly well, and email more than most
things is a case of "if it ain't broke…", but if you have a moment I
encourage you to try out the new search syntax. It provides completion
on search keys, so much of the same benefit as
`gm-nnir-read-imap-clause', as well as "or" statements, and nice things
like shorthands for relative dates, etc.

Give it a shot!

Eric

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1274 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:


Hi Eric, Will give it a shot, but here's why I am reluctant:

emacspeak is released code and I and quite a few users run directly from
Git@HEAD.
But not all users build their emacs every few days:-) -- so trying out
the new API risks breaking users.

> "T.V Raman" <raman@google.com> writes:
>
>> I'm going to attach my gm-nnir.el module here so you can use it in
>> testing.
>
> Turns out it was a relatively simple bug that was preventing your
> library from working, so that's already fixed.
>
> I have a larger patch underway for providing the previous behavior of
> setting `nnir-imap-default-search-key' to "gmail". But if you're using
> your own functions here, that won't have much effect on you.
>
> I know your library is working perfectly well, and email more than most
> things is a case of "if it ain't broke¡­", but if you have a moment I
> encourage you to try out the new search syntax. It provides completion
> on search keys, so much of the same benefit as
> `gm-nnir-read-imap-clause', as well as "or" statements, and nice things
> like shorthands for relative dates, etc.
>
> Give it a shot!
>
> Eric
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1482 bytes --]

"T.V Raman" <raman@google.com> writes:

Eric, Just pulled and built, and nnselect is working for me again,
thanks for fixing it so rapidly once I notified you!


> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>
> Hi Eric, Will give it a shot, but here's why I am reluctant:
>
> emacspeak is released code and I and quite a few users run directly from
> Git@HEAD.
> But not all users build their emacs every few days:-) -- so trying out
> the new API risks breaking users.
>
>> "T.V Raman" <raman@google.com> writes:
>>
>>> I'm going to attach my gm-nnir.el module here so you can use it in
>>> testing.
>>
>> Turns out it was a relatively simple bug that was preventing your
>> library from working, so that's already fixed.
>>
>> I have a larger patch underway for providing the previous behavior of
>> setting `nnir-imap-default-search-key' to "gmail". But if you're using
>> your own functions here, that won't have much effect on you.
>>
>> I know your library is working perfectly well, and email more than most
>> things is a case of "if it ain't broke¡­", but if you have a moment I
>> encourage you to try out the new search syntax. It provides completion
>> on search keys, so much of the same benefit as
>> `gm-nnir-read-imap-clause', as well as "or" statements, and nice things
>> like shorthands for relative dates, etc.
>>
>> Give it a shot!
>>
>> Eric
>>
>>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1562 bytes --]

"T.V Raman" <raman@google.com> writes:

However ...
There is still a huge latency on catch-up-and-exit when dealing with
nnselect groups (think I mentioned this a while back). Hitting "Q" to
exit without catchup doesn't exhibit this problem.
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>
> Hi Eric, Will give it a shot, but here's why I am reluctant:
>
> emacspeak is released code and I and quite a few users run directly from
> Git@HEAD.
> But not all users build their emacs every few days:-) -- so trying out
> the new API risks breaking users.
>
>> "T.V Raman" <raman@google.com> writes:
>>
>>> I'm going to attach my gm-nnir.el module here so you can use it in
>>> testing.
>>
>> Turns out it was a relatively simple bug that was preventing your
>> library from working, so that's already fixed.
>>
>> I have a larger patch underway for providing the previous behavior of
>> setting `nnir-imap-default-search-key' to "gmail". But if you're using
>> your own functions here, that won't have much effect on you.
>>
>> I know your library is working perfectly well, and email more than most
>> things is a case of "if it ain't broke¡­", but if you have a moment I
>> encourage you to try out the new search syntax. It provides completion
>> on search keys, so much of the same benefit as
>> `gm-nnir-read-imap-clause', as well as "or" statements, and nice things
>> like shorthands for relative dates, etc.
>>
>> Give it a shot!
>>
>> Eric
>>
>>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>
> Hi Eric, Will give it a shot, but here's why I am reluctant:
>
> emacspeak is released code and I and quite a few users run directly from
> Git@HEAD.
> But not all users build their emacs every few days:-) -- so trying out
> the new API risks breaking users.

Well that's a good point -- as a library others users rely on, it's
safest to leave it as-is, especially if backwards compatibility is
working okay.

Anyway, I'm glad the error is fixed!

Re: NNSelect Failing

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> "T.V Raman" <raman@google.com> writes:
>
> However ...
> There is still a huge latency on catch-up-and-exit when dealing with
> nnselect groups (think I mentioned this a while back). Hitting "Q" to
> exit without catchup doesn't exhibit this problem.

This unfortunately is beyond the scope of my code, this will be
something inside nnselect. I only wrote the search stuff that sits on
top of it. You might want to open a bug report for this.

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 748 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:


Interesting, but I'd like to point out that this latency issue emerged
after the search code started changing.> "T.V Raman" <raman@google.com> writes:
>
>> "T.V Raman" <raman@google.com> writes:
>>
>> However ...
>> There is still a huge latency on catch-up-and-exit when dealing with
>> nnselect groups (think I mentioned this a while back). Hitting "Q" to
>> exit without catchup doesn't exhibit this problem.
>
> This unfortunately is beyond the scope of my code, this will be
> something inside nnselect. I only wrote the search stuff that sits on
> top of it. You might want to open a bug report for this.
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>
> Interesting, but I'd like to point out that this latency issue emerged
> after the search code started changing.

The nnselect backend and gnus-search code were introduced pretty close
to one another -- gnus-search depended on the new possibilities
introduced by nnselect. But by the time the search group is open,
gnus-search is already out of the picture. When you exit the group
nnselect applies any changes you've made to the "real" backend that
owns the displayed articles. gnus-search doesn't have anything to do
with that process.

Re: NNSelect Failing

[Andrew Cohen]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

    EA> "T.V Raman" <raman@google.com> writes:
    >> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
    >> 
    >> 
    >> Interesting, but I'd like to point out that this latency issue
    >> emerged after the search code started changing.

    EA> The nnselect backend and gnus-search code were introduced pretty
    EA> close to one another -- 

git says about a month apart.

nnselect went in on Sep 5
gnus-search on Oct 14. 

I agree that its hard to see why gnus-search would have caused this, but
if we could nail down when it started that would help in tracking it
down.

Best,
Andy

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 961 bytes --]

Andrew Cohen <acohen@ust.hk> writes:

I first noticed it after search broke for me and was restored.

Mail me from me on this group should gives us the dates.
>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>     EA> "T.V Raman" <raman@google.com> writes:
>     >> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>     >> 
>     >> 
>     >> Interesting, but I'd like to point out that this latency issue
>     >> emerged after the search code started changing.
>
>     EA> The nnselect backend and gnus-search code were introduced pretty
>     EA> close to one another -- 
>
> git says about a month apart.
>
> nnselect went in on Sep 5
> gnus-search on Oct 14. 
>
> I agree that its hard to see why gnus-search would have caused this, but
> if we could nail down when it started that would help in tracking it
> down.
>
> Best,
> Andy
>
>
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: NNSelect Failing

[Andrew Cohen]

>>>>> "TVR" == T V Raman <raman@google.com> writes:

    TVR> Andrew Cohen <acohen@ust.hk> writes: I first noticed it after
    TVR> search broke for me and was restored.

OK, going back through your messages it appears that this was Nov 7, and
you were pretty clearly using the nnselect backend prior to that.  This
would tend to point the finger at gnus-search.

But I'm kind of stumped how it could be gnus-search, since it should by
completely out of the loop once the list of articles is generated. This
suggests that something else (neither nnselect or gnus-search) changed
coincidentally around the same time. I don't see anything obvious in the
git logs from around this time. 

I wish I could reproduce it. Just as a benchmark I do a search with an
imap group with about 20,000 messages that returns 4000 search hits. It
takes well under 1s from hitting "q" to finishing back at the group
buffer. (I haven't done better timing since I am assuming your observed
latency is more than this). 

Some questions:

The symptoms are: you enter a search group, do whatever, hit "q" to
exit, and it just takes awhile before you are back in the group buffer? 

I assume this is with an ephemeral search group? (If it is a permanent
group things might be different).

Do you use the registry? If so does turning it off eliminate the latency?

Re: NNSelect Failing

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1731 bytes --]

Andrew Cohen <acohen@ust.hk> writes:


This latency could well be gmail specific --- perhaps nnselect is doing
something in "catchup" that is heavy-weight with respect to gmail/imap
integration (note: I'm just fishing here).

>>>>>> "TVR" == T V Raman <raman@google.com> writes:
>
>     TVR> Andrew Cohen <acohen@ust.hk> writes: I first noticed it after
>     TVR> search broke for me and was restored.
>
> OK, going back through your messages it appears that this was Nov 7, and
> you were pretty clearly using the nnselect backend prior to that.  This
> would tend to point the finger at gnus-search.
>
> But I'm kind of stumped how it could be gnus-search, since it should by
> completely out of the loop once the list of articles is generated. This
> suggests that something else (neither nnselect or gnus-search) changed
> coincidentally around the same time. I don't see anything obvious in the
> git logs from around this time. 
>
> I wish I could reproduce it. Just as a benchmark I do a search with an
> imap group with about 20,000 messages that returns 4000 search hits. It
> takes well under 1s from hitting "q" to finishing back at the group
> buffer. (I haven't done better timing since I am assuming your observed
> latency is more than this). 
>
> Some questions:
>
> The symptoms are: you enter a search group, do whatever, hit "q" to
> exit, and it just takes awhile before you are back in the group buffer? 
>
> I assume this is with an ephemeral search group? (If it is a permanent
> group things might be different).
>
> Do you use the registry? If so does turning it off eliminate the latency?
>
>
>
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8