emacs-devel
[Top][All Lists]
Advanced

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

Re: Progress for bug#59314 for emacs-29


From: Alexander Adolf
Subject: Re: Progress for bug#59314 for emacs-29
Date: Fri, 23 Dec 2022 15:59:12 +0100

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +  (when (and (or eudc-server eudc-server-hotlist)
>> +             (seq-some #'derived-mode-p eudc-capf-modes)
>> +             (let ((mail-abbrev-mode-regexp 
>> message-email-recipient-header-regexp))
>> +               (mail-abbrev-in-expansion-header-p)))
>> +    (setq-local completion-styles '(substring partial-completion))
>> +    (eudc-capf--message-expand-name)))
>
> Please don't do that.  `completion-styles` is a user-config, we
> shouldn't mess with it.  Instead you should use
> `completion-category-defaults` (and use a completion table which returns
> an appropriately chosen `category`).  Then users can decide to override
> your choice with `completion-category-overrides`.
> [...]

This was designed as an intermediary step, enabling "early access" to
EUDC in completion-at-point.

The real McCoy will be the changes to message.el I'm working on, and of
which I had circulated a draft earlier. That will have the completion
function responding to the 'metadata request as you describe, of course.
For the purposes of message-mode (which is the only mode I'm using for
email), that's all that'll be needed. eudc-capf.el would be for other
email composing modes (e.g. mail-mode) only.

In this light, instead of investing the work to implement something in
eudc-capf.el now, of which I know that I will have to move from there to
message.el anyways, I think it seems more advisable to drop the
intermediary step altogether, i.e. to drop eudc-capf.el, and put the new
feature off until my updates to message.el will be in a better shape.


Many thanks and looking forward to your thoughts,

  --alexander



reply via email to

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