From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer Date: Thu, 20 Apr 2023 21:18:57 +0300 Organization: LINKOV.NET Message-ID: <868rema032.fsf@mail.linkov.net> References: <8635574n10.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="28253"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: 62700@debbugs.gnu.org, Spencer Baugh To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 20 20:23:25 2023 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 1ppYwG-0007GB-Ks for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Apr 2023 20:23:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppYvw-0002lo-P4; Thu, 20 Apr 2023 14:23:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppYvu-0002k0-FH for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 14:23:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppYvu-0001gm-6h for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 14:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppYvt-0007tx-Ns for bug-gnu-emacs@gnu.org; Thu, 20 Apr 2023 14:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Apr 2023 18:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62700 X-GNU-PR-Package: emacs Original-Received: via spool by 62700-submit@debbugs.gnu.org id=B62700.168201494930332 (code B ref 62700); Thu, 20 Apr 2023 18:23:01 +0000 Original-Received: (at 62700) by debbugs.gnu.org; 20 Apr 2023 18:22:29 +0000 Original-Received: from localhost ([127.0.0.1]:38659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppYvN-0007tA-6K for submit@debbugs.gnu.org; Thu, 20 Apr 2023 14:22:29 -0400 Original-Received: from relay1-d.mail.gandi.net ([217.70.183.193]:35447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppYvK-0007su-5s for 62700@debbugs.gnu.org; Thu, 20 Apr 2023 14:22:28 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 6A54B240009; Thu, 20 Apr 2023 18:22:16 +0000 (UTC) In-Reply-To: (Spencer Baugh's message of "Thu, 20 Apr 2023 12:52:20 -0400") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260351 Archived-At: >>>> It just needs more testing for different categories of completion. >>> >>> Which categories do you have in mind? >> >> Actually, I can't find categories where it could fail. >> So your patch looks safe to push. > > Can we go ahead and push it to Emacs master, then? I will work on the > changing-only-new-code backport for Emacs 29 as Eli requested. But your patch changes only new code. >>>> Maybe you could find another heuristic for insertion of completion? >>>> The code is located in the same function 'minibuffer-completion-help': >>>> >>>> (if (and (stringp start) (stringp end)) >>>> (progn >>>> (delete-minibuffer-contents) >>>> (insert start choice) >>>> ;; Keep point after completion before suffix >>>> (save-excursion (insert end))) >>>> >>>> Currently it keeps point before the suffix. >>> >>> I will try. Although this is a case where completion-base-position feels >>> more suited than completion-base-affixes... >> >> Can you get the same info about positions by calculating the >> lengths of prefix/choice/suffix? > > Hm I have thought about it but I can't see a simple heuristic. > > It's not actually clear what behavior we want, anyway. When TAB > completes a string fully, it sends point to the end of the buffer. This > happens even if completion-cycle-threshold is non-nil, and > completion-cycle-threashold feels like a pretty similar feature to > minibuffer-{previous,next}-completion. So maybe that's correct for us to > do here too? > > But a different behavior feels like it could also makes sense. For > example, if I'm completing from ffap-|-path (| is point), I'm just > cycling between ffap-bib-path, ffap-c++-path, ffap-c-path, and it feels > like as I cycle through those, point should stay right before "-path", > like ffap-bib|-path, ffap-c++|-path, ffap-c|-path. No idea how to > achieve this behavior though. This also makes sense: ffap-|bib-path, ffap-|c++-path, ffap-|c-path. I tried it with this tentative patch and it feels quite natural, so maybe could be turned into an option: diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index a6af65dfa14..733f7710378 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2366,6 +2371,7 @@ minibuffer-completion-help (let* ((start (or start (minibuffer--completion-prompt-end))) (end (or end (point-max))) (string (buffer-substring start end)) + (pos (1- (point))) (md (completion--field-metadata start)) (completions (completion-all-completions string @@ -2493,7 +2503,8 @@ minibuffer-completion-help (delete-minibuffer-contents) (insert start choice) ;; Keep point after completion before suffix - (save-excursion (insert end))) + (save-excursion (insert end)) + (move-to-column pos)) (unless (or (zerop (length prefix)) (equal prefix (buffer-substring-no-properties > Anyway, the behavior with my earlier patch now feels fine to me, I don't > think we need any improvements to point's behavior for now. Maybe your patch still could be pushed to emacs-29 because it fixes the new feature.