GNU bug report logs -
#44016
28.0.50; Add new "gnus-search" search interface to Gnus
Previous Next
Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Date: Thu, 15 Oct 2020 16:49:02 UTC
Severity: wishlist
Tags: patch
Found in version 28.0.50
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44016 in the body.
You can then email your comments to 44016 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Thu, 15 Oct 2020 16:49:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eric Abrahamsen <eric <at> ericabrahamsen.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 15 Oct 2020 16:49:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Now that the nnselect Gnus backend is in, I've been able to finish the
gnus-search.el library from... four years ago or more. There's a
scratch/gnus-search branch in the repo but it was so old merging was a
pain, so I'm going to just delete it. I've attached a work-in-progress
patch.
To recap: with this library, you can set
`gnus-search-use-parsed-queries' non-nil, and use the same generalized
search query language against all supported search engines. A query
might look like:
from:"my boss" mark:flag since:1w
That same query would work against an IMAP group, or a nnmaildir group
indexed with notmuch, or even multiple groups backed by different search
engines, and the results will be collected correctly. Using nnselect,
the above group could be made permanent, so you'd have a
continually-updating group displaying recent important messages from
your boss.
Some open questions:
- This patch doesn't include documentation, though I have that around
here somewhere. I'll fix it up and add it.
- 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.
- There's "clever" completion stuff in there, that allows search keys to
be completed either during entry, with TAB, or programmatically, after
the query has been entered. I suspect I'm not using quite the right
functions, particularly `completion-in-region' which sort of looks
like it's not meant to be used the way I'm using it -- it seems to
return messages directly.
Anyway, comments very welcome!
Eric
[gnus-search.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Fri, 16 Oct 2020 05:10:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44016 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> 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/.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Fri, 16 Oct 2020 15:50:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44016 <at> debbugs.gnu.org (full text, mbox):
On 10/16/20 07:08 AM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Sun, 01 Nov 2020 05:33:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 44016 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> On 10/16/20 07:08 AM, Lars Ingebrigtsen wrote:
>> Eric Abrahamsen <eric <at> 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.
So there's documentation, nnir.el is in obsolete/, and I've defaulted
`gnus-search-use-parsed-queries' to nil, so that no one is surprised.
I also implemented a search engine for gmane, then removed it in one
separate commit, in case one fine day we get that back again it will be
easy to revert the removal.
I think it's ready to go! I'm sure there are bugs but it shouldn't be
too disruptive, since there's a big Turn It On switch people will have
to flip, and they can just turn it off again.
Eric
[0003-Remove-gmane-search-engine.patch (text/x-patch, attachment)]
[0002-Move-nnir.el-to-lisp-obsolete.patch (text/x-patch, attachment)]
[0001-New-gnus-search-library.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Sun, 01 Nov 2020 18:11:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 44016 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Finally done! I think. Most of the final work was writing the docs.
Thanks! I only had time to look through the manual, and it looks good,
modulo some minor markup nits.
> +It's possible to search a backend more thoroughly using an associated
> +search engine. Some backends come with their own search engine: IMAP
> +servers, for instance, do their own searching. Other backends, for
> +example a local @code{nnmaildir} installation, might require the user
> +to manually set up some sort of search indexing. Default associations
> +between backends and engines can be defined in
> +@code{gnus-search-default-engines}, and engines can also be defined on
> +a per-backend basis (@xref{Search Engines}).
Should this and other parenthesised xrefs be pxref instead?
(I haven't tested the difference.)
> +Once the search engines are set up, you can search for messages in
> +groups from one or more backends, and show the results in a group.
> +The groups that hold search results are created on the nnselect
> +backend, and can be either ephemeral or persistent (@xref{Creating
> +Search Groups}).
> +
> +@vindex: gnus-search-use-parsed-queries
Is the colon necessary?
> +Search queries can be specified one of two ways: either using the
> +syntax of the engine responsible for the group you're searching, or
> +using Gnus' generalized search syntax. Set the option
> +@code{gnus-search-use-parsed-queries} to a non-nil value to used the
> +generalized syntax. The advantage of this syntax is that, if you have
> +multiple backends indexed by different engines, you don't need to
> +remember which one you're searching -- it's also possible to issue the
I think Texinfo conventionally uses three hyphens for punctuation in
sentences (info "(texinfo) Conventions"). (Here and elsewhere.)
> +same query against multiple groups, indexed by different engines, at
> +the same time. It also provides a few other conveniences including
> +relative date parsing and tie-ins into other Emacs packages. For
> +details on Gnus' query language, @xref{Search Queries}.
I think @xref is used at the start of sentences and @ref at the end.
> +@vindex gnus-search-default-engines
> +The option @code{gnus-search-default-engines} assigns search engines
> +by server type. Its value is an alist mapping symbols indicating a
> +server type (e.g. @code{nnmaildir} or @code{nnml}) to symbols
My impression is that Emacs uses the (US?) convention of following
e.g. with a comma (but I could be wrong). (Here and elsewhere.)
> +These engines have a handful of configuration parameters that can
> +either be set as a default option for all engines of that type, or set
> +per-engine in your server config. These common paramters are:
paramters -> parameters
> +
> +@itemize
> +@item
> +@code{program}: The name of the executable. Defaults to the plain
I think listing definitions, particularly when they need markup, is
better done with e.g. '@table @code' rather than @itemize.
(Here and elsewhere.)
> +program name such as ``notmuch'' or ``namazu''.
Should command names be marked as @command? (Here or elsewhere.)
> +The customization options are formed on the pattern
> +@code{gnus-search-<engine>-<parameter>}. For instance, to use a
Don't know whether it's preferable here, but there's also the
metavariable syntax @code{gnus-search-@var{engine}-@var{parameter}},
with which you can e.g. refer to individual @vars in subsequent prose.
> +non-standard notmuch program, you might set
> +@code{gnus-search-notmuch-program} to ``/usr/local/bin/notmuch''.
@file?
> -By default the whole message will be searched. The query can be limited
> -to a specific part of a message by using a prefix-arg. After inputting
> -the query this will prompt (with completion) for a message part.
> -Choices include ``Whole message'', ``Subject'', ``From'', and
I think literal text (here and elsewhere) is usually written as @samp.
> +(from:john or from:peter) subject: ``lunch tomorrow'' since:3d
I think quoting in examples should use "" instead of ``'' (here and
elsewhere).
> +@item
> +mark: Accepts ``flag'', ``seen'', ``read'' or ``replied'', or any of
> +Gnus' single-letter representations of those marks, i.e. ``mark:R''
i.e. -> e.g.?
> +for ``read''.
> -@end table
> +@vindex gnus-search-contact-sources
> +If an elisp-based contact management packages (e.g. BBDB or EBDB)
packages -> package
elisp -> Elisp?
> -@node Customizations
> -@subsubsection Customizations
> +@vindex gnus-search-date-keys
> +Date-type keys (see @code{gnus-search-date-keys}) will accept a wide
> +variety of values. First, anything that @code{parse-time-string} can
> +parse is acceptable. Dates with missing values will be interpreted as
> +the most recent occurance thereof: for instance ``march 03'' is the
occurance -> occurrence (here and elsewhere)
--
Basil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Sun, 01 Nov 2020 18:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44016 <at> debbugs.gnu.org (full text, mbox):
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Date: Sun, 01 Nov 2020 18:10:39 +0000
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44016 <at> debbugs.gnu.org
>
> > +@vindex: gnus-search-use-parsed-queries
>
> Is the colon necessary?
It's necessary to remove it ;-)
> > +same query against multiple groups, indexed by different engines, at
> > +the same time. It also provides a few other conveniences including
> > +relative date parsing and tie-ins into other Emacs packages. For
> > +details on Gnus' query language, @xref{Search Queries}.
>
> I think @xref is used at the start of sentences and @ref at the end.
Either "see @ref" or "@pxref". Definitely not @xref.
> > +@item
> > +mark: Accepts ``flag'', ``seen'', ``read'' or ``replied'', or any of
> > +Gnus' single-letter representations of those marks, i.e. ``mark:R''
>
> i.e. -> e.g.?
Yes. And @: after "e.g.".
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Sun, 01 Nov 2020 21:20:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 44016 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 11/01/20 18:10 PM, Basil L. Contovounesios wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Finally done! I think. Most of the final work was writing the docs.
>
> Thanks! I only had time to look through the manual, and it looks good,
> modulo some minor markup nits.
Some day... some day, I will learn to write texi properly. I see I also
forgot a NEWS entry. Thanks to both of you for your comments.
I'm attaching just the diff for the manual changes. I think I've got all
of your (plural) comments -- the @table hint was particularly helpful,
thank you.
Eric
[gnus-search-docs.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Sun, 01 Nov 2020 21:40:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 44016 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> On 10/16/20 07:08 AM, Lars Ingebrigtsen wrote:
>>> Eric Abrahamsen <eric <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Sun, 01 Nov 2020 23:52:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 44016 <at> debbugs.gnu.org (full text, mbox):
> 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---
IIUC this function is used to expand unambiguous abbreviations, right
(rather than the more usual "completion" which is done as the user is
typing)?
It just happens to reuse the completion machinery to do the work.
If so, it looks OK (I guess you could try and reuse the output from
completion-all-completions in the last branch instead of calling
completion-try-completion, but it might be more trouble than it's worth).
> --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---
Hmm... here I think instead of calling `completion-in-region` yourself,
you'd want to do something like:
(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) ;; Isn't this redundant?
(define-key km (kbd "TAB") #'completion-at-point)
km))
(defun gnus-search--complete-key-data ()
"Return completion data for gnus-search keys."
(list (save-excursion
(if (re-search-backward " " (minibuffer-prompt-end) t)
(1+ (point))
(minibuffer-prompt-end)))
(point)
gnus-search-expandable-keys))
(minibuffer-with-setup-hook
(lambda ()
(add-hook 'completion-at-point-functions
#'gnus-search--complete-key-data nil t))
(read-from-minibuffer ...))
See `read--expression` (used to provide completion on Elisp function
and var names when reading an ELisp expression in the minibuffer, such
as in `M-:`) for an example.
If you want to auto-insert a `:` you'd then do it via an `:exit-function`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Mon, 02 Nov 2020 03:44:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 44016 <at> debbugs.gnu.org (full text, mbox):
On 11/01/20 18:50 PM, Stefan Monnier wrote:
>> 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---
>
> IIUC this function is used to expand unambiguous abbreviations, right
> (rather than the more usual "completion" which is done as the user is
> typing)?
Right, at this stage the string is already out of the user's hands.
> It just happens to reuse the completion machinery to do the work.
I wrote a function to do the expansion, then realized it was just a poor
implementation of half of what the completion functions already do. I
understand that these functions are aimed at interactive use (the
"(consp (cdr (completion-all-completions" bit above definitely felt like
I was holding the tool upside down), but they're absolutely useful in a
programmatic setting. I wonder if there could be some version of these
functions that could be "blessed" for use in Elisp programs.
> If so, it looks OK (I guess you could try and reuse the output from
> completion-all-completions in the last branch instead of calling
> completion-try-completion, but it might be more trouble than it's worth).
>
>> --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---
>
> Hmm... here I think instead of calling `completion-in-region` yourself,
> you'd want to do something like:
>
> (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) ;; Isn't this redundant?
Somewhere I'd gotten the idea that SPC was bound to
`minibuffer-complete-word', I don't know how.
> (define-key km (kbd "TAB") #'completion-at-point)
> km))
>
> (defun gnus-search--complete-key-data ()
> "Return completion data for gnus-search keys."
> (list (save-excursion
> (if (re-search-backward " " (minibuffer-prompt-end) t)
> (1+ (point))
> (minibuffer-prompt-end)))
> (point)
> gnus-search-expandable-keys))
>
> (minibuffer-with-setup-hook
> (lambda ()
> (add-hook 'completion-at-point-functions
> #'gnus-search--complete-key-data nil t))
> (read-from-minibuffer ...))
>
> See `read--expression` (used to provide completion on Elisp function
> and var names when reading an ELisp expression in the minibuffer, such
> as in `M-:`) for an example.
>
> If you want to auto-insert a `:` you'd then do it via an `:exit-function`.
Ah, of course! And if `gnus-search--complete-key-data' is conservative
about when it fires, it leaves the door open for other completion
functions. This function could complete "cont" to "contact:", at which
point (for example) an EBDB-specific capf function could take over and
complete names or email addresses to search for.
Thanks!
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Mon, 02 Nov 2020 14:25:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 44016 <at> debbugs.gnu.org (full text, mbox):
> (the "(consp (cdr (completion-all-completions" bit above definitely
> felt like I was holding the tool upside down),
It's just another way (more efficient) way to write
(< 1 (length (completion-all-completions ...)))
so it looks fine from where I stand.
> but they're absolutely useful in a programmatic setting. I wonder if
> there could be some version of these functions that could be "blessed"
> for use in Elisp programs.
They're definitely allowed to be used for ELisp programs. They're not
100% pure functions, but not too far off. The main issue I can see for
use "internal use" is that their behavior is influenced by the
`completion-styles` user-config, which may or may not be what you want.
>> (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) ;; Isn't this redundant?
>
> Somewhere I'd gotten the idea that SPC was bound to
> `minibuffer-complete-word', I don't know how.
I presume you earlier inherited from `minibuffer-local-completion-map`
or something like that.
> Ah, of course! And if `gnus-search--complete-key-data' is conservative
> about when it fires, it leaves the door open for other completion
> functions.
If by "fires" you mean "returns non-nil", then yes, indeed.
> This function could complete "cont" to "contact:", at which
> point (for example) an EBDB-specific capf function could take over and
> complete names or email addresses to search for.
Right. Or it could itself recognize "contact:" and return the bounds of
the contact info along with EBDB's completion table (since EBDB's
capf presumably doesn't know about the "contact:" syntax).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Mon, 02 Nov 2020 16:17:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 44016 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> (the "(consp (cdr (completion-all-completions" bit above definitely
>> felt like I was holding the tool upside down),
>
> It's just another way (more efficient) way to write
>
> (< 1 (length (completion-all-completions ...)))
>
> so it looks fine from where I stand.
The return value for multiple matches is not a proper list (looks like
("subject" "since" . 0)), so I couldn't use `length' on it. That and the
fact that the strings have a face property made it seem like the
function wasn't really meant for what I was doing with it
>> but they're absolutely useful in a programmatic setting. I wonder if
>> there could be some version of these functions that could be "blessed"
>> for use in Elisp programs.
>
> They're definitely allowed to be used for ELisp programs. They're not
> 100% pure functions, but not too far off. The main issue I can see for
> use "internal use" is that their behavior is influenced by the
> `completion-styles` user-config, which may or may not be what you want.
I'll wait and see if that's a problem. If I'm expecting a completion
style that completes hyphenated strings ("con-f" -> "contact-from") and
the user has removed that style it could be an issue. I wonder how many
users even know about this configuration, though.
>>> (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) ;; Isn't this redundant?
>>
>> Somewhere I'd gotten the idea that SPC was bound to
>> `minibuffer-complete-word', I don't know how.
>
> I presume you earlier inherited from `minibuffer-local-completion-map`
> or something like that.
Yes, I was confusing with `completing-read'.
>> Ah, of course! And if `gnus-search--complete-key-data' is conservative
>> about when it fires, it leaves the door open for other completion
>> functions.
>
> If by "fires" you mean "returns non-nil", then yes, indeed.
>
>> This function could complete "cont" to "contact:", at which
>> point (for example) an EBDB-specific capf function could take over and
>> complete names or email addresses to search for.
>
> Right. Or it could itself recognize "contact:" and return the bounds of
> the contact info along with EBDB's completion table (since EBDB's
> capf presumably doesn't know about the "contact:" syntax).
Right, it would be much easier just to have a variable where
contact-management packages can register a completion table. Now I'm
thinking there's no real need for a "contact" key at all, just offer
completion on to/from/recipient/etc. Anyway, I've already got the code
working, thanks again for the pointers.
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Mon, 02 Nov 2020 20:13:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 44016 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Okay, I think this is Close Enough. I'm going to sit on it for a couple
of days, then push.
[0001-New-gnus-search-library.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44016; Package
emacs.
(Wed, 04 Nov 2020 05:23:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 44016 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Okay, I think this is Close Enough. I'm going to sit on it for a couple
> of days, then push.
There goes. I'll keep an eye out for bugs. Closing this now.
Reply sent
to
Eric Abrahamsen <eric <at> ericabrahamsen.net>:
You have taken responsibility.
(Wed, 04 Nov 2020 05:23:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eric Abrahamsen <eric <at> ericabrahamsen.net>:
bug acknowledged by developer.
(Wed, 04 Nov 2020 05:23:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 02 Dec 2020 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 214 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.