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

[Alexander Adolf]

Hello Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> [...]
> Thank you for working on this!

It seems several people have already been scratching their heads about
this. I just happen to be the first one to stick it out the window...
;-)

> I think everyone can agree that the current setup is tricky to work
> within. 

Very true.

> As the author of (yet another) contact management package, 

Curious; which one?

> I do what I assume anyone else would do: clobber the binding of TAB
> altogether.

Agree.

> I understand that EUDC has the capability of combining results from
> multiple backends,

Yep.

> but completion-at-point also has those capabilities,

I had hoped that ":exclusive 'no" would do this, but haven't been able
to meet my expectations.

Any hints how to go about this?

As an aside, in minibuffer.el, in function completion--capf-wrapper, the
comment on line 2559 states a caveat on ":exclusive 'no":
---------------------------- Begin Quote -----------------------------
;; FIXME: Here we'd need to decide whether there are
;; valid completions against the current text.  But this depends
;; on the actual completion UI (e.g. with the default completion
;; it depends on completion-style) ;-(
;; We approximate this result by checking whether prefix
;; completion might work, which means that non-prefix completion
;; will not work (or not right) for completion functions that
;; are non-exclusive.
----------------------------- End Quote ------------------------------

> and personally I would much prefer to see message-mode make use of one
> of completion-table combining functions. Better to be wrapped inside
> one burrito than two!
>
> The `message-tab' would still need to check where it's been called and
> make a decision before calling `completion-at-point', but it seems much
> cleaner for each package to provide a function that's suitable for use
> in a combined capf completion table, rather than writing an adapter for
> EUDC.
>
> What do you think?
> [...]

I basically agree with your assessment, but have come to a slightly
different conclusion with respect to what to do about it. See my
first response to Stefan Monnier on this thread for more details.


Cheers,

  --alexander