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

[Thomas Fitzsimmons]

Hi Alexander,

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> 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.

OK.

>> 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.

OK, I see.

>> 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.

It looks like the default binding for TAB in message-mode-map is
message-tab; so I tested by rebinding TAB to message-tab.  It worked,
except I was expecting case sensitive results.  Can you please change
`completion-ignore-case' to nil?  And figure out what to do with
`completion-table-with-cache''s IGNORE-CASE argument accordingly, if
necessary?

I had to run (message-tab) repeatedly to get the final result if
multiple results were available, whereas with eudc-expand-try-all bound
to TAB, I get a "Multiple matches found; choose one:" prompt.  I guess
that's just a different UI style for completion-at-point?  FWIW, I think
I prefer eudc-expand-try-all's behaviour.

I have one bbdb entry and one LDAP server in the hotlist.  It seems like
the LDAP operation happens every time I call (message-tab).  Is that
expected?  Is the completion table caching meant to prevent this?  I
don't like the idea that hitting TAB several times per email address
will result in several calls to the LDAP server.  Can
completion-at-point be made to have the same behaviour as
eudc-expand-try-all, which only results in each backend being queried
once?

> 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").

Depending on the outcome of the above we might want to describe the
alternative completion-at-point and eudc-expand-try-all behaviours in
the EUDC manual.

Thanks,
Thomas