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: Sat, 16 Apr 2022 00:16:18 +0200 Message-ID: <053148964ff0c8baaf2dc560f6208df8@condition-alpha.com> References: <87o814wi9l.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3745"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 16 00:17: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 1nfUFQ-0000jA-U2 for ged-emacs-devel@m.gmane-mx.org; Sat, 16 Apr 2022 00:17:00 +0200 Original-Received: from localhost ([::1]:56232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfUFP-0003yq-Dh for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Apr 2022 18:16:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfUEp-0003GP-RC for emacs-devel@gnu.org; Fri, 15 Apr 2022 18:16:23 -0400 Original-Received: from smtprelay03.ispgateway.de ([80.67.31.30]:30431) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfUEo-0000EF-3A for emacs-devel@gnu.org; Fri, 15 Apr 2022 18:16:23 -0400 Original-Received: from [46.244.203.213] (helo=condition-alpha.com) by smtprelay03.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nfUF0-0007Uj-6X; Sat, 16 Apr 2022 00:16:34 +0200 In-Reply-To: <87o814wi9l.fsf@ericabrahamsen.net> X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.31.30; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay03.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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:288466 Archived-At: Hello Eric, Eric Abrahamsen writes: > [...] > Thank you for working on this! It seems several people have already been scratching their heads about this. I just happen to be the first one to stick it out the window... ;-) > I think everyone can agree that the current setup is tricky to work > within. Very true. > As the author of (yet another) contact management package, Curious; which one? > I do what I assume anyone else would do: clobber the binding of TAB > altogether. Agree. > I understand that EUDC has the capability of combining results from > multiple backends, Yep. > but completion-at-point also has those capabilities, I had hoped that ":exclusive 'no" would do this, but haven't been able to meet my expectations. Any hints how to go about this? As an aside, in minibuffer.el, in function completion--capf-wrapper, the comment on line 2559 states a caveat on ":exclusive 'no": ---------------------------- Begin Quote ----------------------------- ;; FIXME: Here we'd need to decide whether there are ;; valid completions against the current text. But this depends ;; on the actual completion UI (e.g. with the default completion ;; it depends on completion-style) ;-( ;; We approximate this result by checking whether prefix ;; completion might work, which means that non-prefix completion ;; will not work (or not right) for completion functions that ;; are non-exclusive. ----------------------------- End Quote ------------------------------ > and personally I would much prefer to see message-mode make use of one > of completion-table combining functions. Better to be wrapped inside > one burrito than two! > > The `message-tab' would still need to check where it's been called and > make a decision before calling `completion-at-point', but it seems much > cleaner for each package to provide a function that's suitable for use > in a combined capf completion table, rather than writing an adapter for > EUDC. > > What do you think? > [...] I basically agree with your assessment, but have come to a slightly different conclusion with respect to what to do about it. See my first response to Stefan Monnier on this thread for more details. Cheers, --alexander