Re: [PATCH] EUDC email addresses via completion-at-point in message-mode

[Alexander Adolf <alexander.adolf@condition-alpha.com>]

Hello Thomas,

Many thanks for your swift response.

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> [...]
> I tested this patch with my current setup, and it doesn't break
> anything,

I'm glad to hear this.

> [...]
> Is there a way to implement eudc-capf-complete such that it doesn't need
> eudc-capf-modes?  I don't like the fact that eudc-capf-modes would need
> to be updated every time a new mode wants to use eudc-capf-complete.

Yes, it may at first seem onerous having to add each new mode to
eudc-capf-modes. But the integration works both ways: eudc-capf-complete
also needs to be able to work out whether point is on a line where email
addresses are wanted/useful. Hence, some basic assumptions
eudc-capf-complete makes about the mode in which it is used, need to be
confirmed first. For the modes listed in eudc-capf-modes, these
assumptions have been confirmed.

> What would go wrong if you just omitted the mode check? (Maybe I'm
> missing something about completion-at-point's design here.)

I am trying to limit the cases where eudc-capf-complete "kicks in" to
those where I think it can be assumed that its results will quite
certainly desirable. The reason is that completion-at-point works along
the functions in completion-at-point-functions, and stops when the first
function returns a completion table. Thus, by calling eudc-capf-complete
too "aggressively", more useful completion results may be prevented from
being offered to the user.

The check to establish whether point is in a suitable header line, calls
mail-abbrev-in-expansion-header-p (from mailabbrev.el). I haven't tested
what effects calling this in any other mode than mail-mode or
message-mode has. It may well work ok in the majority of cases, but then
the list of "other modes" to test could potentially be quite long...

Also, an EUDC query may take a second or two (remote servers and stuff),
so triggering it when not useful could hamper the speed of editing
without user-visible benefit.

> Can you add an example in message-mode's manual, for how to make use of
> completion-at-point, even if it means mentioning a specific
> completion-at-point UI package?

Um, you just call it? That said, I'd of course be happy to add a couple
of sentences along the lines of what I explain below.

> Currently I use:
>
>      (with-eval-after-load "message"
>        (define-key message-mode-map
>         [(control ?c) (tab)]
>         'eudc-expand-try-all))
>
> as per the EUDC manual.  I shouldn't need that anymore with this patch,
> correct?  What completion-at-point UI package should I install in order
> to test this?

You don't need any additional package to test it. Just start composing a
new message in message-mode (e.g. "C-x m"), put point in the "To:" line,
type a substring you know there will be a match for, and then invoke
completion-at-point (e.g. "M-: (completion-at-point)"). The default UI
is completing-read (i.e. you'll see candidates presented in the
minibuffer).

By default, message-mode binds TAB to message-tab, which in turn calls
completion-at-point. Depending on your keymap setup it may thus be
sufficient to type TAB in the "To:" line, or to change your setup to
replace eudc-expand-try-all with completion-at-point.

The only info documentation about in-buffer completion using
completion-at-point I was able to find, is the info node "Completion for
Symbol Names", which is rather short IMO. Whereas minibuffer completion
enjoys a quite extensive info documentation (see info node
"Completion").


Cheers, and looking forward to your thoughts,

  --alexander