specifying the charset of the query string with nnir/imap

specifying the charset of the query string with nnir/imap

[Daiki Ueno]

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

I'm using nnir 1.72.

Whenever I enter Japanese chars, I get the following error:

>Search produced empty results.
>Couldn't request group: Search produced empty results.

The attached patch is just to bring it off by asserting optional
CHARSET argument for the UID SEARCH command.


[-- Attachment #2: nnir.el.diff --]
[-- Type: application/octet-stream, Size: 1888 bytes --]

--- nnir.el~	Sun Sep 23 11:30:13 2001
+++ nnir.el	Sun Sep 23 10:55:45 2001
@@ -461,6 +461,11 @@ (defcustom nnir-excite-remove-prefix (co
   :type '(regexp)
   :group 'nnir)
 
+(defcustom nnir-imap-search-charset nil
+  "*Name of the charset of the strings that appear in the search criteria."
+  :type '(choice (const nil) string)
+  :group 'nnir)
+
 ;; Swish++.  Next three variables Copyright (C) 2000, 2001 Christoph
 ;; Conrad <christoph.conrad@gmx.de>.
 ;; Swish++ home page: http://homepage.mac.com/pauljlucas/software/swish/
@@ -959,6 +964,9 @@ (defun nnir-run-excite-search (query &op
 ;; send queries as literals
 ;; handle errors
 
+(eval-and-compile
+  (autoload 'mm-charset-to-coding-system "mm-util"))
+
 (defun nnir-run-imap (query &optional group)
   (require 'imap)
   (require 'nnimap)
@@ -975,13 +983,21 @@ (defun nnir-run-imap (query &optional gr
 	    (setq buf nnimap-server-buffer) ;; xxx
 	    (message "Searching %s..." group)
             (let ((arts 0)
-                  (mbx (gnus-group-real-name group)))
+                  (mbx (gnus-group-real-name group))
+		  coding-system)
               (when (imap-mailbox-select mbx nil buf)
                 (mapcar
                  (lambda (artnum)
                    (push (vector mbx artnum 1) artlist)
                    (setq arts (1+ arts)))
-                 (imap-search (concat "TEXT \"" qstring "\"") buf))
+		 (if (and nnir-imap-search-charset
+			  (setq coding-system (mm-charset-to-coding-system
+					       nnir-imap-search-charset)))
+		     (imap-search
+		      (concat "CHARSET " nnir-imap-search-charset " TEXT \""
+			      (mm-encode-coding-string qstring coding-system)
+			      "\"") buf)
+		   (imap-search (concat "TEXT \"" qstring "\"") buf)))
                 (message "Searching %s... %d matches" mbx arts)))
             (message "Searching %s...done" group))
         (quit nil))

[-- Attachment #3: Type: text/plain, Size: 25 bytes --]


Regards,
-- 
Daiki Ueno

Re: specifying the charset of the query string with nnir/imap

[Simon Josefsson]

Daiki Ueno <ueno@unixuser.org> writes:

> I'm using nnir 1.72.

Maybe it would be nice to have search functionality built into Gnus.

How about using a backend interface for the interface?  Then you don't
need to specify the backend to search with nnir, which I found a bit
cumbersome and inflexible.

We could keep the current simple interface -- press `G G' to search
the current group, or the currently processed marked groups for a
simple string -- but also add a fancy "advanced query" form using all
kind of weird widgets.

What about the following backend interface?  IMAP can implement this,
and I guess nnfolder could implement at least the `text' primitive
easily using `search-forward', and nnml could implement it using
`grep'.  Of course, nnml and nnfolder could use Glimpse, Swish++ etc
as well if so configured.

`(nnchoke-request-search-capability &optional GROUP SERVER)'
     This function should return the list of search functions which the
     server (or group, if GROUP is non-nil) supports.  The search
     functions include `and', `or', `not', `text', `to', `from',
     `subject', `cc', `head', `header', `body' and `charset'.  If
     searching is not supported, the empty list should be returned.  It
     is sufficient to implement the `text' search function to get a
     useful search interface, the other functions are only used by the
     advanced query interface.

     There should be no result data returned.

`(nnchoke-request-search-group GROUP QUERY &optional SERVER)'
     This function should search the group for articles matching QUERY,
     returning a range of articles that match the query (or nil if no
     articles match).  The QUERY is a flexible expression looking
     something like:

          (and (subject "Something")
               (text "Something else"))

     The meaning of the primitives is hopefully obvious, however some
     details:

    `header'
          The `header' primitive takes two arguments, one string
          indicating the header to search and one to indicate the
          string to search for.  E.g. `(header "bcc" "myself")'.

    `head'
          On other other hand, the `head' primitive only takes one
          argument and searches the entire header.

    `charset'
          This is a pseduo-primitive, used to wrap other search
          primitives that should search using a certain character set.
          E.g. `(charset "iso-8859-1" (subject "räksmörgås"))'.

     There should be no result data returned.

`(nnchoke-request-search-server QUERY &optional SERVER)'
     This function should search all groups in the server, returning a
     alist containing `group range' elements where GROUP is the
     non-fully qualified name of the group where the RANGE articles
     match the search query (or nil if no articles match).  See
     `nnchoke-request-search-group' for the syntax of QUERY.  This
     function is typically only implemented if the backend can
     efficiently search all groups.

     There should be no result data returned.

Re: specifying the charset of the query string with nnir/imap

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> How about using a backend interface for the interface?  Then you don't
> need to specify the backend to search with nnir, which I found a bit
> cumbersome and inflexible.

I agree that the current nnir.el interface is cumbersome.  Originally,
I wanted to specify the search engine via server parameters, but then
people persuaded me to use simple variables, instead.

However, I'm not so sure that it is a good idea to specify the
searching in the backend, for the search engine is orthogonal to the
backend, with the single exception of nnimap, perhaps.

Which search engine to use depends just as much on the search engine
that's installed as it depends on the backend in use.

Thoughts?

kai
-- 
Symbol's function definition is void: signature