bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44016: 28.0.50; Add new "gnus-search" search interface to Gnus


From: Eric Abrahamsen
Subject: bug#44016: 28.0.50; Add new "gnus-search" search interface to Gnus
Date: Sun, 01 Nov 2020 13:38:53 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> On 10/16/20 07:08 AM, Lars Ingebrigtsen wrote:
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> - This patch doesn't remove the nnir.el library, though that's now
>>>>   obsolete. I think removing it could be problematic: it's not like
>>>>   declaring functions/variables obsolete, where we can let people down
>>>>   gently. I suspect plenty of code uses (require 'nnir), which will
>>>>   cause blowups. Renaming gnus-search.el to nnir.el doesn't make a lot
>>>>   of sense, though. I'm considering leaving the nnir.el file in there,
>>>>   but containing nothing but a warning.
>>>
>>> Just move it to obsolete/.
>>
>> Oh, of course -- thanks.
>
> Finally done! I think. Most of the final work was writing the docs.

Stefan, I am also dragging you into this briefly, because we talked
(perhaps several years ago now) about providing nice completion for the
search keys in this library: both using TAB in the minibuffer while
entering the search query, and also expanding abbreviated keys
programmatically during parsing.

So far as I know I've done this correctly, but I wanted to run it by you
and see if you had any suggestions/corrections.

The expandable search keys are kept in `gnus-search-expandable-keys'.
The programmatic completion part looks like:

--8<---------------cut here---------------start------------->8---
+(defun gnus-search-query-expand-key (key)
+  (cond ((test-completion key gnus-search-expandable-keys)
+        ;; We're done!
+        key)
+       ;; There is more than one possible completion.
+       ((consp (cdr (completion-all-completions
+                     key gnus-search-expandable-keys #'stringp 0)))
+        (signal 'gnus-search-parse-error
+                (list (format "Ambiguous keyword: %s" key))))
+       ;; Return KEY, either completed or untouched.
+       ((car-safe (completion-try-completion
+                   key gnus-search-expandable-keys
+                    #'stringp 0)))))
--8<---------------cut here---------------end--------------->8---

The desired behavior is that a key is expanded if it's a prefix of only
one key in `gnus-search-expandable-keys', it's left alone if it isn't,
and an error is raised if it's a prefix of more than one expandable key.
That means the user can't enter their own arbitrary keys that are a
prefix of a known key, but, too bad.

The interactive minibuffer part looks like:

--8<---------------cut here---------------start------------->8---
+(defvar gnus-search-minibuffer-map
+  (let ((km (make-sparse-keymap)))
+    (set-keymap-parent km minibuffer-local-map)
+    (define-key km (kbd "SPC") #'self-insert-command)
+    (define-key km (kbd "TAB") #'gnus-search-complete-key)
+    km))
+
+(defun gnus-search-complete-key ()
+  "Complete a search key at point.
+Used when reading a search query from the minibuffer."
+  (interactive)
+  (when (completion-in-region
+        (save-excursion
+          (if (re-search-backward " " (minibuffer-prompt-end) t)
+              (1+ (point))
+            (minibuffer-prompt-end)))
+        (point) gnus-search-expandable-keys)
+    (insert ":")))
+
+(defun gnus-search-make-spec (arg)
+  (list (cons 'query
+             (read-from-minibuffer
+              "Query: " nil gnus-search-minibuffer-map
+              nil 'gnus-search-history))
+       (cons 'raw arg)))
--8<---------------cut here---------------end--------------->8---

This appears to work, though there's more that I can do in
`gnus-search-complete-key' to check the surrounding text and handle
various situations gracefully. Mostly I'm not entirely confident that
`completion-in-region' is the right function to be using here.

Thanks for any tips,

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]