bbdb-user
[Top][All Lists]
Advanced

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

Re: Questions on completion


From: Basil L. Contovounesios
Subject: Re: Questions on completion
Date: Mon, 30 Oct 2017 17:21:18 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On Sun, Oct 29 2017, at 18:34, Roland Winkler <address@hidden> wrote:

> On Wed Oct 25 2017 Basil L. Contovounesios wrote:
>> 1) AIUI, the user option bbdb-completion-list lists all
>>    fields it is currently possible to complete. Are there
>>    any plans to support completing more fields, e.g. the
>>    mail-name xfield? If not, are there any objections or
>>    technical obstacles to such a feature?
>
> There is certainly no fundamental obstacle preventing such
> a feature. - Could you explain with a few words the usage
> scenario you have in mind for when the proposed feature
> will come handy? (I do not use the mail-name xfield at
> all; i never found a need for it.)

I keep records with full names (titles, middle names, etc.)
in multiple scripts (Latin and Greek), but in emails I
prefer to use abbreviated Latinised names, as they both are
more universal and look better in my MUA.  I found the
mail-name xfield to be a convenient place to store these.

> Could you explain with a few words

If you are uninterested in reading more than a few words on
my relevant configuration, please ignore the following
paragraph:

In order to make the aforementioned organisational approach
more effective, I add bbdb-mail-name to
bbdb-mua-summary-unification-list, set my MUA (Gnus) to
perform BBDB unification in its summary buffer, and advise
bbdb-complete-mail to first pass the candidates it offers
through bbdb-mua-summary-unify.  The only missing aspect of
this approach is offering Latinised mail-names as completion
candidates.

>> 2) Why does bbdb-complete-mail use a *Completions* buffer
>>    populated by the display-completion-list function,
>>    instead of using a higher-level completion command such
>>    as completing-read or completing-read-multiple? Would it
>>    be favourable and/or possible to switch to using such an
>>    interface, or support both?
>
> bbdb-complete-mail runs in the mail buffer, whereas
> completing-read(-multiple) runs in the minibuffer.  Apart
> from that, they behave similarly: both use a *Completions*
> buffer to display possible completions.
>
> When would it be useful to run the completion performed by
> bbdb-complete-mail not in the mail buffer but in a
> minibuffer?
>
> Note also that bbdb-completing-read-mails provides
> minibuffer completion similar to bbdb-complete-mail.  This
> is used in a couple of places (search the code).

Sorry, I wasn't thinking clearly when I wrote my email and
thank you for pointing out bbdb-completing-read-mails, which
I hadn't noticed.  I am not lobbying for minibuffer over
in-buffer completion.  What I meant to say is the following.

AFAICT, Emacs now provides two standard, high-level and
configurable interfaces to arbitrary completion: in-buffer
completion via completion-at-point/completion-in-region and
minibuffer completion via completing-read.

At first glance, bbdb-complete-mail seems to emulate some of
the work completion-at-point/completion-in-region
could/should be doing, e.g. managing the *Completions*
buffer.  Though I am not particularly familiar with the
code, I have a feeling that bbdb-complete-mail could be
simplified if it were refactored to use one of these
built-in functions instead.

Furthermore, bbdb-completing-read-mails is not *really*
performing minibuffer completion by using completing-read or
similar.  Its only difference from bbdb-complete-mail is
that the user's input is inserted in the minibuffer, rather
than the mail buffer.

The potential for simplification is not an argument I can
further support without first becoming more familiar with
the code.  From a user's point of view, however, there is a
clear benefit in configurability from using the built-in
methods.  bbdb-complete-mail currently emulates the default
completion frontend of Emacs (i.e. the *Completions*
buffer), but many Emacs users (myself included) prefer to
use frontends such as those provided by ivy[1] or helm[2],
which work by customising completing-read-function and
completion-in-region-function, amongst other things.

In other words, creating a *Completions* buffer is not a
complete substitute for using one of the built-in completion
methods and may even be duplicating some of their
functionality.  I was thus wondering whether there is a
preference for this approach; if it is, say, a historical
artefact; and what people think of switching to one of the
aforementioned completion methods.

If no-one is opposed to this idea, but it is deemed a
low-priority wishlist feature, I would be interested to
investigate further, though I probably wouldn't get around
to it for another month or so.

Footnotes: 
[1]  https://github.com/abo-abo/swiper

[2]  https://emacs-helm.github.io/helm/

Thanks,

-- 
Basil



reply via email to

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