From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id ECWDBoM8HWLY0AAAgWs5BA (envelope-from ) for ; Mon, 28 Feb 2022 22:20:03 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id OFkkBIM8HWLkJAEA9RJhRA (envelope-from ) for ; Mon, 28 Feb 2022 22:20:03 +0100 Received: from mail.notmuchmail.org (yantan.tethera.net [135.181.149.255]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AEEEB295CB for ; Mon, 28 Feb 2022 22:19:57 +0100 (CET) Received: from yantan.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id BE9D15F6C9; Mon, 28 Feb 2022 21:19:54 +0000 (UTC) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.98]) by mail.notmuchmail.org (Postfix) with ESMTPS id 1A05D5F6BE for ; Mon, 28 Feb 2022 21:19:52 +0000 (UTC) Received: from [46.244.193.28] (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 1nOnQd-0001SV-C9; Mon, 28 Feb 2022 22:19:35 +0100 Message-Id: From: Alexander Adolf To: Tomi Ollila , Utkarsh Singh , Notmuch mailing list Subject: Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion) In-Reply-To: References: <87bkzhbez9.fsf@gmail.com> <115f4649ac25dff4073a32dba70e6db7@condition-alpha.com> Date: Mon, 28 Feb 2022 22:19:49 +0100 MIME-Version: 1.0 X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Message-ID-Hash: EFZFCAA6MGN4N7VUGSEJ4ADVE36MRJC2 X-Message-ID-Hash: EFZFCAA6MGN4N7VUGSEJ4ADVE36MRJC2 X-MailFrom: alexander.adolf@condition-alpha.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN X-Migadu-Country: DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1646083197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=RYIUX9ttgJkdInJR12lZqLBEKag6+964OEnIKza6FHA=; b=Gw4/bM/tqpyP5h0vUYebB2/aFwH6nqp+Zd07Vf9/3KwdtBUhmWSHih2fiuBRC1oycrdbK7 o3N+X4OYhogJgUtOdeh7maq59qrTsNQPTbUVsXbi2qCJXeHVRUf+XDdMcdUJ1JvG9odwej Sz3gyf6vQLgrPdWSl/Am7gBv57Dc6sqFZmjJVHfRn1kji1pJA+DSydReqBnvRarTN1AsqR +40/BEl71Z5hxTeYKRxk9COKS27zgOOdI3h2ymfVeAKsKWg5CXwpBGWZj1GtSNJC6/Q5Ha 9h6WvjOq3gO6wxr7guk1ulXEsu3IbwBrt9WIDVzIz+5/3rxJr6WoMvFx9VsqAA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1646083197; a=rsa-sha256; cv=none; b=nz37ORMnLAI3K+C4ECDTIrAq5V+lw9IV+9bGqM+XdqtD/JIAy75N0oQriCiVbHOQbfCEPy vJycM3sAT9eThV4YnOVNEXyxIEI8/4j5I8tqwFAlXHEtNCQ+sBUcUkXV9XjIIYshVTUkye 39dy7+6sCMRpFIlvCa4JagQBu6e1GDFJP94HIpXz2C0Tw0UqGS7qBTDn64+eUXiPpsKfq+ Q3YSgGC0+v055/sMexT4mlhC0t6hRtiPnYjdzO2SJi47h86AJant/jZc8lbHKEaMRScQce CAcyDzmW98uvz2cbUU9oEQFiYvR+hKvHzq+pKxzIQJ3F231Nq8f9Q4T8RPUE/A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 135.181.149.255 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: -3.27 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 135.181.149.255 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: AEEEB295CB X-Spam-Score: -3.27 X-Migadu-Scanner: scn0.migadu.com X-TUID: oMZKaCK3rtX0 Tomi, apologies for the delay in getting back to you. I'm moving office, so had a couple of other chores for having fun with. ;-) Tomi Ollila writes: > [...] >> In case not, how can I prevent modification of message-completion-alist >> by notmuch, and still have notmuch use the 'internal mechanism for >> generating address completion candidates? > > My guess would be some elisp is required... > [...] That's a very good first guess. Always. ;-D I'm happy to have a go at contributing a patch to enable users to use completion-at-point for address completion. What would be the least controversial way forward? I can currently think of two variants. Variant 1 "minimally invasive surgery": Adding a new, Boolean custom variable which controls modification of message-completion-alist. notmuch-address-setup would need to be modified to make use of it. Pros: "minimally invasive surgery" Cons: High entry barrier (the end user needs to define his/her own function producing a completion table for email addresses, and must hence have a good understanding of how both, notmuch-address.el, and completion-at-point work). notmuch-address-command 'as-is retains its not too stringently defined semantics. Variant 2 "core Emacs": Adding a new, choice type custom variable which controls the framework to use for address completion; possible values are "completing-read (minibuffer UI)", and "completion-at-point (in-buffer UI)". At the same time, notmuch-address-use-company and notmuch-address-command 'as-is would be deprecated. A new function would be added to notmuch-address.el, which returns a completion table for completion-at-point. notmuch-address-setup would then need to modified to add either said new function, or notmuch-address-expand-name to message-completion-alist, depending on the chosen completion framework type. Pros: Uses core Emacs functionality (completing-read, or completion-at-point), hence removes dependency on 3rd party packages, and thus would make notmuch-address.el (even) more future proof. High-level configuration option lowers entry barrier for end users (no knowledge of notmuch-address.el, or completion-at-point required). Cons: Paves the way for removing company from notmuch-address.el. Company can use completion-at-point as a back-end (company-capf), so end users can continue to use company if they wish, but need to adapt their configuration. Looking forward to your thoughts, --alexander