Re: Add integration to gnus-search library, if present

"Roland Winkler" <[email protected]> writes:

> On Fri Nov 6 2020 Eric Abrahamsen wrote:
>> I can imagine users wanting to search all those value types -- users
>> certainly might want to search contact names -- perhaps with the
>> exception of lf-name. If it's a simple matter of filtering out unhelpful
>> strings, that filtering should be done in gnus-search.el, as part of the
>> completion-at-point return process. If we wanted to build some extra
>> strings (for instance, searching on email address domain names only)
>> then that extra work could be done in BBDB.
>
> I have not yet used this feature of gnus you want to support.
> I guess the question is in what context this feature is supposed
> to be used.

Basically Gnus has a new way of entering queries to search for messages.
You might search "from:urusula since:1w subject:party" -- this query is
entered in the minibuffer. Gnus uses the completion-at-point mechanism
to provide TAB completion for valid search keys ("from", "subject",
etc). The same mechanism can provide completion for search _values_.

There's a variable `gnus-search-contact-tables' where contact management
packages can push "completion tables" (alists, hashtables, lists of
strings) with contact data. When the user is entering the value part of
a person-related search key ("from", "cc", etc) and hits TAB, the
contact tables are merged, and sent along with the string entered so far
to the completion-at-point mechanism. So "to:eric@er<TAB>" would send
"eric@er" to the completion mechanism, along with tables holding my full
email address, which would complete the address.

> I can imagine that it could make more sense if bbdb supported
> completion-at-point at a higher level than just exporting
> bbdb-hashtable and using this in a context that knows nothing about
> bbdb beyond bbdb-hashtable.  But again, I do not know much about the
> completion-at-point machinery.  I hope it may allow such a
> higher-level support.  I can imagine that this will be useful also
> beyond gnus.

My understanding of completion-at-point is that it wants consumer
programs to be as "dumb" as possible, allowing the user's customizations
to take full effect. It prefers that a completion-at-point function
simply return the start/end substring indexes, and the table. It can
also return a :predicate for filtering the table, an :exit-function for
doing post-completion cleanup, and a few other things.

But the idea is that the work is separated out a bit. In this case the
completion-at-point function is `gnus-search--complete-key-data', which
looks at the string the user has entered so far, decides what type of
completion should be performed (search key, search value, what type of
search value), and then returns the appropriate buffer string indexes
and completion table.

A package like BBDB is one step removed from this logic. Ideally its
only job should be to provide a table of contact-related strings that
the user might want to complete on. It shouldn't be involved in the
"downstream" logic of examining user input, etc.

This is a bit new for me, as well, but that's my understanding.

eric