From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: master 49e06183f5 1/3: Allow REQUIRE-MATCH to be a function Date: Sat, 11 Jun 2022 12:57:00 +0200 Message-ID: <87pmjfsc1v.fsf@gnus.org> References: <165484935985.12525.14065631018362412932@vcs2.savannah.gnu.org> <20220610082240.A7222C01683@vcs2.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4255"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, Daniel Mendler To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 11 13:35:49 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 1nzzPA-0000ui-P5 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jun 2022 13:35:48 +0200 Original-Received: from localhost ([::1]:59406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzzP7-0004L8-Rf for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jun 2022 07:35:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzynk-000320-3y for emacs-devel@gnu.org; Sat, 11 Jun 2022 06:57:08 -0400 Original-Received: from quimby.gnus.org ([2a01:4f9:2b:f0f::2]:33332) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzyni-0001Ek-Gd for emacs-devel@gnu.org; Sat, 11 Jun 2022 06:57:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: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=sKVaNGVqo52weuwhTimuSU+IswqivaLGg2j+n7EoW/E=; b=fTN1TFtF87s9CjT/Y7a1+ZCSot zxNnC9yjnoxmjcP3HNMdP0fbpVJXrUfj6iSVT2sLn8YKQ2eRmA5mnL7JNRMY0sME4ztAjzdEvWDt/ oOvRZmMnHMDZ7VCbX40thYtk8bpe6Wx1GWMQH3UNu6W39EzbFCbpUvSGTt1i8l4ftS/w=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzynd-00084f-0T; Sat, 11 Jun 2022 12:57:03 +0200 X-Now-Playing: Mourning A BLKstar's _The Cycle_: "Hard (Stars Remix)" In-Reply-To: (Stefan Monnier's message of "Fri, 10 Jun 2022 10:15:50 -0400") Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:291027 Archived-At: Stefan Monnier writes: > But besides the `test-completion` part of the completion table, this new > feature also overlaps with the `predicate` argument. I think it would > be good to write down somewhere how those three compare. The PREDICATE argument is under-documented, yes -- it's just supposed to be a filter on COLLECTION, isn't it? > I see that the `minibuffer-completion-confirm` function completely > replaces the usual handling of require-match (i.e. the attempt to fix > the case and the prompting for confirmation). (You probably noticed it, but in case not -- I didn't change that code, I just changed the indentation.) > Maybe this should be better documented, and also AFAICT currently > a `minibuffer-completion-confirm` function cannot reliably reproduce this > behavior by hand because it doesn't have access to `beg` and `end`. > I think we should make this "default behavior" more easily accessible > (e.g. put it into its own function and document it as something that can > be called from `minibuffer-completion-confirm`?). I'm pretty sure I don't understand the subtleties here, but er sure? =F0= =9F=A7=90 --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no