From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thomas Fitzsimmons Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] EUDC email addresses via completion-at-point in message-mode Date: Wed, 13 Apr 2022 20:26:20 -0400 Message-ID: References: <4c3f728f989e832d224be1503808a682@condition-alpha.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34057"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alexander Adolf Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 14 02:27:52 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 1nenKx-0008jo-Vz for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Apr 2022 02:27:52 +0200 Original-Received: from localhost ([::1]:48958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nenKw-0008IW-8j for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Apr 2022 20:27:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41588) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nenJb-0007KS-Kj for emacs-devel@gnu.org; Wed, 13 Apr 2022 20:26:27 -0400 Original-Received: from mail-qt1-x82d.google.com ([2607:f8b0:4864:20::82d]:41897) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nenJZ-0008U8-7j for emacs-devel@gnu.org; Wed, 13 Apr 2022 20:26:27 -0400 Original-Received: by mail-qt1-x82d.google.com with SMTP id r25so2569047qtp.8 for ; Wed, 13 Apr 2022 17:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fitzsim-org.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=UuS2G9avkEoqpAG2+yz9lWL5AbEBsFOLWMYakNiMLKk=; b=cmoVffpl05vLHenLdd/3DhdSqzCyuAgDD/7epRU+eh568W6m55SCpcX+cfX4tUSGD0 8t9Qdh2Z/ewsJ07LdyIIj3o0adfPeooSHbR4gTuThpJKiuWlwtoFyoBoJHCGqMBMcao7 eHK8lOzVtIY0qfZoYq/D07Z1R9Slw4igo5K9JxRZC0jbIQ3+ajZy5X33NEU43wtM5xwv 2C0h3lWLof4+7Jqrw6DgDeN2QRORZaDMZ4T7TrLytEAxer0CboO8upOSqGvbS4xajWVB hLdq7hGXYbFmfB+q9kDCRnUd0iq0eSvFLhtu642QRv5ZI2ooRVoWnNsZt4KGvha02//L rqFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=UuS2G9avkEoqpAG2+yz9lWL5AbEBsFOLWMYakNiMLKk=; b=UpyOSyEaDXHUyeY7l9TIyaTsnX/scbWkqZNbwUxX41WrqYIWpPrSfdsobIxHfVCde7 xMGdXhMwFgOxkptQkwZvp2AOGxgVTw4m/XoWcAZ/3a4/zBTxEPvz2YEuuq9x7zvh7NFn dBjHtNCXiwlkBIr88lKUo7HQywh9kyxoBjGW82s6SeFxpA5EP8d1EsmB5S7xIVHUAHOH 5uIYEKJ5IOOyJich/F+xs/6n1rv8slNL4tU7WjEJ+pOez7K10sn9XJvFmmU549/e/3Kf jSIe72qVJbxPHUfd55Ez1qYS9u9c3DYuqok3WXIV4zF2n0Ep6L56U/CxT+heAgOeJJrM zUGQ== X-Gm-Message-State: AOAM531M9vuyDfe+SegTl//lxTab3oB/oKduM47ZjqnJgQeNB38GTXnZ FbySCRfa80cOYPiA3X5L1mTcEzOrRvxjCA== X-Google-Smtp-Source: ABdhPJxDXmRkWYVwuCmOfMfeCnAq4CJeduaZHpQwQBr/YyFgbKDyMxpYiCGHEqyvdCXETtf+xGm/Mg== X-Received: by 2002:ac8:7d42:0:b0:2e1:bb4d:9364 with SMTP id h2-20020ac87d42000000b002e1bb4d9364mr68436qtb.303.1649895982732; Wed, 13 Apr 2022 17:26:22 -0700 (PDT) Original-Received: from localhost.localdomain (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by smtp.gmail.com with ESMTPSA id g28-20020a05620a109c00b0069c25d4fee4sm196997qkk.32.2022.04.13.17.26.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 17:26:22 -0700 (PDT) In-Reply-To: <4c3f728f989e832d224be1503808a682@condition-alpha.com> (Alexander Adolf's message of "Wed, 13 Apr 2022 16:44:28 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::82d; envelope-from=fitzsim@fitzsim.org; helo=mail-qt1-x82d.google.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:288376 Archived-At: Hi Alexander, Alexander Adolf writes: > 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. 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