From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#56613: 29; minibuffer-complete-history throws an error for minibuffer-history-variable=t Date: Mon, 18 Jul 2022 17:39:10 +0200 Message-ID: <5646a09b-6360-2290-d0c9-671c8216ad69@daniel-mendler.de> References: <86bktna9zo.fsf@mail.linkov.net> <86wncayjaw.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34389"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56613@debbugs.gnu.org To: Stefan Monnier , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 18 17:40:18 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 1oDSr3-0008m0-KD for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 17:40:18 +0200 Original-Received: from localhost ([::1]:49440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDSr2-00032Y-JH for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 11:40:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49226) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDSqp-0002zO-NY for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 11:40:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54113) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDSqp-0002oB-Du for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 11:40:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDSqo-0000eC-5I for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 11:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Jul 2022 15:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56613 X-GNU-PR-Package: emacs Original-Received: via spool by 56613-submit@debbugs.gnu.org id=B56613.16581587672440 (code B ref 56613); Mon, 18 Jul 2022 15:40:02 +0000 Original-Received: (at 56613) by debbugs.gnu.org; 18 Jul 2022 15:39:27 +0000 Original-Received: from localhost ([127.0.0.1]:51872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDSqF-0000dI-I7 for submit@debbugs.gnu.org; Mon, 18 Jul 2022 11:39:27 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:44715 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDSqA-0000cy-Bg for 56613@debbugs.gnu.org; Mon, 18 Jul 2022 11:39:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID: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=cOGHq38CiWn+IlNidbDpXLTBgt/dZY+LtFnmPjPteUs=; b=DtcCwKNE8zDwjS3R+h3qWA84oJ SmfeuqAsrB1gfIK3iuYv2+uU5G8rn1DQ593W0fpWLlustuWVWii/2ELqjCKYxyWO7U2336kPPqCrK oAuJnk74q+ur6GC4VW8pkXboH44uWfHXkxm2bIW4UCbecN/kjeznymlQLoKz5azJnZSY=; Content-Language: en-US In-Reply-To: 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" Xref: news.gmane.io gmane.emacs.bugs:237364 Archived-At: On 7/18/22 17:01, Stefan Monnier wrote: >> But I can't find a function that would return the >> current completion boundaries to use instead of hard-coding >> minibuffer--completion-prompt-end and point-max. Then >> completing-read-multiple should set locally such a function >> that will use crm-separator and return a cons (BEG . END). > > I can't remember what hacks are used in CRM, but we do have "a function > that would return the current completion boundaries to use": it's what > `completion-at-point-functions` is for. > > I think the long-term direction is clear: `completion-at-point` should > be used not just "in buffer" but in the minibuffer as well. > We could start that journey by making use of it for CRM. Not sure if I agree with this in full generality. The question is if you define completion only as completion of text or if you also accept the selection paradigm, where are a bunch of candidates are offered and filtered. The selection paradigm is used in most popular applications (web browser history, form filling). In Emacs we have Icomplete, Ivy, Vertico, etc. which implement that paradigm. For CRM I agree that completion-at-point makes sense, since there we are indeed doing step wise completion of multiple components. But I am not a fan of CRM and I don't like its API design. It is not widely used and the resulting UI is quite inconvenient. For example if you want to select among a bunch of very long candidates the CRM UI doesn't work at all. For this reason, org-cite and the Citar package instead call completing-read in a loop to select multiple candidates. I've also replaced most of my potential CRM use cases with completing-read in combination with Embark. Embark can be used to act on multiple candidates. Using single candidate completing-read as basis leads to a system which is more composable overall. Anyway because I am critical of CRM I would be cautious to use it as an example which guides a potential redesign of the completion mechanism. Daniel