Gnus search

Gnus search

[Lars Magne Ingebrigtsen]

Gnus has a few backends for adding searching to Gnus, but they all
require third-party utilities and a somewhat complicated setup.

Is there really no way to get this to work out-of-the-box simply and
easily?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus search

[Julien Danjou]

On Thu, Oct 21 2010, Lars Magne Ingebrigtsen wrote:

> Gnus has a few backends for adding searching to Gnus, but they all
> require third-party utilities and a somewhat complicated setup.
>
> Is there really no way to get this to work out-of-the-box simply and
> easily?

Can I answer IMAP to this?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Gnus search

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Can I answer IMAP to this?

I guess you can.  :-)

Then nnir should be on by default, and not need any user customisations,
perhaps? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus search

[Julien Danjou]

On Thu, Oct 21 2010, Lars Magne Ingebrigtsen wrote:

> Then nnir should be on by default, and not need any user customisations,
> perhaps? 

I'd be glad, since I never found time so far to take a look at it and
configure it. If it could just work out of the box, that would be *very*
handy.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Gnus search

[Andrew Cohen]

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:

    Julien> On Thu, Oct 21 2010, Lars Magne Ingebrigtsen wrote:
    >> Then nnir should be on by default, and not need any user
    Julien> customisations,
    >> perhaps?

    Julien> I'd be glad, since I never found time so far to take a look
    Julien> at it and configure it. If it could just work out of the
    Julien> box, that would be *very* handy.


I don't think nnir needs any customizations for imap usage. All I had to
do was add (nnir-search-engine imap) to my imap select method, and it
just works. It should be easy enough to add this as default.

Regards,
Andy

Re: Gnus search

[Tibor Simko]

On Thu, 21 Oct 2010, Julien Danjou wrote:
> On Thu, Oct 21 2010, Lars Magne Ingebrigtsen wrote:
>
>> Then nnir should be on by default, and not need any user customisations,
>> perhaps?
>
> I'd be glad, since I never found time so far to take a look at it and
> configure it. If it could just work out of the box, that would be
> *very* handy.

The nnir configuration for IMAP should be just a matter of:

(require 'nnir)
(setq gnus-secondary-select-methods '((nnimap "foo"
                                       (nnimap-address "foo")
                                       ;; etc
                                       (nnir-search-engine imap))))

Best regards
-- 
Tibor Simko

Re: Gnus search

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> The nnir configuration for IMAP should be just a matter of:
>
> (require 'nnir)
> (setq gnus-secondary-select-methods '((nnimap "foo"
>                                        (nnimap-address "foo")
>                                        ;; etc
>                                        (nnir-search-engine imap))))

Yes, and that's too much.  :-)

What would be the easiest way for this to work automatically?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus search

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Tibor Simko <tibor.simko@cern.ch> writes:
    >> The nnir configuration for IMAP should be just a matter of:
    >> 
    >> (require 'nnir) (setq gnus-secondary-select-methods '((nnimap
    >> "foo" (nnimap-address "foo") ;; etc (nnir-search-engine imap))))

    Lars> Yes, and that's too much.  :-)

    Lars> What would be the easiest way for this to work automatically?

One way (probably lots of others):

nnir gets server parameters through a single function,
nnir-read-server-parm. We could modify this to use a default value of
imap for nnir-search-engine whenever the group method is imap and no
overriding method is set.  I can make this change a little later today. 

Andy

Re: Gnus search

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

Untested patch. Can someone who doesn't have an nnir method set for
nnimap servers give this is a try?


Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nnimap auto search --]
[-- Type: text/x-diff, Size: 1220 bytes --]

diff --git a/lisp/nnir.el b/lisp/nnir.el
index 2a264d1..a6a561e 100644
--- a/lisp/nnir.el
+++ b/lisp/nnir.el
@@ -1606,7 +1606,10 @@ and concat the results."
 			       search-func)
 			   (setq search-func (cadr
 					      (assoc
-					       (nnir-read-server-parm 'nnir-search-engine server) nnir-engines)))
+					       (or (nnir-read-server-parm
+						    'nnir-search-engine server)
+						   (when (eq 'nnimap (car
+								      (gnus-server-to-method server))) 'imap)) nnir-engines)))
 			   (if search-func
 			       (funcall search-func q server x)
 			     nil)))
@@ -1617,9 +1620,12 @@ and concat the results."
 		       (if (and (equal (cadr x) 'ok) (not (equal (cadar x) "-ephemeral")))
 			   (let ((server (format "%s:%s" (caar x) (cadar x)))
 				 search-func)
-			     (setq search-func (cadr
-						(assoc
-						 (nnir-read-server-parm 'nnir-search-engine server) nnir-engines)))
+			   (setq search-func (cadr
+					      (assoc
+					       (or (nnir-read-server-parm
+						    'nnir-search-engine server)
+						   (when (eq 'nnimap (car
+								      (gnus-server-to-method server))) 'imap)) nnir-engines)))
 			     (if search-func
 				 (funcall search-func q server nil)
 			       nil))

Re: Gnus search

[Ted Zlatanov]

On Thu, 21 Oct 2010 14:25:39 -0400 Andrew Cohen <cohen@andy.bu.edu> wrote: 

AC> Untested patch. Can someone who doesn't have an nnir method set for
AC> nnimap servers give this is a try?

It works for me.

I think we should always enable nnir, meaning that this:

(defun nnir-group-mode-hook ()
  (define-key gnus-group-mode-map (kbd "G G")
    'gnus-group-make-nnir-group))
(add-hook 'gnus-group-mode-hook 'nnir-group-mode-hook)

should be available without explicitly loading nnir.el.

On Thu, 21 Oct 2010 20:35:26 +0200 Andreas Seltenreich <andreas+ding@gate450.dyndns.org> wrote: 

AS> Ted Zlatanov writes:

>> What's the downside of setting nnir-search-engine to 'imap by default?

AS> I'm afraid nnoo will clobber it as soon as it sees a method definition
AS> containing another nnir-search-engine.

You're right.  Andy's solution is much better.

Ted

Re: Gnus search

[Andrew Cohen]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

    Ted> I think we should always enable nnir, meaning that this:

    Ted> (defun nnir-group-mode-hook () (define-key gnus-group-mode-map
    Ted> (kbd "G G") 'gnus-group-make-nnir-group)) (add-hook
    Ted> 'gnus-group-mode-hook 'nnir-group-mode-hook)

    Ted> should be available without explicitly loading nnir.el.

How about adding it to gnus-group-group-map? In gnus-group.el

(gnus-define-keys (gnus-group-group-map "G" gnus-group-mode-map)

  "G" gnus-group-make-nnir-group

Re: Gnus search

[Andrew Cohen]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

Attached are patches to make nnir work in nnimap groups without user
configuration. I've set things up so defaults for other backends can be
easily included in the future. I've moved the key binding into
gnus-group.el but left the binding ("G G") unchanged. Finally I've fixed
a bug when searching multiple imap groups. 

Please let me know if this works.

Regards,
Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nnir search changes --]
[-- Type: text/x-diff, Size: 6014 bytes --]

diff --git a/lisp/gnus-group.el b/lisp/gnus-group.el
index 7152c18..e2864b9 100644
--- a/lisp/gnus-group.el
+++ b/lisp/gnus-group.el
@@ -55,6 +55,8 @@
 (autoload 'gnus-agent-total-fetched-for "gnus-agent")
 (autoload 'gnus-cache-total-fetched-for "gnus-cache")
 
+(autoload 'gnus-group-make-nnir-group "nnir")
+
 (defcustom gnus-no-groups-message "No Gnus is good news"
   "*Message displayed by Gnus when no groups are available."
   :group 'gnus-start
@@ -653,6 +655,7 @@ simple manner.")
   "D" gnus-group-enter-directory
   "f" gnus-group-make-doc-group
   "w" gnus-group-make-web-group
+  "G" gnus-group-make-nnir-group
   "M" gnus-group-read-ephemeral-group
   "r" gnus-group-rename-group
   "R" gnus-group-make-rss-group
@@ -904,6 +907,7 @@ simple manner.")
 	["Add the help group" gnus-group-make-help-group t]
 	["Make a doc group..." gnus-group-make-doc-group t]
 	["Make a web group..." gnus-group-make-web-group t]
+	["Make a search group..." gnus-group-make-nnir-group t]
 	["Make a virtual group..." gnus-group-make-empty-virtual t]
 	["Add a group to a virtual..." gnus-group-add-to-virtual t]
 	["Make an ephemeral group..." gnus-group-read-ephemeral-group t]


diff --git a/lisp/nnir.el b/lisp/nnir.el
index 2a264d1..a32d748 100644
--- a/lisp/nnir.el
+++ b/lisp/nnir.el
@@ -378,6 +378,10 @@ should return a message's headers in NOV format.
 If this variable is nil, or if the provided function returns nil for a search
 result, `gnus-retrieve-headers' will be called instead.")
 
+(defvar nnir-method-default-engines
+  '((nnimap . imap)
+    (nntp . nil))
+  "Alist of default search engines by server method")
 
 ;;; Developer Extension Variable:
 
@@ -401,8 +405,8 @@ result, `gnus-retrieve-headers' will be called instead.")
              ())
     (hyrex   nnir-run-hyrex
 	     ((group . "Group spec: ")))
-  (find-grep nnir-run-find-grep
-	     ((grep-options . "Grep options: "))))
+    (find-grep nnir-run-find-grep
+	       ((grep-options . "Grep options: "))))
   "Alist of supported search engines.
 Each element in the alist is a three-element list (ENGINE FUNCTION ARGS).
 ENGINE is a symbol designating the searching engine.  FUNCTION is also
@@ -677,16 +681,6 @@ that it is for Namazu, not Wais."
            gnus-current-window-configuration)
      nil)))
 
-(eval-when-compile
-  (when (featurep 'xemacs)
-    ;; The `kbd' macro requires that the `read-kbd-macro' macro is available.
-    (require 'edmacro)))
-
-(defun nnir-group-mode-hook ()
-  (define-key gnus-group-mode-map (kbd "G G")
-    'gnus-group-make-nnir-group))
-(add-hook 'gnus-group-mode-hook 'nnir-group-mode-hook)
-
 ;; Why is this needed? Is this for compatibility with old/new gnusae? Using
 ;; gnus-group-server instead works for me.  -- Justus Piater
 (defmacro nnir-group-server (group)
@@ -716,22 +710,22 @@ and show thread that contains this article."
 	 (id (mail-header-id (gnus-summary-article-header)))
 	 (refs (split-string
 		(mail-header-references (gnus-summary-article-header)))))
-    (if (string= (car (gnus-group-method group)) "nnimap")
-	(with-current-buffer (nnimap-buffer)
-	  (let* ((cmd (let ((value
-			     (format
-			      "(OR HEADER REFERENCES %s HEADER Message-Id %s)"
-			      id id)))
-			(dolist (refid refs value)
-			  (setq value (format
-				       "(OR (OR HEADER Message-Id %s HEADER REFERENCES %s) %s)"
-				       refid refid value)))))
-		 (result (nnimap-command
-			  "UID SEARCH %s" cmd)))
-	    (gnus-summary-read-group-1 group t t gnus-summary-buffer nil
-				       (and (car result)
-					    (delete 0 (mapcar #'string-to-number
-							      (cdr (assoc "SEARCH" (cdr result)))))))))
+    (if (eq (car (gnus-group-method group)) 'nnimap)
+	(progn (nnimap-possibly-change-group (gnus-group-short-name group) nil)
+	       (with-current-buffer (nnimap-buffer)
+		 (let* ((cmd (let ((value (format
+					   "(OR HEADER REFERENCES %s HEADER Message-Id %s)"
+					   id id)))
+			       (dolist (refid refs value)
+				 (setq value (format
+					      "(OR (OR HEADER Message-Id %s HEADER REFERENCES %s) %s)"
+					      refid refid value)))))
+			(result (nnimap-command
+				 "UID SEARCH %s" cmd)))
+		   (gnus-summary-read-group-1 group t t gnus-summary-buffer nil
+					      (and (car result)
+						   (delete 0 (mapcar #'string-to-number
+								     (cdr (assoc "SEARCH" (cdr result))))))))))
       (gnus-summary-read-group-1 group t t gnus-summary-buffer
 				 nil (list backend-number))
       (gnus-summary-limit (list backend-number))
@@ -1602,24 +1596,37 @@ and concat the results."
     (if gnus-group-marked
 	(apply 'vconcat
 	       (mapcar (lambda (x)
-			 (let ((server (nnir-group-server x))
-			       search-func)
+			 (let* ((server (nnir-group-server x))
+				(engine
+				 (or (nnir-read-server-parm 'nnir-search-engine
+							    server)
+				     (cdr
+				      (assoc (car (gnus-server-to-method server))
+					     nnir-method-default-engines))))
+				search-func)
 			   (setq search-func (cadr
 					      (assoc
-					       (nnir-read-server-parm 'nnir-search-engine server) nnir-engines)))
+					       engine
+					       nnir-engines)))
 			   (if search-func
 			       (funcall search-func q server x)
 			     nil)))
-		       gnus-group-marked)
-	       )
+		       gnus-group-marked))
       (apply 'vconcat
 	     (mapcar (lambda (x)
 		       (if (and (equal (cadr x) 'ok) (not (equal (cadar x) "-ephemeral")))
-			   (let ((server (format "%s:%s" (caar x) (cadar x)))
-				 search-func)
+			   (let* ((server (format "%s:%s" (caar x) (cadar x)))
+				  (engine
+				   (or (nnir-read-server-parm 'nnir-search-engine
+							      server)
+				       (cdr
+					(assoc (car (gnus-server-to-method server))
+					       nnir-method-default-engines))))
+				  search-func)
 			     (setq search-func (cadr
 						(assoc
-						 (nnir-read-server-parm 'nnir-search-engine server) nnir-engines)))
+						 engine
+						 nnir-engines)))
 			     (if search-func
 				 (funcall search-func q server nil)
 			       nil))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: changelog --]
[-- Type: text/x-diff, Size: 609 bytes --]

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 9160666..0e18635 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,14 @@
+2010-10-22  Andrew Cohen  <cohen@andy.bu.edu>
+
+	* nnir.el (nnir-method-default-engines): new variable.
+	(nnir-run-query): use it.
+	(nnir-group-mode-hook): remove key binding and move to gnus-group.el.
+	(gnus-summary-nnir-goto-thread): change group if needed.
+
+	* gnus-group.el (gnus-group-group-map): add key binding for
+	gnus-group-make-nnir-group.
+
+
 2010-10-22  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* mml.el (mml-preview): Work properly when editing article.

Re: Gnus search

[Steinar Bang]

>>>>> Andrew Cohen <cohen@andy.bu.edu>:

> Attached are patches to make nnir work in nnimap groups without user
> configuration. I've set things up so defaults for other backends can
> be easily included in the future.

Any chance of seeing nnir support for gmane?

Re: Gnus search

[Andrew Cohen]

>>>>> "Steinar" == Steinar Bang <sb@dod.no> writes:

>>>>> Andrew Cohen <cohen@andy.bu.edu>:
    >> Attached are patches to make nnir work in nnimap groups without
    >> user configuration. I've set things up so defaults for other
    >> backends can be easily included in the future.

    Steinar> Any chance of seeing nnir support for gmane?


Working on it. But note that the existing search facility for gmane is
very good ("G w" from the group buffer and select gmane), and will in
many ways remain superior to what nnir can do.

Re: Gnus search

[Steinar Bang]

>>>>> Andrew Cohen <cohen@andy.bu.edu>:

> Working on it. But note that the existing search facility for gmane is
> very good ("G w" from the group buffer and select gmane), and will in
> many ways remain superior to what nnir can do.

But `G w' can't warp from the results to the group... or can it...?

Re: Gnus search

[Ted Zlatanov]

On Sat, 23 Oct 2010 08:14:40 -0400 Andrew Cohen <cohen@andy.bu.edu> wrote: 

>>>>>> "Steinar" == Steinar Bang <sb@dod.no> writes:
>>>>>> Andrew Cohen <cohen@andy.bu.edu>:
>>> Attached are patches to make nnir work in nnimap groups without
>>> user configuration. I've set things up so defaults for other
>>> backends can be easily included in the future.

Steinar> Any chance of seeing nnir support for gmane?

AC> Working on it. But note that the existing search facility for gmane is
AC> very good ("G w" from the group buffer and select gmane), and will in
AC> many ways remain superior to what nnir can do.

Can nnir wrap that?

Ted

Re: Gnus search

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Attached are patches to make nnir work in nnimap groups without user
> configuration. I've set things up so defaults for other backends can be
> easily included in the future. I've moved the key binding into
> gnus-group.el but left the binding ("G G") unchanged. Finally I've fixed
> a bug when searching multiple imap groups. 

Thanks; applied.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus search

[Ted Zlatanov]

On Thu, 21 Oct 2010 19:12:27 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Tibor Simko <tibor.simko@cern.ch> writes:
>> The nnir configuration for IMAP should be just a matter of:
>> 
>> (require 'nnir)
>> (setq gnus-secondary-select-methods '((nnimap "foo"
>> (nnimap-address "foo")
>> ;; etc
>> (nnir-search-engine imap))))

LMI> Yes, and that's too much.  :-)

LMI> What would be the easiest way for this to work automatically?

What's the downside of setting nnir-search-engine to 'imap by default?

Ted

Re: Gnus search

[Andreas Seltenreich]

Ted Zlatanov writes:

> What's the downside of setting nnir-search-engine to 'imap by default?

I'm afraid nnoo will clobber it as soon as it sees a method definition
containing another nnir-search-engine.

regards,
andreas

Re: Gnus search

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Julien Danjou <julien@danjou.info> writes:

>> Can I answer IMAP to this?

> I guess you can.  :-)

> Then nnir should be on by default, and not need any user
> customisations, perhaps?

It would be neat of nnir could be used for gmane groups.  I know nnweb
can do searching, but I would have liked the behaviour of nnir (and
functionality such as `A T' working.

I tried to write this method, but it's not quite there...

(defun gnus-group-make-gmane-search-group ()
  "Create an ephemeral nnweb group containing the results of a Gmane search."
  (interactive)
  (require 'nnweb)
  (let* ((group (message-unique-id))
	 (type "gmane")
         (gmane-group-name (car (cdr (split-string (gnus-group-group-name) ":"))))
	 (search
          (concat
           "group:" gmane-group-name " "
           (read-string
            "Search string: "
            (cons (or (car gnus-group-web-search-history) "") 0)
            'gnus-group-web-search-history)))
	 (method
	  `(nnweb ,group (nnweb-search ,search)
		  (nnweb-type ,(intern type))
		  (nnweb-ephemeral-p t))))
    (gnus-group-read-ephemeral-group
     group method t
     (cons (current-buffer)
           (if (eq major-mode 'gnus-summary-mode) 'summary 'group)))))

(defun gmane-search-group-mode-hook ()
  (define-key gnus-group-mode-map (kbd "G b")
    'gnus-group-make-gmane-search-group))
(add-hook 'gnus-group-mode-hook 'gmane-search-group-mode-hook)

Re: Gnus search

[Andrew Cohen]

I am considering significant changes to nnir to improve the searching
experience. I have added gmane searching but this has exposed some
weaknesses in the current interface, so I would like to get some advice
on potential changes.

Currently nnir searches are initiated from the group buffer in one of
two ways:

1. If any groups are process-marked only these groups are searched.

2. If no groups are process marked then all opened servers are
   searched. Some search engines (imap) are only capable of searching a
   single group at a time so the search is restricted to the group on
   the current line. Others (swish, freewais, namazu) can only search
   the whole database, so that's what they do.

With only one search engine available (as has been the case for me
forever) I never noticed this, and assumed that nnir was just searching
the group on the current line. But I now have both imap and gmane
searching available, and without process-marking groups all searches now
search both backends. This is usually not what I want.

So---how about changing the behavior in case 2:

2. If no groups are process-marked search only the group on the current
   line (using the appropriate backend). 

and possibly adding 

3. If no groups are process-marked and no group is on the current line,
   search all opened servers (which might take awhile). The user can put
   point on the last line of the group buffer for example. 

This last addition might not be a great idea, and its only relevant if
anyone continues to use the relevant search engines. So is anyone using:

swish
wais
hyrex
namazu


Can any of these be removed?

Regards,
Andy

Re: Gnus search

[Steinar Bang]

>>>>> Andrew Cohen <cohen@andy.bu.edu>:

> So---how about changing the behavior in case 2:

> 2. If no groups are process-marked search only the group on the current
>    line (using the appropriate backend). 

That works for me.

(I have an additional feature request for this case: look in the group
parameters of the current group for a group parameter giving the name
for an archive group and search that as well.  My use case is that I
keep my high traffic nnimap groups slim by expiring read mail to archive
groups, and manually moving ticked messages to the same archive groups).

> and possibly adding 

> 3. If no groups are process-marked and no group is on the current line,
>    search all opened servers (which might take awhile). The user can put
>    point on the last line of the group buffer for example. 

Um... I don't really have any strong views on this one, except...

> This last addition might not be a great idea,

...a feeling in this direction, yeah...

I only use nnir for imap, and (up until the new nnir) web search for gmane.

Re: Gnus search

[Dan Christensen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> and possibly adding 
>
> 3. If no groups are process-marked and no group is on the current line,
>    search all opened servers (which might take awhile). The user can put
>    point on the last line of the group buffer for example. 

Maybe a prefix arg could be used to start a search like this?

> This last addition might not be a great idea, and its only relevant if
> anyone continues to use the relevant search engines. So is anyone using:
>
> swish
> wais
> hyrex
> namazu

Will mairix be integrated into nnir?

Dan

Re: Gnus search

[Andrew Cohen]

>>>>> "Dan" == Dan Christensen <jdc@uwo.ca> writes:

    Dan> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> and possibly adding
    >> 
    >> 3. If no groups are process-marked and no group is on the current
    Dan> line,
    >> search all opened servers (which might take awhile). The user can
    Dan> put
    >> point on the last line of the group buffer for example.

    Dan> Maybe a prefix arg could be used to start a search like this?


Prefix arg is already used for something else (adding search-engine
specific info).


    >> This last addition might not be a great idea, and its only
    >> relevant
    Dan> if
    >> anyone continues to use the relevant search engines. So is anyone
    Dan> using:
    >> 
    >> swish wais hyrex namazu

    Dan> Will mairix be integrated into nnir?

I don't know anything about mairix but I will take a look at it when I
get a chance.

Re: Gnus search

[Ted Zlatanov]

On Wed, 27 Oct 2010 07:36:42 -0400 Andrew Cohen <cohen@andy.bu.edu> wrote: 

AC> I am considering significant changes to nnir to improve the searching
AC> experience. I have added gmane searching but this has exposed some
AC> weaknesses in the current interface, so I would like to get some advice
AC> on potential changes.

AC> Currently nnir searches are initiated from the group buffer in one of
AC> two ways:

AC> 1. If any groups are process-marked only these groups are searched.

AC> 2. If no groups are process marked then all opened servers are
AC>    searched. Some search engines (imap) are only capable of searching a
AC>    single group at a time so the search is restricted to the group on
AC>    the current line. Others (swish, freewais, namazu) can only search
AC>    the whole database, so that's what they do.

AC> With only one search engine available (as has been the case for me
AC> forever) I never noticed this, and assumed that nnir was just searching
AC> the group on the current line. But I now have both imap and gmane
AC> searching available, and without process-marking groups all searches now
AC> search both backends. This is usually not what I want.

AC> So---how about changing the behavior in case 2:

AC> 2. If no groups are process-marked search only the group on the current
AC>    line (using the appropriate backend). 

Agreed.

AC> and possibly adding 

AC> 3. If no groups are process-marked and no group is on the current line,
AC>    search all opened servers (which might take awhile). The user can put
AC>    point on the last line of the group buffer for example. 

I think this could be in the Server buffer, where you will have a server
under point.  In the Group buffer, I'd use `G M-G' to search specific
servers, which "all" being the default (so `G M-G RET' will search all
servers).

AC> This last addition might not be a great idea, and its only relevant if
AC> anyone continues to use the relevant search engines. So is anyone using:

AC> swish
AC> wais
AC> hyrex
AC> namazu

Not me.

Ted

Re: Gnus search

[Andrew Cohen]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

    Ted> On Wed, 27 Oct 2010 07:36:42 -0400 Andrew Cohen
    Ted> <cohen@andy.bu.edu>
    Ted> wrote:

    AC> I am considering significant changes to nnir to improve the
    AC> searching experience. I have added gmane searching but this has
    AC> exposed some weaknesses in the current interface, so I would
    AC> like to get some advice on potential changes.

    AC> Currently nnir searches are initiated from the group buffer in
    AC> one of two ways:

    AC> 1. If any groups are process-marked only these groups are
    AC> searched.

    AC> 2. If no groups are process marked then all opened servers are
    AC> searched. Some search engines (imap) are only capable of
    AC> searching a single group at a time so the search is restricted
    AC> to the group on the current line. Others (swish, freewais,
    AC> namazu) can only search the whole database, so that's what they
    AC> do.

    AC> With only one search engine available (as has been the case for
    AC> me forever) I never noticed this, and assumed that nnir was just
    AC> searching the group on the current line. But I now have both
    AC> imap and gmane searching available, and without process-marking
    AC> groups all searches now search both backends. This is usually
    AC> not what I want.

    AC> So---how about changing the behavior in case 2:

    AC> 2. If no groups are process-marked search only the group on the
    AC> current line (using the appropriate backend).

    Ted> Agreed.

    AC> and possibly adding

    AC> 3. If no groups are process-marked and no group is on the
    AC> current line, search all opened servers (which might take
    AC> awhile). The user can put point on the last line of the group
    AC> buffer for example.

    Ted> I think this could be in the Server buffer, where you will have
    Ted> a server under point.  In the Group buffer, I'd use `G M-G' to
    Ted> search specific servers, which "all" being the default (so `G
    Ted> M-G RET' will search all servers).

I think this is an excellent idea. It adds a keystroke (to get into the
server buffer) over the existing behavior, but I suspect that this
kind of searching will be rare (and probably no one is using it this way
at the moment).

    AC> So is anyone using:

    AC> swish wais hyrex namazu

    Ted> Not me.

I'm wondering if we could remove some of these? I have been using namazu
up until I switched to imap a year ago. Swish has packages as new as Apr
2009, but the freewais-sf webpage says it is no longer supported, and
hyrex doesn't seem to have any activity since 2004. So I would vote for
removing at least hyrex and freewais-sf. 

Regards,
Andy

Re: Gnus search

[Ted Zlatanov]

On Wed, 27 Oct 2010 14:08:42 -0400 Andrew Cohen <cohen@andy.bu.edu> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
AC> So is anyone using:

AC> swish wais hyrex namazu

Ted> Not me.

AC> I'm wondering if we could remove some of these? I have been using namazu
AC> up until I switched to imap a year ago. Swish has packages as new as Apr
AC> 2009, but the freewais-sf webpage says it is no longer supported, and
AC> hyrex doesn't seem to have any activity since 2004. So I would vote for
AC> removing at least hyrex and freewais-sf. 

I'm in favor of removing them.

Ted

Re: Gnus search

[Julien Danjou]

On Wed, Oct 27 2010, Ted Zlatanov wrote:

> I'm in favor of removing them.

I can prepare a patch. But the default nnir-search-engine value is
'wais.

What should the default become then?

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: Gnus search

[Andrew Cohen]

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:

    Julien> On Wed, Oct 27 2010, Ted Zlatanov wrote:
    >> I'm in favor of removing them.

I've heard from one person still using swish and one still using
namazu. Since I suspect there are others not reading this list, its
probably prudent to leave them in for now.

    Julien> I can prepare a patch. But the default nnir-search-engine
    Julien> value is 'wais.

    Julien> What should the default become then?

I'm in the process of making significant changes to nnir (I should be
ready to post something very soon). In my new version this variable has
gone away :)

Regards,
Andy

Re: Gnus search

[Julien Danjou]

On Thu, Oct 28 2010, Andrew Cohen wrote:

> I'm in the process of making significant changes to nnir (I should be
> ready to post something very soon). In my new version this variable has
> gone away :)

Fine! I've removed hyrex support, and will wait for your patch to remove
wais.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

nnir: Removing some search engines (was: Gnus search)

[Reiner Steib]

On Wed, Oct 27 2010, Andrew Cohen wrote:

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
>     AC> So is anyone using:
>
>     AC> swish wais hyrex namazu
>
>     Ted> Not me.
>
> I'm wondering if we could remove some of these? I have been using namazu
> up until I switched to imap a year ago. Swish has packages as new as Apr
> 2009, but the freewais-sf webpage says it is no longer supported, and
> hyrex doesn't seem to have any activity since 2004. So I would vote for
> removing at least hyrex and freewais-sf. 

Is there a compelling reason to remove them?

Please ask on gnu.emacs.gnus and here on ding (in a dedicated thread)
if anyone uses them.

We could also just mark them as obsolete now (display a message when
using them maybe) and remove them later if no one complains.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: nnir: Removing some search engines

[Andrew Cohen]

>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:

    Reiner> On Wed, Oct 27 2010, Andrew Cohen wrote:
    >>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
    AC> So is anyone using:
    >> 
    AC> swish wais hyrex namazu
    >> 
    Ted> Not me.
    >> 
    >> I'm wondering if we could remove some of these? I have been using
    Reiner> namazu
    >> up until I switched to imap a year ago. Swish has packages as new
    >> as
    Reiner> Apr
    >> 2009, but the freewais-sf webpage says it is no longer supported,
    Reiner> and
    >> hyrex doesn't seem to have any activity since 2004. So I would
    >> vote
    Reiner> for
    >> removing at least hyrex and freewais-sf.

    Reiner> Is there a compelling reason to remove them?

I have been rewriting much of nnir and this just added complexity. Since
I don't have any of these search engines I can't test them.

But in the end it wasn't too extreme an effort to modify them which I
have now done (with the exception of hyrex which I should get to this
weekend). So they can all be left in if we want.

    Reiner> Please ask on gnu.emacs.gnus and here on ding (in a
    Reiner> dedicated thread) if anyone uses them.

I have heard back from one person who uses swish. So that leaves only
freewais and  hyrex as candidates in any case.

    Reiner> We could also just mark them as obsolete now (display a
    Reiner> message when using them maybe) and remove them later if no
    Reiner> one complains.

Probably the best course.

Andy

Re: nnir: Removing some search engines

[Jose A. Ortega Ruiz]

On Fri, Oct 29 2010, Reiner Steib wrote:

[...]

> We could also just mark them as obsolete now (display a message when
> using them maybe) and remove them later if no one complains.

What would be the alternative for searching in local nnml boxes? (I use
namazu, but would be happy to use something better or, at least, not
obsoleted).

TIA,
jao
-- 
How many Zen Buddhist does it take to change a light bulb?
Two. One to change it and one not to change it.

Re: Gnus search

[Jose A. Ortega Ruiz]

On Wed, Oct 27 2010, Andrew Cohen wrote:


[...]

> This last addition might not be a great idea, and its only relevant if
> anyone continues to use the relevant search engines. So is anyone using:
>
> swish
> wais
> hyrex
> namazu


i use namazu (and i don't use imap).

cheers,
jao