Gnus development mailing list
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-devel@gnu.org
Cc: ding@gnus.org
Subject: Re: [RFC] Gnus generalized search, part II
Date: Mon, 24 Apr 2017 13:30:28 -0700	[thread overview]
Message-ID: <87shkx5z17.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <m3lgqsz0am.fsf@stories>

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> The query entered by the user is parsed into a sexp structure, and then
>> each engine is responsible for interpreting that.
>
> I think this sounds like a good approach.  I haven't tried the code
> myself, but I skimmed it briefly and it looks good to me.  :-)

Okay, I've pushed these changes as the scratch/nnir-search branch.

This branch is mostly the same as the nnir.el file I posted last time,
but with more switches for turning query parsing on and off. In the
storied Gnus tradition of over-customization, there are now a grand
total of four ways of controlling whether queries are parsed or raw:

1. The big switch is `nnir-use-parsed-queries'. It is t by default,
   but if set to nil, Gnus will behave more or less the way it does
   now.
2. If a prefix argument is given to the nnir search command (ie, "C-u
   G G" in the *Group* buffer), that search query will not be parsed,
   and will be passed raw to all the marked servers/groups.
3. Individual search engines can be told never to parse search
   queries, by specifying the `raw-queries-p' parameter to engine
   creation. If multiple groups are marked for searching, the query
   will be parsed for groups with engines that allow it, and not for
   engines that don't.
4. Entire classes of engines can be marked never to parse queries, by
   setting variables like nnir-notmuch-raw-queries-p, with "notmuch"
   replaced by the various engine names. Again, queries to multiple
   engines will still be parsed by engines that allow it.

I do hope people will test this. Actually testing that search groups
behave correctly is of course important, but if you just want to fool
with the search language and see how it is parsed, and transformed, you
can use stuff like this:

#+BEGIN_SRC elisp
  (let* ((query-string "subject:gnus or since:1w")
	 (parsed-query (nnir-search-parse-query query-string))
	 (test-imap (make-instance 'gnus-search-imap))
	 (test-notmuch (make-instance 'gnus-search-notmuch)))
    (message "notmuch query: %s\nimap query: %s"
	     (nnir-search-transform-top-level test-imap parsed-query)
	     (nnir-search-transform-top-level test-notmuch parsed-query)))
#+END_SRC

`nnir-search-parse-query' turns strings into sexps, and
`nnir-search-transform-top-level' turns the sexps back into
engine-specific strings -- it requires an engine instance as the first
argument.

All the engines are named gnus-search-*. There are more on the way.




  parent reply	other threads:[~2017-04-24 20:30 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 21:35 Eric Abrahamsen
2017-04-22  0:16 ` Andrew Cohen
2017-04-22  7:50   ` Eli Zaretskii
2017-04-22  8:00     ` Andrew Cohen
2017-04-22 19:53 ` Lars Ingebrigtsen
2017-04-22 20:26   ` Eric Abrahamsen
2017-04-24 20:30   ` Eric Abrahamsen [this message]
2017-04-26  4:41     ` Andrew Cohen
2017-04-26  6:31       ` Adam Sjøgren
2017-04-26  7:39         ` Saša Janiška
2017-04-26 16:07           ` Eric Abrahamsen
2017-04-26  9:21       ` Joakim Jalap
2017-04-26 15:51       ` Eric Abrahamsen
     [not found]       ` <7e7ccca805864b5398551cc74123df11@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
     [not found]         ` <87k2653oum.fsf@delle7240>
2017-04-27 19:35           ` Eric Abrahamsen
2017-04-28  1:18           ` Andrew Cohen
     [not found]           ` <cb06d28e83ab4a6cab1b3cd02fc7e554@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
     [not found]             ` <87zif16j2t.fsf@delle7240>
2017-04-28  9:16               ` Andrew Cohen
2017-04-26  8:18     ` Andrew Cohen
2017-04-26 16:37       ` Eric Abrahamsen
2017-04-26 22:31         ` Eric Abrahamsen
2017-04-27  4:27           ` Andrew Cohen
2017-04-27 18:22             ` Eric Abrahamsen
2017-04-28  1:15               ` Andrew Cohen
2017-04-28 18:23                 ` Eric Abrahamsen
2017-04-28 20:52                   ` Eric Abrahamsen
2017-04-28 23:26                     ` Andrew Cohen
2017-04-29  3:57                       ` Eric Abrahamsen
2017-04-29  9:37                         ` Andrew Cohen
2017-04-30  5:13                           ` Eric Abrahamsen
2017-04-28 23:34                   ` Andrew Cohen
2017-04-29  4:16                     ` Eric Abrahamsen
2017-04-29 21:20                 ` Harry Putnam
2017-04-30  0:15                   ` Andrew Cohen
2017-04-26 17:50       ` Eric Abrahamsen
2017-04-26  8:22     ` Andrew Cohen
2017-04-23 13:48 ` Dan Christensen
2017-04-23 17:19   ` Eric Abrahamsen
2017-04-23 17:59     ` Dan Christensen
2017-04-23 23:22       ` Eric Abrahamsen
2017-04-24  1:37         ` Dan Christensen
2017-04-24 21:02           ` Eric Abrahamsen
2017-06-10  4:46     ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87shkx5z17.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).