emacs-devel
[Top][All Lists]
Advanced

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

Re: [elpa] externals/ebdb 9e7a96f: Add experimental ebdb-completion-at-p


From: Eric Abrahamsen
Subject: Re: [elpa] externals/ebdb 9e7a96f: Add experimental ebdb-completion-at-point-function
Date: Fri, 23 Mar 2018 13:50:31 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> +;; Experimental completion-at-point function.  I'm not sure this is a
>> +;; good idea yet -- with a large enough EBDB database, nearly any
>> +;; string is completable, meaning the other completion-at-point
>> +;; functions will rarely get a chance.
>> +(defun ebdb-completion-at-point-function ()
> [...]
>> +    (when completions
>> +      (list start (point)
>> +        (mapcar
>> +         (lambda (str)
>> +           ;; Gross.
>> +           (if (string-match-p "@" str)
>> +               str
>> +             (capitalize str)))
>> +         completions)
>> +        '(:exclusive no)))))
> Completion-at-point-functions are expected to be cheap/fast (it's normal
> to call it in post-command-hook) and in order to work correctly the
> completion table it returns should ideally not depend on the text
> between START and END (i.e. it's OK to look at the text between
> START..END in order to choose between an email completion table and
> a file completion table, but it shouldn't throw away emails just
> because they don't seem to match the text between START..END).
>
> Also in order to be effective, you want them to be selective, e.g. only
> match when we're pretty sure that the completion-table we return is
> relevant (e.g. we're on a "To:" line in a message-mode buffer), so it
> usually depends on the major mode in which it's used.
>
> EBDB might elect not to provide a completion-at-point-function but
> instead to provide only a completion-table (or a bunch of completion
> tables).  Then message-mode could use that completion-table when it
> determines that we're completing an email address.

Thanks for these notes!

In part I was wondering if it would be useful to provide completion on
contact names in other contexts besides message headers, but I suppose
the right thing to do is just add contact names to the user's personal
spelling dictionary, and allow them to complete names as part of
spell-checking/ispell-complete-word. EBDB provides other tools for
inserting contact information in random contexts.

So this completion function should be targeted specifically at
message/mail-mode header lines. I'll no longer override <TAB> in that
message-mode, but instead tie into what's already there.

In message-mode, c-a-p-f contains `message-completion-function', which
consults `message-completion-alist' (which contains a FIXME: "Make it
possible to use the standard completion UI."), which hands off to
`message-expand-name', which is hard-coded to use either eudc, bbdb, or
`expand-abbrev'. There is a user option,
`message-expand-name-databases', but it's mostly useless as putting new
databases in there won't actually let you use them.

Looks like you added that FIXME! If you outline how you think this ought
to look, I can take a stab at patching message.el. At what level should
these functions be intervening?

My only reservation is that BBDB/EBDB mail completion first completes a
contact mail address, and subsequently cycles through that contact's
other addresses. Is this something that the standard mechanisms can
replicate?

Thanks,
Eric




reply via email to

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