From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: James N. V. Cash Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers Date: Mon, 02 May 2022 11:32:46 -0400 Message-ID: <87wnf40x29.fsf@occasionallycogent.com> References: <87k0b84tfr.fsf@occasionallycogent.com> <87h76c4ruf.fsf@occasionallycogent.com> <86sfpwwerz.fsf@mail.linkov.net> <87czh03xa9.fsf@occasionallycogent.com> <87o80i3frf.fsf@occasionallycogent.com> <87ee1e374d.fsf@occasionallycogent.com> <861qxdf7pl.fsf@mail.linkov.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="12555"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 02 17:33:58 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 1nlY3h-00033c-Pq for ged-emacs-devel@m.gmane-mx.org; Mon, 02 May 2022 17:33:57 +0200 Original-Received: from localhost ([::1]:34430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlY3g-0005i6-9A for ged-emacs-devel@m.gmane-mx.org; Mon, 02 May 2022 11:33:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlY2n-0004VN-Pn for emacs-devel@gnu.org; Mon, 02 May 2022 11:33:01 -0400 Original-Received: from mail-qt1-f171.google.com ([209.85.160.171]:33688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlY2l-0001y3-3A for emacs-devel@gnu.org; Mon, 02 May 2022 11:33:01 -0400 Original-Received: by mail-qt1-f171.google.com with SMTP id hf18so11359014qtb.0 for ; Mon, 02 May 2022 08:32:50 -0700 (PDT) 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:in-reply-to:references:date :message-id:mime-version; bh=c4puTC5m5OBJNVyt9+kE18QNSaFXM7//N0Tl1Li/1/w=; b=myFcNGFwB4o3ScjL3oJFFlDCLhwmv0cAp578H+DvDAEpMuyo80y9y6dpZjGwmCRbNZ PZ/R0jB4pExGB2gzA/hzdNe3oUxO7UH+z5K4pR4SwTPop1fD0dGlBadt8BqFS/g8WTUk fSYEemVfNl9WOpNV0fM4mavCOTT5Y/1ALqTWK9Brd88B/us7jiXraTggV8tiaJy4DuHA 1Pv/aCK+my857mEJ/aewJgm2Vl8JDU7f2gujMtspcMcPpu6dFxlzebfuMVTh5oCTX+j2 OO9F3OJcjil9m/bwjufBeyhG2fE3+sVag1Rw612Lfh64vXOkDt859qV7yrWF3dOdcI5p M9jw== X-Gm-Message-State: AOAM5321SGGdGRMlEkr+V6nxE9UI9rqjLZfuspdcUTry7McfNpv1KxkD G0hMytEUP00oIrke8hzx3W+DkJh9bug= X-Google-Smtp-Source: ABdhPJwxBk7LSDO5DFsgo2iR4wzivh+Acii8X2DJ91C9feVqx3dC4Jr4wmo2+PMVi7VeW3s64eF0Tg== X-Received: by 2002:ac8:5ac5:0:b0:2f3:9348:ccc1 with SMTP id d5-20020ac85ac5000000b002f39348ccc1mr10690563qtd.26.1651505569437; Mon, 02 May 2022 08:32:49 -0700 (PDT) Original-Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com. [66.111.4.228]) by smtp.gmail.com with ESMTPSA id t24-20020ac865d8000000b002f39b99f6acsm4181586qto.70.2022.05.02.08.32.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 08:32:48 -0700 (PDT) Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 26B3327C0054; Mon, 2 May 2022 11:32:48 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 02 May 2022 11:32:48 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehgdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufgjfhffkfggtgesthdtredttddttdenucfhrhhomheplfgrmhgvshcu pfdrucggrdcuvegrshhhuceojhgrmhgvshdrnhhvtgesghhmrghilhdrtghomheqnecugg ftrfgrthhtvghrnhepudehtdeukeekiedvfeekudefkeeileejgeehfffhieevuefhkeeu ffefgfeileeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepjhgrmhgvshgptggrshhhodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithih qdduvdefvddtvdejledvqddvjeekgedtudehvddqjhgrmhgvshdrnhhvtgeppehgmhgrih hlrdgtohhmsehotggtrghsihhonhgrlhhlhigtohhgvghnthdrtghomh X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 May 2022 11:32:47 -0400 (EDT) In-Reply-To: <861qxdf7pl.fsf@mail.linkov.net> Received-SPF: pass client-ip=209.85.160.171; envelope-from=james.nvc@gmail.com; helo=mail-qt1-f171.google.com X-Spam_score_int: -9 X-Spam_score: -1.0 X-Spam_bar: - X-Spam_report: (-1.0 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:289087 Archived-At: Juri Linkov writes: >> Upon further inspection, I see that `minibuffer-completion-help` is setting >> `completion-list-insert-choice-function` to a function that checks if the `beg` >> and `end` arguments are strings, in which case it just replaces the >> minibuffer contents with "beg" + "choice" + "end". Indeed, when doing >> `completing-read` instead of `completing-read-multiple`, >> `completion--replace` doesn't get called at all in this case. > > completing-read-multiple already overrides choose-completion-string-functions > with own crm--choose-completion-string. So it would also make sense to > override completion-list-insert-choice-function as well. I think there are a few ways this could be done. The simplest would be to do the same thing that minibuffer.el does (if `start` and `end` are strings, insert `start`, `choice`, `end`; otherwise call `completion--replace` as usual). The other approach, which the below patch implements, is try to find the bounds based on the strings, but if the contents been edited, find the nearest CRM separator. This is kind of nice in that it lets you edit other selections but then still select a candidate, but I don't know how useful/expected that really is. The logic could also be made somewhat more complex (count the number of separators in `start` and `end`, try to guess how many we should skip over in each direction) but I don't know if that's really worthwhile. --- lisp/emacs-lisp/crm.el | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/lisp/emacs-lisp/crm.el b/lisp/emacs-lisp/crm.el index f3e1981732..8a5c3d3730 100644 --- a/lisp/emacs-lisp/crm.el +++ b/lisp/emacs-lisp/crm.el @@ -254,6 +254,23 @@ completing-read-multiple 'crm--choose-completion-string nil 'local) (setq-local minibuffer-completion-table #'crm--collection-fn) (setq-local minibuffer-completion-predicate predicate) + (setq-local completion-list-insert-choice-function + (lambda (start end choice) + (if (and (stringp start) (stringp end)) + (let* ((beg (save-excursion + (goto-char (minibuffer-prompt-end)) + (or (search-forward start nil t) + (search-forward-regexp crm-separator nil t) + (minibuffer-prompt-end)))) + (end (save-excursion + (goto-char (point-max)) + (or (search-backward end nil t) + (progn + (goto-char beg) + (search-forward-regexp crm-separator nil t)) + (point-max))))) + (completion--replace beg end choice)) + (completion--replace start end choice)))) ;; see completing_read in src/minibuf.c (setq-local minibuffer-completion-confirm (unless (eq require-match t) require-match)) -- 2.25.1