From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FAKE_REPLY_C,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22824 invoked from network); 6 Dec 2021 17:54:23 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 6 Dec 2021 17:54:23 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1muIBx-000YP9-2u for ml@inbox.vuxu.org; Mon, 06 Dec 2021 11:54:21 -0600 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94.2) (envelope-from ) id 1muIBw-001UKw-En for ml@inbox.vuxu.org; Mon, 06 Dec 2021 11:54:20 -0600 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1muIBv-001UKq-Jg for ding@lists.math.uh.edu; Mon, 06 Dec 2021 11:54:19 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1muIBt-009ch8-B8 for ding@lists.math.uh.edu; Mon, 06 Dec 2021 11:54:19 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:Message-ID:Date:Subject:From:To: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=TFDYmRt1DjagGXRJ/CfHkT+4jLGvz9e9JMb0F0IX8hw=; b=j1ICkUfezOdo9R1lTjP2jld+z0 wb80afdqNmRD0cuMb+tq8zFRmTFf2hZ9PceOd8BXTkG7MbHnbEzPuEXnqCiiqZksXsTg6Oce6nPQs qe5e12kt/kgkkt7hUzqAALpVtO2QxWLPgibuLZtk5j4aTAGmd4Ddo6wxVmDMnQm2kB7M=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muIBl-0007dj-K4 for ding@gnus.org; Mon, 06 Dec 2021 18:54:12 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1muIBi-00071I-Ox for ding@gnus.org; Mon, 06 Dec 2021 18:54:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: Aliases with mailing lists Date: Mon, 06 Dec 2021 09:53:54 -0800 Message-ID: <875ys1ei19.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cancel-Lock: sha1:HD5Sf6JcRuk7DCnaG+yAht/0m6M= List-ID: Precedence: bulk Eric S Fraga writes: > On Friday, 3 Dec 2021 at 10:43, Eric Abrahamsen wrote: >> If your Emacs is recent and you have the option >> `message-expand-name-standard-ui', try setting it to t and see what that >> does. > > I am trying this out (having been using bbdb-handy up to now). I cannot > quite figure out what it is doing. I use bbdb as my address book. Mail > aliases from bbdb work just fine (typing "somealias SPC") but tab > completion is strange. It works, in the sense that if I type "somename > TAB", I get a completion list. However, it is unclear where the > contents of this list are coming from. > > TAB is bound to message-tab which then invokes message-expand-name which > should be checking bbdb but it does not appear to (or is missing many > entries from bbdb). > > Any pointers or clarifications would be welcome. Ha, you sort of called my bluff here, I hadn't looked closely at what that option is actually doing. Basically, in a perfect world, in a name/group header would call `completion-at-point' directly. Programs that want to provide names and addresses for completion would push their tables onto `completion-at-point-functions'. The nice thing about this is that there are several user options that would govern how completion works (giving you more control), and also multiple backends can put their tables in, meaning that you could cycle through completions that come from various packages. At present things have gotten fairly convoluted. If you set `message-expand-name-standard-ui' to t, what happens is: `message-tab' calls `completion-at-point', which finds `message-completion-function' and calls that, which sees that we're in a "To:" header and ends up calling `message-expand-name'. `message-expand-name' sees that `message-expand-name-standard-ui' is t, and returns the standard set of capf data, including `message--name-table' as the completion table. This table simply does what `message-expand-name' otherwise does directly: checks if we're using eudc or bbdb (*EBDB maintainer wipes away a tear*), and calls `message--bbdb-query-with-words' which, god willing and the creek don't rise, ends up with the same result as if `message-expand-name-standard-ui' were nil, and we'd called `bbdb-complete-name'. Apologies if that's more detail than you wanted; I'm also trying to make sense of this myself. The point being, it *ought* to behave the same way, just with (potentially) more completion candidates from multiple backends, and more user control over the completion style. If you're seeing wrong completions from BBDB, that means that `message--bbdb-query-with-words' is not doing the same job as `bbdb-complete-name', and that should be considered a bug, I guess. Whew. Eric