From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] EUDC email addresses via completion-at-point in message-mode Date: Wed, 13 Apr 2022 16:44:28 +0200 Message-ID: <4c3f728f989e832d224be1503808a682@condition-alpha.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28265"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Thomas Fitzsimmons Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 13 16:46:00 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neeFo-00072V-DT for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Apr 2022 16:45:56 +0200 Original-Received: from localhost ([::1]:42276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1neeFn-0005Cn-61 for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Apr 2022 10:45:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neeEU-0004BH-LJ for emacs-devel@gnu.org; Wed, 13 Apr 2022 10:44:34 -0400 Original-Received: from smtprelay08.ispgateway.de ([134.119.228.110]:63983) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neeES-0008Bb-Pk for emacs-devel@gnu.org; Wed, 13 Apr 2022 10:44:34 -0400 Original-Received: from [46.244.200.233] (helo=condition-alpha.com) by smtprelay08.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1neeEa-000189-Ts; Wed, 13 Apr 2022 16:44:41 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=134.119.228.110; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay08.ispgateway.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:288361 Archived-At: Hello Thomas, Many thanks for your swift response. Thomas Fitzsimmons 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. > 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. > 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. 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"). Cheers, and looking forward to your thoughts, --alexander