[Top][All Lists]

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

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

From: Eric Abrahamsen
Subject: Re: Add integration to gnus-search library, if present
Date: Tue, 10 Nov 2020 21:12:47 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

"Roland Winkler" <> writes:

> On Fri Nov 6 2020 Eric Abrahamsen wrote:
>> 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.
> If that's the case, it might make sense to have a new variable
> bbdb-completion-at-point-hashtable the content of which bbdb users
> can customize similar to bbdb-completion-list.  Then this customized
> hashtable can be made available to the "outside world" such as the
> gnus-search library.

I've been thinking about this a bit: there's no need to create a new
hashtable, since all that's needed is a list of strings to complete on.
We also want this list to be dynamic so that it reflects updates to the
BBDB as the user makes them.

The completion code provides a `completion-table-dynamic' function that
wraps a function and returns a completion table, and that could be the
ticket. I've attached another patch to show how that could work.

Possible issues:

- This will rebuild the string table at every single use of
  `completion-at-point' (in other words, at every use of TAB in the
  minibuffer). I haven't tried it, maybe it would be slow. But maybe
  not! I don't think it's worth optimizing before it's tested.
- It reuses the value of `bbdb-completion-list' as a predicate. Perhaps
  it would be better to have a separate and equivalent option to govern
  this completion, but it seemed to me that if the user went to the
  trouble of customizing `bbdb-completion-list', they'd probably want
  the same behavior here. But it would be easy to add a new option that
  governed this in particular.

How does this look? It might be good to check with Stefan Monnier, as he
wrote most of the completion stuff and usually seems happy to tell me
where I've gone wrong.


Attachment: bbdb-capf.diff
Description: Text Data

reply via email to

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