From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
To: Alexander Adolf <alexander.adolf@condition-alpha.com>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] EUDC email addresses via completion-at-point in message-mode
Date: Wed, 13 Apr 2022 20:26:20 -0400 [thread overview]
Message-ID: <m3fsmgpl1v.fsf@fitzsim.org> (raw)
In-Reply-To: <4c3f728f989e832d224be1503808a682@condition-alpha.com> (Alexander Adolf's message of "Wed, 13 Apr 2022 16:44:28 +0200")
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
next prev parent reply other threads:[~2022-04-14 0:26 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-09 16:24 [PATCH] EUDC email addresses via completion-at-point in message-mode Alexander Adolf
2022-04-12 21:12 ` Thomas Fitzsimmons
2022-04-13 14:44 ` Alexander Adolf
2022-04-14 0:26 ` Thomas Fitzsimmons [this message]
2022-04-15 21:23 ` Alexander Adolf
2022-04-14 13:02 ` Eric S Fraga
2022-04-14 13:27 ` Thomas Fitzsimmons
2022-04-14 13:52 ` Eric S Fraga
2022-04-15 21:39 ` Alexander Adolf
2022-04-17 12:12 ` Eric S Fraga
2022-04-15 21:35 ` Alexander Adolf
2022-04-17 12:20 ` Eric S Fraga
2022-04-17 13:58 ` Thomas Fitzsimmons
2022-04-17 17:21 ` Eric S Fraga
2022-04-14 14:02 ` Stefan Monnier
2022-04-15 21:58 ` Alexander Adolf
2022-04-15 22:57 ` Eric Abrahamsen
2022-04-14 1:44 ` Eric Abrahamsen
2022-04-14 13:04 ` Eric S Fraga
2022-04-14 15:17 ` Eric Abrahamsen
2022-04-14 15:26 ` Stefan Monnier
2022-04-15 16:31 ` Eric Abrahamsen
2022-04-15 17:17 ` Stefan Monnier
2022-04-15 22:30 ` Alexander Adolf
2022-04-15 22:16 ` Alexander Adolf
2022-04-15 22:58 ` Stefan Monnier
2022-04-26 14:39 ` Alexander Adolf
2022-04-26 18:58 ` Filipp Gunbin
2022-04-28 17:15 ` Alexander Adolf
2022-04-29 14:43 ` Thomas Fitzsimmons
2022-05-02 17:10 ` Alexander Adolf
2022-05-03 18:03 ` Thomas Fitzsimmons
2022-05-05 16:32 ` Alexander Adolf
2022-05-05 16:57 ` Thomas Fitzsimmons
2022-05-10 21:16 ` Thomas Fitzsimmons
2022-05-16 12:35 ` Alexander Adolf
2022-04-29 23:04 ` Filipp Gunbin
2022-05-02 21:38 ` Alexander Adolf
2022-05-02 22:32 ` Filipp Gunbin
2022-05-03 16:18 ` Alexander Adolf
2022-05-03 16:22 ` Alexander Adolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3fsmgpl1v.fsf@fitzsim.org \
--to=fitzsim@fitzsim.org \
--cc=alexander.adolf@condition-alpha.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).