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.bugs Subject: bug#59314: 29.0.50; EUDC and message-mode header completion Date: Wed, 16 Nov 2022 22:28:23 -0500 Message-ID: References: <87a64q7p25.fsf@ericabrahamsen.net> <878rka1y4n.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="19516"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Alexander Adolf , 59314@debbugs.gnu.org To: Eric Abrahamsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 17 04:29:17 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ovVaW-0004pV-Oc for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Nov 2022 04:29:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovVaT-00058l-PS; Wed, 16 Nov 2022 22:29:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovVaI-00053s-Ha for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 22:29:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ovVaI-00063g-9N for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 22:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ovVaI-0007Rw-2m for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2022 22:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Thomas Fitzsimmons Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Nov 2022 03:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59314 X-GNU-PR-Package: emacs Original-Received: via spool by 59314-submit@debbugs.gnu.org id=B59314.166865571328600 (code B ref 59314); Thu, 17 Nov 2022 03:29:02 +0000 Original-Received: (at 59314) by debbugs.gnu.org; 17 Nov 2022 03:28:33 +0000 Original-Received: from localhost ([127.0.0.1]:58679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovVZp-0007RD-6m for submit@debbugs.gnu.org; Wed, 16 Nov 2022 22:28:33 -0500 Original-Received: from mail.fitzsim.org ([69.165.165.189]:43264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovVZm-0007Qy-Hz for 59314@debbugs.gnu.org; Wed, 16 Nov 2022 22:28:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fitzsim.org ; s=20220430; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4XwQedQDB2K6glzY4j73/KdOop0/R30V0iYnZSuEmO0=; b=jemsdUyHVCdGdZqTdNiA94HXaG BMs/WSDr6Nuu6mmwrNbQzJ9jtwcHpRlqyUNcdzj+qRAHR3JJWZ0+f/yqfbiuX6juUr2aAJQjh+8FF umeP4VeFxV9Zkw73juUUSAsJBaBPY7qNkNfHBreTNMnvU/uDQnI2QKsmbMzJci1dPe/5btPvow0Pg t6O5Dm6Trvv0x3AghYfNAnzNKQ/9ilr/Y1/BYY3bhBOlTgW5Rv67zxfv6nt4tdPvYNkHfnC5dwbio Y+uFnhfDzhccjOr+H/8XPGsY+UNsI+ufqz4VsKtkIOX9JE+z8BHxaVnykeMenlqjiqV4mKINn5JG/ t3wimVnQ==; Original-Received: from [192.168.1.1] (helo=localhost.localdomain) by mail.fitzsim.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ovVZf-000DJm-G6; Wed, 16 Nov 2022 22:28:24 -0500 In-Reply-To: <878rka1y4n.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Wed, 16 Nov 2022 11:46:00 -0800") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248075 Archived-At: Eric Abrahamsen writes: > On 11/16/22 14:18 PM, Thomas Fitzsimmons wrote: >> Hi Eric, >> >> Thanks for filing this. >> >> Eric Abrahamsen writes: >> >>> Address completion in message-mode has stopped working in master, >>> possibly as a result of 0e25a39e69acca0324c326ea8e46b1725594bff5. This >>> has been reported for several contact-management backends that expect to >>> have their completions available with . >>> >>> `completion-at-point-functions' contains '(eudc-capf-complete >>> message-completion-function t) at this point -- `eudc-capf-complete' >>> returns no matches, and no other functions in the list are consulted. >> >> I just checked and I didn't think the recent patch I pushed, >> 0e25a39e6..., should have affected completion-at-point-functions. It >> did change the default of eudc-server-hotlist from `nil' to >> `(("localhost" . ecomplete) ("localhost" . mailabbrev))". I thought >> that should only affect EUDC users who have not customized >> eudc-server-hotlist. >> >> `eudc-capf-complete' was added to `message-mode' in commit >> 620ac6735... I'm pretty sure that commenting out this line in >> message.el will restore prior behaviour, but I don't yet know what prior >> behaviour should be (see below). >> >> (add-hook 'completion-at-point-functions #'message-completion-function nil t) >> >>> On gnus.general, someone using BBDB and corfu reported that this recipe >>> fixed the problem: >>> >>> (setq eudc-server-hotlist '(("localhost" . bbdb))) >>> >>> (add-hook 'message-mode-hook >>> (lambda () >>> (setq-local completion-at-point-functions >>> (delq 'message-completion-function >>> completion-at-point-functions)))) >>> >>> Someone else *not* using corfu reported that that didn't work for them. >>> Dunno. >> >> I'm not sure what the out-of-the-box behaviour here is meant to be. Can >> you make a recipe starting from "emacs -Q" (including adding dummy email >> addresses somewhere) that makes completion work how you want it to? For >> me: >> >> emacs -Q >> C-x m TAB >> >> inserts four spaces and prints in *Messages*: >> >> Loading eudcb-ecomplete...done >> Loading eudcb-mailabbrev...done >> >> (Those are new, due to 0e25a39e6... but I thought should be harmless.) > > Yuck, it's been a long time since I looked at this... > > In emacs -Q, message-mode `completion-at-point-functions' is: > > (eudc-capf-complete message-completion-function t) > > Actually that's what it is in my regular Emacs, as well. All I'd need > for EBDB (and BBDB and everything else) is for > `message-completion-function' to get called, which it isn't. I believe > you could allow this by having `eudc-capf-complete' return nil, or have > `eudc-capf-message-expand-name' return a `(list beg end )' > structure that includes the prop `:exclusive 'no' at the end of it. That > would allow a fallthrough to the next function. > > In fact this whole message-mode thing is an impossible tangle, burritos > within burritos, and it would be great to get rid of it altogether. > > `message-completion-function' already looks at where it is in the > message buffer, and calls `message-expand-name' if it's in a "name" > header. That function consults `message-expand-name-databases', and > *that's* where EBDB should put its completion table, except > `message-expand-name-databases' is hardcoded to (or 'eudc 'bbdb) for no > reason. Should we set `message-expand-name-databases' to (or 'eudc 'bbdb 'ebdb)? Would that avoid the need to clobber `message-expand-name' for your use case? I'd be fine adding "known packages" there, as long as referring to non-core packages doesn't break anything (which it doesn't seem to, since BBDB is non-core, in GNU ELPA). > So I need to clobber `message-expand-name' altogether. When I use EUDC, I too clobber `message-mode's completion, by binding TAB to `eudc-expand-try-all'. Part of the effort around eudc-capf was trying to improve the default so that this clobbering wouldn't be necessary. But as you point out, we're not there yet. > And EUDC having a function on `completion-at-point-functions' is > wrapping yet another burrito outside the existing burritos, because now > EUDC has a completion function both inside and outside message-mode's > own completion machinery. > > In fact the docstring of `eudc-capf-message-expand-name' makes it sound > like it thinks it's being called as part of `message-expand-name', but > now it isn't -- it's being called as part of the capf machinery. Or > rather, it could potentially be called in both places. > I think a half-stick of dynamite is the only real solution. Agreed it's currently hard to navigate, but I'd prefer to take minimal steps from what we have now, since people have configurations that depend on the current state. I think we should probably create a set of core "out-of-the-box" `message-mode' completion ERT tests. For example, given: "emacs -Q" + EBDB + a single EBDB entry "emacs-ert-test@ebdb.gnu.org" will "C-x m emacs TAB" work? If it won't, will the above-suggested `message-expand-name-databases' make it work? Once we get "emacs-ert-test" examples for @bbdb.gnu.org, @ecomplete.gnu.org, @mailabbrev.gnu.org, we'll be able to test how the various completion backends interact, and I'm thinking that will help us simplify TAB's default behaviour in `message-mode' (while preserving backward compatibility). Do you want to try adding a core ERT test for EBDB completion? Optional core tests are allowed to depend on GNU ELPA packages. Thanks, Thomas