From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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, 06 Apr 2023 21:22:42 +0300 Message-ID: <83r0swq39p.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12513"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62700@debbugs.gnu.org, juri@linkov.net To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 06 20:23:19 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 1pkUGV-00032F-Nh for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Apr 2023 20:23:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pkUGG-0000j7-LQ; Thu, 06 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 1pkUGF-0000iO-8k for bug-gnu-emacs@gnu.org; Thu, 06 Apr 2023 14:23:03 -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 1pkUGE-0007fB-Tq for bug-gnu-emacs@gnu.org; Thu, 06 Apr 2023 14:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pkUGE-0005UO-8T for bug-gnu-emacs@gnu.org; Thu, 06 Apr 2023 14:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Apr 2023 18:23:02 +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.168080534321018 (code B ref 62700); Thu, 06 Apr 2023 18:23:02 +0000 Original-Received: (at 62700) by debbugs.gnu.org; 6 Apr 2023 18:22:23 +0000 Original-Received: from localhost ([127.0.0.1]:55121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkUFb-0005Sv-3C for submit@debbugs.gnu.org; Thu, 06 Apr 2023 14:22:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkUFY-0005SX-Lo for 62700@debbugs.gnu.org; Thu, 06 Apr 2023 14:22:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pkUFR-0007Gg-Tb; Thu, 06 Apr 2023 14:22:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gSWVzKoWrLCkxjnT33kVfcNKTYvYdCxOmw0uZfz1Tqs=; b=biVHDr2ODu/T EzQUkAyPn21GjzuTxjf7w9fk//yNjWKlszYm74TWrnUqCI2lSrAWDqE5Qlp7sYtlNmYNI4N0M2srE rg3toprSvnBP7R/7Kowj/4AnsyM3u2IwyXVUNT5LVFQ9XFZZNdQSJ5cFb+RAMlrbGwM7xo+2Cvc1C a9f0b03Sv1VdLE0b+POgjOQcsyKotuAtQGsiju0T2tNh3dite2EsVcEOGV4c/1ns0d5sUOf033KrR K4fIsGSCKFY2Tzp5q6qpOA06cmwOLD/aqAiWxQ58uLTFU1Pcn0YED/K0N9aB9IlBULkuiNTdd8fLc tpBcZQxP3Ko88iAiOYoIGw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pkUFR-0005L5-7c; Thu, 06 Apr 2023 14:22:13 -0400 In-Reply-To: (message from Spencer Baugh on Thu, 06 Apr 2023 13:56:35 -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:259343 Archived-At: > Cc: Juri Linkov > From: Spencer Baugh > Date: Thu, 06 Apr 2023 13:56:35 -0400 > > 6. C-h v -path > 7. C-a to move point to before -path > 8. to show completions of variables ending in -path > 9. Use M- and M- to switch between completions. Now as you > switch completions, they are inserted at point, *without* replacing the > text already in the buffer. So e.g. the minibuffer will contain > "load-path-path". > 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET > inserts the completion string at point, without replacing the text in > the minibuffer, so you will get "load-path-path". > > I think this is basically just a bug. I think it's the intended behavior. In this case, it looks not useful, because the string you typed before starting to use M- and M- happens to be at the end of each completion candidate. But this is not the only situation possible. Basically, completion always modifies only the text before point, leaving what's after point intact, so that the user could have after point stuff that completion should ignore, and that eventually will be appended to the selected candidate. > Hopefully we can fix this before Emacs 29 is released, because this > is the last thing which stops these new commands from being a really > great improvement to the Emacs completion defaults. Why did you need to move point to the beginning of what you typed to begin with? Unless you explain that, I don't see how we can consider this issue important enough to fix at all, let alone for Emacs 29. > If this is intentional for some reason, I think the behavior should > definitely be changed before Emacs 29 is released. Moving point around > in the minibuffer while completing is an important part of using the > default completion-styles It is? why?