From unknown Fri Jun 20 07:19:50 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#34116 <34116@debbugs.gnu.org> To: bug#34116 <34116@debbugs.gnu.org> Subject: Status: 27.0.50; minibuffer-force-complete-and-exit mostly broken Reply-To: bug#34116 <34116@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:19:50 +0000 retitle 34116 27.0.50; minibuffer-force-complete-and-exit mostly broken reassign 34116 emacs submitter 34116 Jo=C3=A3o T=C3=A1vora severity 34116 normal tag 34116 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 17 08:57:01 2019 Received: (at submit) by debbugs.gnu.org; 17 Jan 2019 13:57:01 +0000 Received: from localhost ([127.0.0.1]:34276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk8AH-0000bw-6K for submit@debbugs.gnu.org; Thu, 17 Jan 2019 08:57:01 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk8AF-0000bg-2d for submit@debbugs.gnu.org; Thu, 17 Jan 2019 08:56:59 -0500 Received: from lists.gnu.org ([209.51.188.17]:38309) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gk8A9-0006fy-NT for submit@debbugs.gnu.org; Thu, 17 Jan 2019 08:56:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk8A6-0004IP-0g for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2019 08:56:53 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gk8A4-0006aT-Mz for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2019 08:56:49 -0500 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:38269) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gk8A4-0006XV-8Z for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2019 08:56:48 -0500 Received: by mail-wr1-x435.google.com with SMTP id v13so11123624wrw.5 for ; Thu, 17 Jan 2019 05:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:user-agent:mime-version; bh=Z5SqcoFp1cipHTW/Vk9o1SfKLtxNd8qP/1NsI/I1mGw=; b=XzZGIxFbwJSsQDagLzgk7pLry3R4r+uqd2ZeixSrHkNWYm76z25HnUQxiQjN+lAbZU O/MQgfutnE9l4ENKxb9xDlRfWydJKyRFrIvAwY0/KLExKHpKkM9U+/jUt606LVbo+tv4 l8OGtrM2kGaCOOtLIgYNIYShvAaVHnMdzszQTICrb6s0WiMUM/lTZwghMU8df8vWeEZ/ 1AmH5wy0gg/Y+hP8pYp4iLuIC2yKPXhe7QxREBYGMrLaL+dJIAbNvVcW9jog5ibVWud0 k74UUXA/8GJeQD4RxsvuMh14el/vPzXDaa/cOkXFeUgdrOlFjxSukEVXg/HcU3cvH9nz oAsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :mime-version; bh=Z5SqcoFp1cipHTW/Vk9o1SfKLtxNd8qP/1NsI/I1mGw=; b=Kyy3C547nN3PnE0yZfOfgr8+rZ/sLOgL969qfv3egAuBlV35XpFnjkQ1eqFM9H0ZTc IR7u/lBCCZkHj4hc94QzX3SoleZApUEq/ldp0pGElZPxb7Z9XgpEFMlfsdeM3nyuL3sx qXdR5vsG+VaadmOBffOxJJeR8Zwn842iGKfp7rZKV9IzVqauWafT7XM9zBRbf9zp4x7l fUX9GTkRem78StQl7Euaho0k/+qg5TjVXjLaKrMI9jWx3pE45hydjs1yg56HVHdVMBbQ 8NGSPIQ9iZQAKeLLPRjFnW8GOdFrpM3VQ67yZUXCnzyNd3Ws1ePzaA6W2e8qtJIDdIO9 7E/Q== X-Gm-Message-State: AJcUukcxcGobmF0n2DZbxUWhOyV7GbZ5sv1Wmedcr4bIFl39Xchn5jbb 0Qv19VkVV4tOsxt61Umgy60= X-Google-Smtp-Source: ALg8bN6E2LNP/5u4gvni11Vw1XByLqT1NmBZ/MpaA4/NkwTexQvH7mdOG4ssfLTM/QfeIDjdX75O3w== X-Received: by 2002:adf:b102:: with SMTP id l2mr11782300wra.296.1547733405979; Thu, 17 Jan 2019 05:56:45 -0800 (PST) Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by smtp.gmail.com with ESMTPSA id u204sm65510033wmu.30.2019.01.17.05.56.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Jan 2019 05:56:45 -0800 (PST) From: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= To: bug-gnu-emacs@gnu.org Subject: 27.0.50; minibuffer-force-complete-and-exit mostly broken Date: Thu, 17 Jan 2019 13:56:39 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Antivirus: AVG (VPS 190117-0, 17-01-2019), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::435 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi maintainers, Here's a cute one from my recent icomplete adventures, Emacs -Q M-x icomplete-mode M-: (completing-read "test: " '("foo" "bar")) C-M-i ;; minibuffer-force-complete, this completes to "foo" C-j ;; icomplete-force-complete-and-exit Expected "foo", right? Nope: you get "bar". Incidently, this also happens without icomplete, provided you have bound the commands minibuffer-force-complete and minibuffer-force-complete-and-exit in minibuffer-local-completion-map. The problem happens because m-f-b cycles/rotates silently rotates the candidate list _after_ forcing the completion. The other second "and-exit" command, which also calls m-f-b during its execution, catches this extra rotation before returning the final value to the user. The attached patch fixes this. It add considerable hackery to an already nasty collection of hacks, but is the safest way short of redesigning this whole cycling business (which is heavily used in completion-at-point). This patch also simplifies the fix for bug#34077 which I had previously submitted. Jo=E3o --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Fix-nasty-cycling-on-minibuffer-force-complete-and-e.patch >From 97756513d4fe4521f3eff5376ad1ecfce5e1f266 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Wed, 16 Jan 2019 23:29:34 +0000 Subject: [PATCH] Fix nasty cycling on minibuffer-force-complete-and-exit minibuffer-force-complete sets up cycling after forcing the completion, which is mostly fine for successive interactive calls. However minibuffer-force-complete-and-exit also calls it. In situations where the former and latter are called in succession this causes an unwanted extra cycle, which ultimately yields the wrong completion. * lisp/minibuffer.el (minibuffer-force-complete): Take DONT-CYCLE arg. (minibuffer-force-complete-and-exit): Pass DONT-CYCLE to minibuffer-force-complete. --- lisp/minibuffer.el | 79 +++++++++++++++++++++++++++------------------- 1 file changed, 47 insertions(+), 32 deletions(-) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 5760a2e49d..74f85e7b90 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1257,29 +1257,32 @@ completion-all-sorted-completions (defun minibuffer-force-complete-and-exit () "Complete the minibuffer with first of the matches and exit." (interactive) - (minibuffer-force-complete) + (minibuffer-force-complete nil nil t) (completion--complete-and-exit (minibuffer-prompt-end) (point-max) #'exit-minibuffer ;; If the previous completion completed to an element which fails ;; test-completion, then we shouldn't exit, but that should be rare. (lambda () (minibuffer-message "Incomplete")))) -(defun minibuffer-force-complete (&optional start end) - "Complete the minibuffer to an exact match. -Repeated uses step through the possible completions." +(defun minibuffer-force-complete (&optional start end dont-cycle) + "Complete the minibuffer string between START and END to an exact match. +Repeated uses step through the possible completions, unless +prevented to do so by DONT-CYCLE." (interactive) (setq minibuffer-scroll-window nil) ;; FIXME: Need to deal with the extra-size issue here as well. ;; FIXME: ~/src/emacs/t/lisp/minibuffer.el completes to ;; ~/src/emacs/trunk/ and throws away lisp/minibuffer.el. + ;; FIXME: shouldn't we cycle _before_ instead of after forcing?? (let* ((start (copy-marker (or start (minibuffer-prompt-end)))) (end (or end (point-max))) ;; (md (completion--field-metadata start)) (all (completion-all-sorted-completions start end)) - (base (+ start (or (cdr (last all)) 0)))) + (base (+ start (or (cdr (last all)) 0))) + last second-last) (cond ((not (consp all)) - (completion--message + (completion--message (if all "No more completions" "No completions"))) ((not (consp (cdr all))) (let ((done (equal (car all) (buffer-substring-no-properties base end)))) @@ -1287,36 +1290,48 @@ minibuffer-force-complete (completion--done (buffer-substring-no-properties start (point)) 'finished (when done "Sole completion")))) (t + (setq second-last (last all 2) + last (cdr second-last)) + ;; If we happened to be already cycling, we must undo the + ;; effects of the last rotation (get out yer' pen and paper to + ;; get the cons cell math). + (when (and dont-cycle completion-cycling) + (let ((lastcdr (cddr second-last))) + (setcdr (cdr second-last) all) + (setq all (cdr second-last)) + (setcdr second-last lastcdr) + (setq last second-last))) (completion--replace base end (car all)) (setq end (+ base (length (car all)))) (completion--done (buffer-substring-no-properties start (point)) 'sole) - ;; Set cycling after modifying the buffer since the flush hook resets it. - (setq completion-cycling t) - (setq this-command 'completion-at-point) ;For completion-in-region. - ;; If completing file names, (car all) may be a directory, so we'd now - ;; have a new set of possible completions and might want to reset - ;; completion-all-sorted-completions to nil, but we prefer not to, - ;; so that repeated calls minibuffer-force-complete still cycle - ;; through the previous possible completions. - (let ((last (last all))) + (unless dont-cycle + ;; Set cycling after modifying the buffer since the flush hook resets it. + (setq completion-cycling t) + (setq this-command 'completion-at-point) ;For completion-in-region. + ;; Rotate the completions collected earlier and cache them. If + ;; completing file names, (car all) may be a directory, so we'd + ;; now have a new set of possible completions and might want to + ;; reset completion-all-sorted-completions to nil, but we prefer + ;; not to, so that repeated calls minibuffer-force-complete + ;; still cycle through the previous possible completions. (setcdr last (cons (car all) (cdr last))) - (completion--cache-all-sorted-completions start end (cdr all))) - ;; Make sure repeated uses cycle, even though completion--done might - ;; have added a space or something that moved us outside of the field. - ;; (bug#12221). - (let* ((table minibuffer-completion-table) - (pred minibuffer-completion-predicate) - (extra-prop completion-extra-properties) - (cmd - (lambda () "Cycle through the possible completions." - (interactive) - (let ((completion-extra-properties extra-prop)) - (completion-in-region start (point) table pred))))) - (set-transient-map - (let ((map (make-sparse-keymap))) - (define-key map [remap completion-at-point] cmd) - (define-key map (vector last-command-event) cmd) - map))))))) + (completion--cache-all-sorted-completions start end (cdr all)) + ;; Make sure repeated uses cycle, even though completion--done + ;; might have added a space or something that moved us outside + ;; of the field. (bug#12221). + (let* ((table minibuffer-completion-table) + (pred minibuffer-completion-predicate) + (extra-prop completion-extra-properties) + (cmd + (lambda () "Cycle through the possible completions." + (interactive) + (let ((completion-extra-properties extra-prop)) + (completion-in-region start (point) table pred))))) + (set-transient-map + (let ((map (make-sparse-keymap))) + (define-key map [remap completion-at-point] cmd) + (define-key map (vector last-command-event) cmd) + map)))))))) (defvar minibuffer-confirm-exit-commands '(completion-at-point minibuffer-complete -- 2.19.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 17 08:59:11 2019 Received: (at control) by debbugs.gnu.org; 17 Jan 2019 13:59:11 +0000 Received: from localhost ([127.0.0.1]:34281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk8CM-0000g6-S5 for submit@debbugs.gnu.org; Thu, 17 Jan 2019 08:59:11 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:43852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk8CK-0000fg-Hg for control@debbugs.gnu.org; Thu, 17 Jan 2019 08:59:09 -0500 Received: by mail-wr1-f45.google.com with SMTP id r10so11082560wrs.10 for ; Thu, 17 Jan 2019 05:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:from:subject:mime-version :content-transfer-encoding; bh=U39uwm0/jJMgWZKLLreJlplqBTyQeT83L02EjKpoPsg=; b=kEQs0Mamely9Cw1ErzmQFXbTX0MKHdNkh/iL9Y/c+6ZAubPcMXDIld8BtgyCWWWyo7 D5HvoA2M9Z2zbzM+zgV1sRzFp5Ll5psFabKD/7Ew2EFZyXqwdBCcka4MX14dTFl+LSgK 4GjrAbH6weQ82WkW1QSO2J1KqJUJUZ6NeZBDJUla+kOYuvhGthHwOv6qVkLwYV+Sf1TV kBPQ5yxQIEi4fvdFwgqGmmz26yyYBMuHyWGhjq0l1Dkp2XeRXyd+ZY3lXYKRNHu5Z7Ho 1aZlbU/lWKW4Rx1+OkppNFBX4T+wyyBsJEgHjZqbIep5V9VL5FmPbdsSYdBKdHHc7W+g o/xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:from:subject:mime-version :content-transfer-encoding; bh=U39uwm0/jJMgWZKLLreJlplqBTyQeT83L02EjKpoPsg=; b=KAdFFIdX+A2KhZMiWBcbTBvXyAmX6URwz8hqXxliDk8ZJntmGJ4n2+6Hc2266P4iV5 JmxewQx6Ily4yngR32H2vDbKaVeFv81YgG05VFEwddpuPP/xWstqCYZAw+Hu8Sj4PiS4 s5AV4rWE3snTmV64WP7DutsMuH0X3qNlQs6JPs9WUpkJsGY+1VTatHqca9fgZXwjU6H2 J3k5jfdduChpEalYA2zcf8GRCgS+dEYTdKYmJloYMUqgMq58TsIhNaiS3LxiRDY5aKto LFBG1ZVrBP53XXDXTaeXjyJvdzQKMO43jo/IHB4yc86OvqPbnYUoY2Ywb8DV3AvY6sYg A9Cw== X-Gm-Message-State: AJcUukdCw7PzNGpVPHlvFbny7Cm67tcZIoh17xfP8xvuLJp15uVrPfLt 0lNjcaXUxH3N1ppSYT0OBGQ5/fzQ X-Google-Smtp-Source: ALg8bN7uZ0YGxXCArs13vpS9qOJTi6wcRInRVh8JmMkRd8nyGpJ8IQejyqpdhg08cJqbyzQL3WRZVA== X-Received: by 2002:adf:fb4c:: with SMTP id c12mr578239wrs.297.1547733542362; Thu, 17 Jan 2019 05:59:02 -0800 (PST) Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by smtp.gmail.com with ESMTPSA id w18sm25435438wmi.12.2019.01.17.05.59.01 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Jan 2019 05:59:01 -0800 (PST) Date: Thu, 17 Jan 2019 13:59:01 +0000 Message-Id: To: control@debbugs.gnu.org From: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Subject: control message for bug #34116 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Antivirus: AVG (VPS 190117-0, 17-01-2019), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 34116 patch From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 17 09:57:15 2019 Received: (at 34116) by debbugs.gnu.org; 17 Jan 2019 14:57:16 +0000 Received: from localhost ([127.0.0.1]:35181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk96Z-0004yc-It for submit@debbugs.gnu.org; Thu, 17 Jan 2019 09:57:15 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:57260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk96V-0004yQ-I5 for 34116@debbugs.gnu.org; Thu, 17 Jan 2019 09:57:13 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x0HEvAqO032435; Thu, 17 Jan 2019 09:57:10 -0500 Received: by pastel.home (Postfix, from userid 20848) id 31BF86A58C; Thu, 17 Jan 2019 09:57:10 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: 27.0.50; minibuffer-force-complete-and-exit mostly broken Message-ID: References: Date: Thu, 17 Jan 2019 09:57:10 -0500 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1v?= =?windows-1252?Q?ora=22's?= message of "Thu, 17 Jan 2019 13:56:39 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6463=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6463> : inlines <6996> : streams <1810351> : uri <2781364> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > @@ -1257,29 +1257,32 @@ completion-all-sorted-completions > (defun minibuffer-force-complete-and-exit () > "Complete the minibuffer with first of the matches and exit." > (interactive) > - (minibuffer-force-complete) > + (minibuffer-force-complete nil nil t) > (completion--complete-and-exit > (minibuffer-prompt-end) (point-max) #'exit-minibuffer > ;; If the previous completion completed to an element which fails > ;; test-completion, then we shouldn't exit, but that should be rare. > (lambda () (minibuffer-message "Incomplete")))) Wouldn't it be simpler to change minibuffer-force-complete-and-exit so it checks test-completion before calling minibuffer-force-complete? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 17 10:04:02 2019 Received: (at 34116) by debbugs.gnu.org; 17 Jan 2019 15:04:02 +0000 Received: from localhost ([127.0.0.1]:35199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk9D8-0005Ae-BF for submit@debbugs.gnu.org; Thu, 17 Jan 2019 10:04:02 -0500 Received: from mail-qk1-f179.google.com ([209.85.222.179]:44717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gk9D6-0005A8-OL for 34116@debbugs.gnu.org; Thu, 17 Jan 2019 10:04:01 -0500 Received: by mail-qk1-f179.google.com with SMTP id o8so6126172qkk.11 for <34116@debbugs.gnu.org>; Thu, 17 Jan 2019 07:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2NSZFk7nVwHgJvPs9VEI/a8Farj25PBETzNgWFezbc0=; b=f9QM5ybx7m1vPGjsEIARCIVfj1B+f+5OqmoqrUF5UyTSV6CxTM7MLxo0L+mHrjCAmv WokQMh+DlCRDLM2bSU7cMS8OREVLaIz+GtfG9qYiRWAMISL9X8yy/dFZfYD825qPpQj+ pnkzFmbP2GH23yEnKoUOFSDF5TV671gXXvd52qwlbUHDMgmLBgs/fcK9nZkbo35QeD8d vkFI0RN3TNE1hd7t/d0coSDVT/3+TSUsqxe5N8+b8ROtTp3L073f6jLfX119UYhdHfuL SbeSVE478wXFDmVF3V7EDGIu5v5TAZ6VgWqgFm8TVcWCCqsYEMTjLLDRKTIhH8P30tjY x+TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2NSZFk7nVwHgJvPs9VEI/a8Farj25PBETzNgWFezbc0=; b=JiwfBdz9mgS7pcv2lrozj2uGLLMOZH9iv7/PT8JwwabPKu9K6IhXeypXKSQDDNSYwB qrHb/XmUMxdYOZBJEubSJ/gN47SLWQXmw0BjyU8X+XVBPzMc5c9EtukeHZMXr8vz1Re4 y4WweV0RftM9vf28T8gKF2wnLUvi4ePIFq4g+GfGFSVgaoTOAYy4dhOttdYwKu9ranP8 vXQmowfsbGXFsThBKb1dpEftJUfskfk63svUa2PbPI8R8mA3V7QRW5HS7U4AFQiq2nbV U0Z5bYg+NUOtmRXprzAsFxfekAcKU4xeV3V5GcEv/nH/dtahNjiTavznUmqWedipS0E1 Vf+w== X-Gm-Message-State: AJcUukduwtjGZoGhYSgSPwNV0pKegvUPdB7lyjbikFhWw4XN6u/WLJB3 60aCDqh9n3m+BYb0h0APrcB5cJBhcqUBESUOCSw= X-Google-Smtp-Source: ALg8bN7BlhleeCrTWTeSl8bl3nE1P0FfoYey0/gKHMG0hx72NW9ojaAVeNeP8vTjtuvvPNpGdWsesl9y7sTqJFVcq0U= X-Received: by 2002:a37:f706:: with SMTP id q6mr10830433qkj.96.1547737434960; Thu, 17 Jan 2019 07:03:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 17 Jan 2019 15:03:43 +0000 Message-ID: Subject: Re: 27.0.50; minibuffer-force-complete-and-exit mostly broken To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) On Thu, Jan 17, 2019 at 2:57 PM Stefan Monnier w= rote: > > > @@ -1257,29 +1257,32 @@ completion-all-sorted-completions > > (defun minibuffer-force-complete-and-exit () > > "Complete the minibuffer with first of the matches and exit." > > (interactive) > > - (minibuffer-force-complete) > > + (minibuffer-force-complete nil nil t) > > (completion--complete-and-exit > > (minibuffer-prompt-end) (point-max) #'exit-minibuffer > > ;; If the previous completion completed to an element which fails > > ;; test-completion, then we shouldn't exit, but that should be rare= . > > (lambda () (minibuffer-message "Incomplete")))) > > Wouldn't it be simpler to change minibuffer-force-complete-and-exit so > it checks test-completion before calling minibuffer-force-complete? Makes sense. As I explained elsewhere, I am a total completion API newbie. I'm always unsure what to pass to these functions and the dark logic they engage in. On the contrary, my change is based on cons cells, which I still understand :-) But your suggestion makes perfect sense and I'd be very thankful if you could do it yourself (if it is as trivial as it sounds). Jo=C3=A3o T=C3=A1vora From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 18 07:13:25 2019 Received: (at 34116) by debbugs.gnu.org; 18 Jan 2019 12:13:25 +0000 Received: from localhost ([127.0.0.1]:35774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkT1Z-0000h8-4n for submit@debbugs.gnu.org; Fri, 18 Jan 2019 07:13:25 -0500 Received: from mail-qt1-f181.google.com ([209.85.160.181]:37028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkT1X-0000gu-2o for 34116@debbugs.gnu.org; Fri, 18 Jan 2019 07:13:24 -0500 Received: by mail-qt1-f181.google.com with SMTP id t33so14879850qtt.4 for <34116@debbugs.gnu.org>; Fri, 18 Jan 2019 04:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jD1LM4HqutKHGMY0x3hDBWOPvmm2vZpJl17NytMIzFY=; b=Oq8TfJvJx4HOfRRGfFb8jvDv+11Nw3kSGY8LICMv9HIymLbloCON4uYbfIT0dlIi9I JZatrv73BV8OHUi1+4+O7hNSLHJ7VUdLXMYiHeCFAxfikjmyTeF2XgcDagQEr+fneYyR FcavfOTf/WaZVUstP1lneuAkpMVwJJa+DpW8CWDce5AnPsVoAKANdrvjEPSLJrUZDPYl n8M+RKkuo/jxF9AbDK+wpDlmW6qN7FhhY9xENArQoc3PSEvVdgwB4TvpE2BKZ1c15hgQ Za7c7+FufImnShjSQcB+SKzoVM+3ibYndXU5ltgm+Lz/nASaSzaEY18Z1b9F/i7o8DZj O5eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jD1LM4HqutKHGMY0x3hDBWOPvmm2vZpJl17NytMIzFY=; b=Ssn2V4DBewCck/eUhgar7dpN6gsvk4HoPS9rXLgFEpEq/CiIApt3lqOjMv6zXsH/7y 4Z4+7ERADgNbFuo6rDZ09W7IxuO6ClFDZ8iedRRbnGAP6btPck/kryz9bTntOF8+bzJC niySexEqVB+wwnU8ijpHjevdv9bwd+UK64xHWEv0//IeVzAybKYzj3KQ6CW/luVRneO0 XpRPoLdxCiA6NTwCeeU7HfUEOTwmwPU37sns8ZIhSXORhzPxeX1WZTLoWSR4FaxqTi+K KzxRN+FBUfUuhUXpdY9l6dB4E3y1i39aRHZb5qDnwdJMhbehXXMF4WfrgFb2EPndj60V FhTg== X-Gm-Message-State: AJcUukfT/4a1z+nsXqf/7lV1S9KOiizzOznarrnuNr5klUezbrNdmrSj F6tjOYII+NW1faivfhKnm5RNpSRVlHGgLxTkNx8= X-Google-Smtp-Source: ALg8bN5x2ZWbLUQqrwPL9LFsM3BCPpczNAS3zOmLmSF69HL/35TV4rVVf5idb79icgA+wYP7f2Xh0JCdAdu+mY/25Xk= X-Received: by 2002:ac8:3790:: with SMTP id d16mr15657584qtc.20.1547813597458; Fri, 18 Jan 2019 04:13:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 18 Jan 2019 12:13:06 +0000 Message-ID: Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) I'm going to change my stance on this, but just a little. I trid your approach, passing minibuffer-completion-table and minibuffer-completion-predicate and some "reasonable" string to try-completion. It seems to work most of the times, but I could swear it is is doing mischief in some situations (can't tell which tho). Other arguments against it is that it shouldn't be necessary to query the table again by this point, which is potentially slow and could have side effects depending on the table. In other words, there is some arguably poorly chosen cons juggling going on in minibuffer-force-complete. My fix adds to that, but at least it stays within the same idiom. So if you don't mind I'd fix this rather serious bug with my safer fix, and later we can use your try-completion approach. Jo=C3=A3o On Thu, Jan 17, 2019 at 3:11 PM Jo=C3=A3o T=C3=A1vora wrote: > > On Thu, Jan 17, 2019 at 2:57 PM Stefan Monnier = wrote: > > > > > @@ -1257,29 +1257,32 @@ completion-all-sorted-completions > > > (defun minibuffer-force-complete-and-exit () > > > "Complete the minibuffer with first of the matches and exit." > > > (interactive) > > > - (minibuffer-force-complete) > > > + (minibuffer-force-complete nil nil t) > > > (completion--complete-and-exit > > > (minibuffer-prompt-end) (point-max) #'exit-minibuffer > > > ;; If the previous completion completed to an element which fails > > > ;; test-completion, then we shouldn't exit, but that should be ra= re. > > > (lambda () (minibuffer-message "Incomplete")))) > > > > Wouldn't it be simpler to change minibuffer-force-complete-and-exit so > > it checks test-completion before calling minibuffer-force-complete? > > Makes sense. As I explained elsewhere, I am a total completion API > newbie. I'm always unsure what to pass to these functions and the > dark logic they engage in. On the contrary, my change is based on > cons cells, which I still understand :-) > > But your suggestion makes perfect sense and I'd be very > thankful if you could do it yourself (if it is as trivial as it sounds). > > Jo=C3=A3o T=C3=A1vora > > > -- Jo=C3=A3o T=C3=A1vora From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 18 08:09:19 2019 Received: (at 34116) by debbugs.gnu.org; 18 Jan 2019 13:09:19 +0000 Received: from localhost ([127.0.0.1]:35798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkTtf-0003z6-Eg for submit@debbugs.gnu.org; Fri, 18 Jan 2019 08:09:19 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:60438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkTtc-0003yx-Py for 34116@debbugs.gnu.org; Fri, 18 Jan 2019 08:09:18 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x0ID9Fum032171; Fri, 18 Jan 2019 08:09:15 -0500 Received: by pastel.home (Postfix, from userid 20848) id 146636AB93; Fri, 18 Jan 2019 08:09:15 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken Message-ID: References: Date: Fri, 18 Jan 2019 08:09:15 -0500 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 18 Jan 2019 12:13:06 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6464=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6464> : inlines <6997> : streams <1810439> : uri <2781846> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > It seems to work most of the times, but I could swear it is > is doing mischief in some situations (can't tell which tho). I can believe it. > Other arguments against it is that it shouldn't be necessary > to query the table again by this point, which is potentially > slow and could have side effects depending on the table. test-completion should be pretty fast (and it's called by the subsequent completion--complete-and-exit so no matter how slow, adding a call cannot slowdown the command by more than a factor 2x). > In other words, there is some arguably poorly chosen cons > juggling going on in minibuffer-force-complete. My fix adds > to that, but at least it stays within the same idiom. I must admit that I find your fix a bit ugly (adding an ad-hoc extra arg, then undoing cycling depending on (and dont-cycle completion-cycling), ...). Taking another look at the problem, I believe the change below is the better option. Any objection? Stefan diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index db8d4ba5ce..879ad9a8f7 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1378,7 +1381,8 @@ completion-all-sorted-completions (defun minibuffer-force-complete-and-exit () "Complete the minibuffer with first of the matches and exit." (interactive) - (minibuffer-force-complete) + (unless completion-cycling + (minibuffer-force-complete)) (completion--complete-and-exit (minibuffer-prompt-end) (point-max) #'exit-minibuffer ;; If the previous completion completed to an element which fails From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 18 08:28:59 2019 Received: (at 34116) by debbugs.gnu.org; 18 Jan 2019 13:28:59 +0000 Received: from localhost ([127.0.0.1]:35813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkUCg-0004S2-RC for submit@debbugs.gnu.org; Fri, 18 Jan 2019 08:28:59 -0500 Received: from mail-qk1-f179.google.com ([209.85.222.179]:38392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkUCe-0004Rp-BS for 34116@debbugs.gnu.org; Fri, 18 Jan 2019 08:28:57 -0500 Received: by mail-qk1-f179.google.com with SMTP id m17so557790qki.5 for <34116@debbugs.gnu.org>; Fri, 18 Jan 2019 05:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ecxxn8oPXH0VJDJJXUjl0Gf3tyIExsr98oS7uO3oEuE=; b=KMQVN9EswS9UF8ICpXl735vYJTJwouJkd5JTvJuKDPivS/qDjvWiZ7GQqoKIaoCRw8 O234W6XzpqzOHztTvAugm9ulEvGvd7mEpqUNTse0uBWeKRl3rYgZms/jYSLzQQfDbEOr OFh62iGs/KUb+6/DGseutyMtJjelfFp4nzknHhDXzoipg+3yLMkZmdiK/plWHwJbP+LL lzAQT2YwmL/Tx2BC5dVB76u/7Hkw3yVotkB/AFGT/IYlu0SRQkn2VInN86dPXHDUmkRQ 8Xb1ei8Jgh2AG7TtM8aJvKDqr+PL4eYT5sVXwaQ1W9UNh4JySkqYLZRt4ai3vQ8/WLBp RxNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ecxxn8oPXH0VJDJJXUjl0Gf3tyIExsr98oS7uO3oEuE=; b=kFH6T88ycjz0hg0XKdSJ5xmIC7KDBm8fZnprv+CrcYwR2mJL7wHbdPWftugDj0MB9b EDVsZl6PhzB78yn43SxWUa2vFzDcSysCACj5K1IaBfPx2m1265jWVLeWsNJm+3DaC8kn bkSjnnopHj0zusUggVypvv8GKvRfVlbPu9YI1yDQYbKdH9VLN5uVtJQTi1ey9KvtlNMc 6xd1/+ZUwSRwXAuZUoqiskMXae/gtcXwWWActmPMxtqQsgMScG38q41wzZK+75lLgNfX YAh2V/6ynV+5sRAZoYYoalJihRAGvSPPdSVVcNzONBE/O6oHJy7vrQSdnCFgavZAadOc Ha6Q== X-Gm-Message-State: AJcUukfzz5uTw696cGESM3ZRF9aRENgD0ZLJkUXEPaOq0EjuKQeHOrm2 xyCZ2/m/c2vVwBRYKY88xE1jBWroXbW/4g//F6w= X-Google-Smtp-Source: ALg8bN4TvJdT5Js0VER0xqsWEkasgx2/H5rTXzHrRq6do+k5RueyFXG33PVdWE/DuvyQ0SHkBOhvd2sO7+dhamRrwZA= X-Received: by 2002:ae9:ef14:: with SMTP id d20mr15053348qkg.147.1547818130737; Fri, 18 Jan 2019 05:28:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 18 Jan 2019 13:28:39 +0000 Message-ID: Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) On Fri, Jan 18, 2019 at 1:09 PM Stefan Monnier w= rote: > > It seems to work most of the times, but I could swear it is > > is doing mischief in some situations (can't tell which tho). > > I can believe it. I'll try to pin it down later. > test-completion should be pretty fast (and it's called by the subsequent > completion--complete-and-exit so no matter how slow, adding a call > cannot slowdown the command by more than a factor 2x) OK, though not particularly reassuring :-) > > In other words, there is some arguably poorly chosen cons > > juggling going on in minibuffer-force-complete. My fix adds > > to that, but at least it stays within the same idiom. > > I must admit that I find your fix a bit ugly (adding an ad-hoc extra > arg, then undoing cycling depending on (and dont-cycle > completion-cycling), ...). Oh yes, no problem admitting that. It's hideous! But small enough to yield to local analysis and be easy to analyse to be safe. > Taking another look at the problem, I believe the change below is the > better option. Any objection? Yes, it elegantly fixes this bug, but complicates #34077. OTOH #34077 could be solved by your try-completion thing. But as I said I think that is unstable (or at least has much more potential to be unstablel). commit 74ff04e5cd271a238cb9bd966cdbcf9804d49386 Author: Jo=C3=A3o T=C3=A1vora Date: Tue Jan 15 16:50:40 2019 +0000 Avoid broken C-M-i cycling in icomplete-mode (bug#34077) If there is only one propective candidate and it happens to be a directory then (1) C-M-i causes the prospects to be updated to the subfil= es of the completed directory, otherwise (2) the prospects are merely rotated. It is very hard to tell if (1) or (2) happened because the rotated prospects may look identical to the updated prospects. Therefore, in icomplete-mode, it is preferable to do (1) always, to avoid iconsistencies with the presentation of prospects in this mode. There are already facilities in place to rotate the prospects list. * lisp/icomplete.el (icomplete-minibuffer-map): Bind C-M-i to icomplete-force-complete. (icomplete-force-complete): New command. The current fix I have for it is (defvar icomplete-minibuffer-map (let ((map (make-sparse-keymap))) - (define-key map [?\M-\t] 'minibuffer-force-complete) + (define-key map [?\M-\t] 'icomplete-force-complete) (define-key map [?\C-j] 'icomplete-force-complete-and-exit) (define-key map [?\C-.] 'icomplete-forward-completions) (define-key map [?\C-,] 'icomplete-backward-completions) map) "Keymap used by `icomplete-mode' in the minibuffer.") +(defun icomplete-force-complete () + "Complete the minibuffer. +Like `minibuffer-force-complete', but don't cycle." + (interactive) + ;; FIXME: it _could_ make sense to cycle in certain situations, by + ;; analyzing the current thing and the thing to cycle to for + ;; instance. Unfortunately that can't be done until a _very nasty + ;; hack_ in `minibuffer-force-complete' is removed. That hack uses + ;; transient maps and prevents two consecutive calls to + ;; `icomplete-force-complete'. + (minibuffer-force-complete nil nil t)) Jo=C3=A3o T=C3=A1vora From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 18 13:00:40 2019 Received: (at 34116) by debbugs.gnu.org; 18 Jan 2019 18:00:40 +0000 Received: from localhost ([127.0.0.1]:37024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkYRc-00031V-4Y for submit@debbugs.gnu.org; Fri, 18 Jan 2019 13:00:40 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:34948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkYRY-00031M-S0 for 34116@debbugs.gnu.org; Fri, 18 Jan 2019 13:00:39 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x0II0ZV0011363; Fri, 18 Jan 2019 13:00:35 -0500 Received: by pastel.home (Postfix, from userid 20848) id 4BDD26AB9E; Fri, 18 Jan 2019 13:00:35 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken Message-ID: References: Date: Fri, 18 Jan 2019 13:00:35 -0500 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 18 Jan 2019 13:28:39 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Rules: 3 Rules triggered GEN_SPAM_FEATRE=0.1, EDT_SA_DN_PASS=0, RV6464=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6464> : inlines <6997> : streams <1810458> : uri <2781967> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Yes, it elegantly fixes this bug, but complicates #34077. I don't see why. Can you explain? Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 18 17:18:33 2019 Received: (at 34116) by debbugs.gnu.org; 18 Jan 2019 22:18:33 +0000 Received: from localhost ([127.0.0.1]:37117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkcTB-0004ei-2p for submit@debbugs.gnu.org; Fri, 18 Jan 2019 17:18:33 -0500 Received: from mail-wr1-f52.google.com ([209.85.221.52]:42102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkcT9-0004eV-Kl for 34116@debbugs.gnu.org; Fri, 18 Jan 2019 17:18:32 -0500 Received: by mail-wr1-f52.google.com with SMTP id q18so16856144wrx.9 for <34116@debbugs.gnu.org>; Fri, 18 Jan 2019 14:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=t2aTENCkt9tdkT0cXfIH5/z0i84neGdAqjfv0FekYXY=; b=Ppd4t8TXZUZm+rZLw9HkIOmxSFQpBUmv427X5FIScw+K9pmnqDym1LN3vaVZRq00VG i8g+Vd8lqPcays2h/wa9ruWPrNgUqu1cujSbj3ysSYsYkJufDruHRKmXqy3nNb2HiKkB H9/9yaRKgAEeagFdAHunYbHwFa4XQn6Fd4FNxZAA6FrsKTjK6gsU5NLwpHQHoLmgS7hR m9H1iQnCOOF9RTqq7DB5mZI3QufUHZekOsa9ApnLe+p8y8+9+fbLqRKFmvq5CGVm80Vf xPf2apxW7Y5UgMmOoG22X64+fivA3y5mx7yfgyD0MNXseZQuB+k78gPdfL/JIuHS12Gx HybQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=t2aTENCkt9tdkT0cXfIH5/z0i84neGdAqjfv0FekYXY=; b=E2EpXH5rKq5y2QymR/fwZXxyUwn7WJ9TCEIxUUdPosIRAe1urg+/h3kfc51yBGTR9x PyVAr57BBG3nvrGXCSOMEJtJTuNtob9bbVO5Q+nVSdQJTwjPVkoZT/0WvOe0lmPM1Q5k QBDc6tAOX0JbOz71Z/b5K6jJgH246FSzVIzNT4hwzWfGFpu6ybcdC/nIByBxhCELX7it Z9nfdE4DvFAtoAurjTccUu/TH8NBI4TkrD3IOlpgjGCNY/yITndRlP4RynuHtmJp3+C0 772IfvFj/dK2Qje2tl9syGzWLfESWKa8GklA5mSRk1UBzIL42+75Q5ZoDsDwpxMe5xiY JMpw== X-Gm-Message-State: AJcUuke3ZWLQfxXs0QcR5oxwqAp8/Y0Hxheb6mUQgyl+2ZcQm1E2Dofb yht1+fQFX6qoI/ZHig2iKIw6kyhy X-Google-Smtp-Source: ALg8bN54SfB0ZhrZJ6T1QaYQu/F09qhHwaY4d8kIZLd+xfjqgnxS1NMLw/heRbwAOiTDsiu2uuAd0g== X-Received: by 2002:adf:b201:: with SMTP id u1mr18056917wra.165.1547849905538; Fri, 18 Jan 2019 14:18:25 -0800 (PST) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id x10sm107359255wrn.29.2019.01.18.14.18.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Jan 2019 14:18:24 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Stefan Monnier Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken References: Date: Fri, 18 Jan 2019 22:18:22 +0000 In-Reply-To: (Stefan Monnier's message of "Fri, 18 Jan 2019 13:00:35 -0500") Message-ID: <87tvi5pq35.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) Stefan Monnier writes: >> Yes, it elegantly fixes this bug, but complicates #34077. > > I don't see why. Can you explain? If I do that, then C-M-i will still cycle/rotate after completing say, '/emacs/sr' to '/emacs/src', which means that completion-all-sorted-completions, used by the prospects, listing is still forcibly cached by minibuffer-force-complete. The reason it shouldn't be, IMO, is that the result is I will now see '{src | libsrc}' as candidates, instead of seeing the files under emacs/src/. The problem is really that now I can't know if those are actual dirs emacs/src/src emacs/src/libsrc. You could argue that's just my personal preference and the cycling still makes sense, so I put this new behaviour is a separate command icomplete-force-complete as a compromise. But with your technique I can't implement it properly. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 18 21:32:00 2019 Received: (at 34116) by debbugs.gnu.org; 19 Jan 2019 02:32:00 +0000 Received: from localhost ([127.0.0.1]:37191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkgQS-00026O-2Z for submit@debbugs.gnu.org; Fri, 18 Jan 2019 21:32:00 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:58442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkgQP-00026F-2h for 34116@debbugs.gnu.org; Fri, 18 Jan 2019 21:31:58 -0500 Received: from milanesa.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x0J2VtTZ024447; Fri, 18 Jan 2019 21:31:56 -0500 Received: by milanesa.home (Postfix, from userid 20848) id 74F1366140; Fri, 18 Jan 2019 21:31:55 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken Message-ID: References: <87tvi5pq35.fsf@gmail.com> Date: Fri, 18 Jan 2019 21:31:55 -0500 In-Reply-To: <87tvi5pq35.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Fri, 18 Jan 2019 22:18:22 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6464=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6464> : inlines <6998> : streams <1810492> : uri <2782150> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> Yes, it elegantly fixes this bug, but complicates #34077. >> I don't see why. Can you explain? > If I do that, then C-M-i will still cycle/rotate after completing say, > '/emacs/sr' to '/emacs/src', which means that > completion-all-sorted-completions, used by the prospects, listing is > still forcibly cached by minibuffer-force-complete. Right, but the patch doesn't affect minibuffer-force-complete at all, so it doesn't make the problem any harder, does it? Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 23 10:49:21 2019 Received: (at 34116) by debbugs.gnu.org; 23 Jan 2019 15:49:21 +0000 Received: from localhost ([127.0.0.1]:42946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmKmG-0003ee-UP for submit@debbugs.gnu.org; Wed, 23 Jan 2019 10:49:21 -0500 Received: from mail-qt1-f178.google.com ([209.85.160.178]:41013) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmKmE-0003eP-B2 for 34116@debbugs.gnu.org; Wed, 23 Jan 2019 10:49:18 -0500 Received: by mail-qt1-f178.google.com with SMTP id l12so2836232qtf.8 for <34116@debbugs.gnu.org>; Wed, 23 Jan 2019 07:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ualhSSxWkg/TQ+N2gUY/1E0UK1DBHKDQPis1WVMfEHU=; b=hVHarVPaXoNar5YHNNqwrMPLGnVRmPve7JtI6z+cLvD2QW+gkgYdpSe4g8al1s0ucm 1JSjOAeiN0xiDeRU76d5wFDDJXRpiIOfjCoJAHeDN4++CCNg1Ub05A9hofdyyE5+AcSk ve5QaPf36xUrlVEX3Lo2Lydd0Y0qiz+l278TQ9kltkb49dqMXuuXiHoIxdOT8WWAl/nS /7K0SXc/Lligbr2vqw+SNLg2ZZbzQYGla7QT8op33YoLj4YA2oDtv3a6jHOrHHscr/eT VqGCdJtEFpxFwuneJKXDrRT8/OdjhJaAVuX7Ug4ggmnD0K31tPKzQyCkcNIOfMakWMy+ sCtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ualhSSxWkg/TQ+N2gUY/1E0UK1DBHKDQPis1WVMfEHU=; b=iM8ggarM89NC0W0UwnfySSbyujLurLFXU2s/NCFRhvAXpXJkPoMMxPfuFNEYqkQmMZ VMBDfBsTNHqKBug7uRXMBqCShZLmE2m1ExMiEiLizyHY3yPTvIYpALd9rVKECN4FIsus s9nHKM6N1vRqdeSdzLr8FSFxaRvkT3xE1TS9W6/PJxGjVbKafoIcbm8/TxGLv/fGbmK6 P8ntO4/1kiIxdtsKkrOarxtmpI9bARfIEI2mh9DAbYkp2iXLQXBqV1s8iK52hU9T6irm JJEatOCg5ypEMad8cgJvBhb3tYv7TWmDwFnctyDfdJr0gJRqqcNeC0SZ0kyMiAmglG1m g/UQ== X-Gm-Message-State: AJcUukfmJU1xnEzTNJVGqzjw6Qs0lcoAD5MKqm6toCFmOS/vrs7KVPiY Y7QBO4Boo3cJd6HB7We/eCR25lrWQQiQtfs59/g= X-Google-Smtp-Source: ALg8bN5XOQ4PgP7IVSbMTLsuw8DLnwrnjP2Pu7fNIUqxYk9o/9XSG/Yw285bAVqOaRRgMwh7isCYLTza2y62I4ZKb1U= X-Received: by 2002:ac8:2dc3:: with SMTP id q3mr2868753qta.178.1548258552481; Wed, 23 Jan 2019 07:49:12 -0800 (PST) MIME-Version: 1.0 References: <87tvi5pq35.fsf@gmail.com> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 23 Jan 2019 15:49:00 +0000 Message-ID: Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) On Sat, Jan 19, 2019 at 2:31 AM Stefan Monnier wrote: > > >>> Yes, it elegantly fixes this bug, but complicates #34077. > >> I don't see why. Can you explain? > > If I do that, then C-M-i will still cycle/rotate after completing say, > > '/emacs/sr' to '/emacs/src', which means that > > completion-all-sorted-completions, used by the prospects, listing is > > still forcibly cached by minibuffer-force-complete. > > Right, but the patch doesn't affect minibuffer-force-complete at all, so > it doesn't make the problem any harder, does it? No but to solve the other problem, I still need the DONT-CYCLE hack. What I should have said is "this doesn't solve my other problem". Indeed it doesn't make it any harder. But what about this which solves both problems bug#34077 and bug#34116? diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 6d77c0649a..562da1a71d 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -145,7 +145,7 @@ icomplete-post-command-hook (defvar icomplete-minibuffer-map (let ((map (make-sparse-keymap))) - (define-key map [?\M-\t] 'minibuffer-force-complete) + (define-key map [?\M-\t] 'icomplete-force-complete) (define-key map [?\C-j] 'icomplete-force-complete-and-exit) (define-key map [?\C-.] 'icomplete-forward-completions) (define-key map [?\C-,] 'icomplete-backward-completions) @@ -162,6 +162,21 @@ icomplete-force-complete-and-exit (minibuffer-force-complete-and-exit) (minibuffer-complete-and-exit))) +(defun icomplete-force-complete () + "Complete the icomplete minibuffer." + (interactive) + (let ((retval (minibuffer-force-complete))) + ;; FIXME: What's this you ask? Do deal with a cycling corner + ;; case, `minibuffer-force-complete' will replace the keybinding + ;; that `icomplete-force-complete' was called with, but at least + ;; returns a function which we can call to disable that, since + ;; we're not interested in cycling at all here (bug#34077). + (when (and completion-cycling (functionp retval)) (funcall retval))) + ;; Again, since we're not interested in cycling, we want prospects + ;; to be recalcualted, and not based on cached, rotated completions. + (setq completion-cycling nil) + (setq completion-all-sorted-completions nil)) + (defun icomplete-forward-completions () "Step forward completions by one entry. Second entry becomes the first and can be selected with diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 5760a2e49d..b06f13251f 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1257,7 +1257,12 @@ completion-all-sorted-completions (defun minibuffer-force-complete-and-exit () "Complete the minibuffer with first of the matches and exit." (interactive) - (minibuffer-force-complete) + ;; If `completion-cycling' is t, then surely a + ;; `minibuffer-force-complete' has already executed. This is not + ;; for speed: the extra rotation caused by the second unnecessary call + ;; would mess up the final result value (bug#34116). + (unless completion-cycling + (minibuffer-force-complete)) (completion--complete-and-exit (minibuffer-prompt-end) (point-max) #'exit-minibuffer ;; If the previous completion completed to an element which fails From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 23 11:09:48 2019 Received: (at 34116) by debbugs.gnu.org; 23 Jan 2019 16:09:48 +0000 Received: from localhost ([127.0.0.1]:42955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmL64-0004Bo-Bs for submit@debbugs.gnu.org; Wed, 23 Jan 2019 11:09:48 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:57893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmL62-0004Bg-AO for 34116@debbugs.gnu.org; Wed, 23 Jan 2019 11:09:47 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x0NG9jsj011355; Wed, 23 Jan 2019 11:09:45 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 32753AE6E4; Wed, 23 Jan 2019 11:09:45 -0500 (EST) From: Stefan Monnier To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken Message-ID: References: <87tvi5pq35.fsf@gmail.com> Date: Wed, 23 Jan 2019 11:09:45 -0500 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Wed, 23 Jan 2019 15:49:00 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Rules: 3 Rules triggered GEN_SPAM_FEATRE=0.1, EDT_SA_DN_PASS=0, RV6467=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6467> : inlines <6998> : streams <1810928> : uri <2784437> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > But what about this which solves both problems bug#34077 > and bug#34116? LGTM, Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 23 11:36:26 2019 Received: (at 34116) by debbugs.gnu.org; 23 Jan 2019 16:36:27 +0000 Received: from localhost ([127.0.0.1]:42988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmLVq-0004ul-Hp for submit@debbugs.gnu.org; Wed, 23 Jan 2019 11:36:26 -0500 Received: from mail-qt1-f182.google.com ([209.85.160.182]:33392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmLVo-0004uJ-PU; Wed, 23 Jan 2019 11:36:25 -0500 Received: by mail-qt1-f182.google.com with SMTP id l11so3096323qtp.0; Wed, 23 Jan 2019 08:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0m4/Retqoqrbx+KIjNQy3/qp1kCArgII3M356X6l79M=; b=T3riDgv3hHuvneMEf915AdZR0GDPNxbizsGQEHYCT1VartGvH+JA/45NZPIob/qK8n 247FiFgV0/wuuJnED6/41uZiabdeOb9EYfhsBIzJImcZmwHjPA/P4w4+/WLQHs63l9wX sreh596dtSE6yQ9fPGaKKE2dz6XJh+w1akdemIWhxZ9aUdNivZ62ITvuAcwfp6LbIbTl 67ufP5FhKS93ReJmOTPJdExuAuVBkKurIxpKL3n2dMU0tuh7mHea0PE+sgdWQ9HCPWv7 Gyw4AdeLmVajpDdSLQLKZPogiacpysRqZ4Hg8Ah/RfIrRQSTtjgRm8VIH8FX+qkol/xt UCeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0m4/Retqoqrbx+KIjNQy3/qp1kCArgII3M356X6l79M=; b=DeYCdSrjl//uRe1xe9/t/jgP2Z0jiYukIKEdMAmxu7QsOO1Gzoa2XPehl/ZTDxjCEJ KhDo09XkdQW5OOemV7GOBqP25hp9zPsdKy4f8Nw6+/WyD+LeAyFMwcU+u30gUh6zoVLL ngTCOEH7LSzJjCMemP2zpOYmHCARdARX+/AmmFnsl4SWu6wjV7TAC+TQIMPD/YAsAczJ M23qwOAQkWPoTr5UP3OAkx+5QIenW320Vv2vflZc0takwOSCjQw/I4pD/n4nViv3aRsV pJJ21fJwq1mj8qOQKBYooTuTk+9Xr90DiUpmR6uUzyf5voHxDMQz+Qkkth98oJZGZR53 RGBg== X-Gm-Message-State: AJcUukfuN0Tf+t8WZ2MbAGZ75yo3oIfGBSkVB7T6KD5bfCkM1IreMNgx 6FNOZZI6pO77EsF6smWLFv438K6OeoZkkp4axsQ= X-Google-Smtp-Source: ALg8bN6kZQn0Fa+Ks/TnGQvKKMACeZXLh6jyBqGrjif2c67CdbLHJgm+g0BpnPah6kxkfROh5fX3p0foKlaCIgGlBas= X-Received: by 2002:ac8:3790:: with SMTP id d16mr3085670qtc.20.1548261379042; Wed, 23 Jan 2019 08:36:19 -0800 (PST) MIME-Version: 1.0 References: <87tvi5pq35.fsf@gmail.com> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Wed, 23 Jan 2019 16:36:07 +0000 Message-ID: Subject: Re: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 34116 Cc: 34116@debbugs.gnu.org, 34116-done@debbugs.gnu.org, bug#34077 <34077@debbugs.gnu.org>, 34077-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) On Wed, Jan 23, 2019 at 4:09 PM Stefan Monnier w= rote: > > > But what about this which solves both problems bug#34077 > > and bug#34116? > > LGTM, > Stefan Great! commit b9add0a5a7eddcf80a189c478b39a5cb7a12befe (HEAD -> master, origin/master, origin/HEAD) Author: Jo=C3=A3o T=C3=A1vora Date: Wed Jan 23 16:30:41 2019 +0000 Force completion in icomplete with C-M-i, but don't cycle (bug#34077) Cycling after forcing a completion with C-M-i in icomplete can be confusing, as it leaves rotated prospects in the minibuffer. In C-x C-f, for example it is very difficult to understand if the prospects refer to subdirectories of the directory being completed to, which happens naturally when the completion is unique; or if they are a cycled version of prospects that match the new completion pattern, in case the completion happens to still match other items. To resolve this confusion, never cycle with C-M-i in icomplete: non-ambiguous cycling can be achieved with C-. and C-, The former behaviour can still be restored with: (define-key icomplete-minibuffer-map (kbd "C-M-i") 'minibuffer-force-complete) * lisp/icomplete.el (icomplete-force-complete): New command. (icomplete-minibuffer-map): Bind C-M-i to icomplete-force-complete. commit 210e592e55ade154c8d58bd467711fb69368f6cb Author: Jo=C3=A3o T=C3=A1vora Date: Wed Jan 23 16:17:03 2019 +0000 Avoid cycling in minibuffer-force-complete-and-exit (bug#34116) * lisp/minibuffer.el (minibuffer-force-complete-and-exit): Check completion-cycling before minibuffer-force-complete. From unknown Fri Jun 20 07:19:50 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 21 Feb 2019 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator