[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