[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