From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer Date: Fri, 15 Sep 2023 14:35:50 +0200 Message-ID: <87ttrv397d.fsf@gmx.net> References: <877cos8zqf.fsf@rub.de> <83edj0ll7z.fsf@gnu.org> <8734zg8p9m.fsf@rub.de> <83bke4kn92.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21631"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65980@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 15 14:37:23 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 1qh84Z-0005R1-Co for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Sep 2023 14:37:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh84P-0000N8-6E; Fri, 15 Sep 2023 08:37:14 -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 1qh84B-0000IH-8F for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 08:37:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qh847-0004rv-8y for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 08:36:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qh84D-0006tK-Kw for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 08:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Sep 2023 12:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65980 X-GNU-PR-Package: emacs Original-Received: via spool by 65980-submit@debbugs.gnu.org id=B65980.169478136626421 (code B ref 65980); Fri, 15 Sep 2023 12:37:01 +0000 Original-Received: (at 65980) by debbugs.gnu.org; 15 Sep 2023 12:36:06 +0000 Original-Received: from localhost ([127.0.0.1]:42387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qh83J-0006s5-U3 for submit@debbugs.gnu.org; Fri, 15 Sep 2023 08:36:06 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:54543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qh83I-0006rV-1j for 65980@debbugs.gnu.org; Fri, 15 Sep 2023 08:36:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1694781351; x=1695386151; i=stephen.berman@gmx.net; bh=o9nIEN4h1+Qgt4vIzRoviCZtAB8nxepsp6CSx4A2HkE=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=OayWNc5iGiZ5/0y+24/VssNJO8fjzkZGKzlyxi7asfaPHqCiummnCI20NTnum6/hBGEt/S1XYyR rH4T3JVASCcp/ilJDQoXFIBl9RVuCAxEsOP5IWWPexH6DXf5BOAiILjgey4+OSUVXXLEWvRcXzAbb HX7H/jsBmiQBBIjay1A/ZKYWjZCybhLwOEIMZhA2EvFQlF0miHy/RkoSKhtXjfXOZu0y0wianwjE3 RiRS2vNz4nYn74NOZxCcRAc3XTTvh+Fx4AeX/xZCBGfBx6cUkYQfvpNYjiRjgeJ19JNzDBxZdXue4 KPbLINRRJN6cc0QGXVOK5PoRw8n3p2UPW0ag== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from strobelfs2 ([94.134.196.64]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MFbRm-1qw0wz0fEs-00H5V4; Fri, 15 Sep 2023 14:35:51 +0200 In-Reply-To: <83bke4kn92.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Sep 2023 08:40:25 +0300") X-Provags-ID: V03:K1:s2mPEhTSzkK/DF2PCijiYYAZ2/ZPJ/LiYMCsRcNShtJXqzy54Lp ThCaX2ZeP2a/Zycv5PfMdY3KKlglFvE/s8yL726RnQHfx+NQ/bpYGV0kpED7KVzvSKS2gSK FniQ+FYWMKlZa1kMxtlV/+sFLuIEo0Mo/HRDsB3LQDUCGLx8OdrkBK++bgY+CzX7B02znDN D2DeoqdSAF9uIHYGsW1jg== UI-OutboundReport: notjunk:1;M01:P0:iOaZBbPtAd8=;xnG/+Dxo6jXG5GvVun8nD24GIQ6 ow3bDjxi5EtzeJbWe93WQR1yq6Uh3wrvhFbsqbrhbjaKFvIpKIgTBykyfLn1ZT+M1//SEDCHg qax8FjeG5QaWt0Yt/vtzEGw3JNiHu+s1YoOGlNrY1NmoIfcw0J0/zFPXV/N328lXwOT9BHp7w wzB0YSTqUSL4vUxC62/QUarjHNpVfsmxF7+T1bnM4drqkgY3WgyNMBCrxWwDL1dG+XbthLBTQ iVyP27q7rrie5K1vNl7GqFpwtCKpoK36whvmFJ/+H3q7fNq8purXhHpYYlFSnx5bgyHZXdm23 dW7yJRBavf9WNBJ3PnWV03yu20kuY79OFAqIwCvL+1UMAwVfONwHw1x8cM54VwSyVfV8TNs9V X0itz4Ggtu/LZ0SrMyFXytSZsleNg9HFF64QMHu3BGyoZmWeDwA2I8jfMOPfIzjJW8dOBFUtr 4Yh24VuysQIkYY1GU/DKv1U2l5vHLCSz5MSlrPLLPK17W2llkUY4bwLlLUm0Vf64/sI+Cu5DE Kdv1exFYs2mI0l0YRFRJF390NNIa1EbdC62WxBc3DIstfZh5QEGPcpPqngY8z781tdSGSX2w1 hMz+yWdwwwZ8aqqV97JtS9OkqYudYg4WuKwDTN8C9isuC8N+561sVzIKb6vfwBMXSBXKNndWT dUiUbFvQfuu7Rv2++zJItr4U3BcJei77Ah8kzud0K03ITvs9Dmv/xzqK4te6nKOgYtY+6WUqz GoM4stseD15s/cmg4lmA1T5peld+QmHve7iVAS2fS/kHdIhVL9mq+OoTA1s6rauNvXIHpCDL 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:270531 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 15 Sep 2023 08:40:25 +0300 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: 65980@debbugs.gnu.org >> Date: Thu, 14 Sep 2023 22:37:41 +0200 >> >> > It's because of fields. If you want this to work disregarding fields= , >> > set inhibit-field-text-motion non-nil, and then C-a and C-e will do >> > what you expect even if you enter the prompt (which has the field >> > property). >> >> Yes, that makes C-e in step 6 work the same as in step 2, but it doesn'= t >> explain why the two cases are different. The point of my patch is to >> make the behavior of C-e in the minibuffer the same in both cases. It'= s >> a change for the benefit of Emacs users, not for Elisp programmers. Do >> you know of any unwanted consequences of making such a change? > > Your patch changes one of the subroutines of next-line and > previous-line. Those by now became very complex creatures, and handle > many different cases of vertical cursor motion (with and without > visual-line-mode, with and without line truncation, with and without > R2L text, etc.) So I hesitate to even consider it for this obscure use > case. I'd be much happier if the change was in move-beginning-of-line > and move-end-of-line instead, so that it wouldn't have any chance of > affecting other commands. Could you try to come up with such a change > instead? Sure. I think the easiest way is simply to take your observation about inhibit-field-text-motion and confine it to the minibuffer: --=-=-= Content-Type: text/x-patch Content-Disposition: inline Content-Description: move-end-of-line patch 1 diff --git a/lisp/simple.el b/lisp/simple.el index 35dd0f59e29..1f987a30abb 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8263,7 +8263,8 @@ move-end-of-line (let ((newpos (save-excursion (let ((goal-column 0) - (line-move-visual nil)) + (line-move-visual nil) + (inhibit-field-text-motion (minibufferp))) (and (line-move arg t) ;; With bidi reordering, we may not be at bol, ;; so make sure we are. --=-=-= Content-Type: text/plain I see no need to change move-beginning-of-line, because it already behaves the same regardless of the length of the text after the prompt, namely, moving to the start of the text instead of the start of the prompt, and this is useful behavior. This does, however, raise the question of whether invoking move-end-of-line with point within the prompt string should just move to the end of the prompt, which would make it more like the mirror image of move-beginning-of-line in the minibuffer. This is easy to do for the case of the text after the prompt extending beyond window-width: --=-=-= Content-Type: text/x-patch Content-Disposition: inline Content-Description: move-end-of-line patch 2 diff --git a/lisp/simple.el b/lisp/simple.el index 35dd0f59e29..d676fe46611 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8265,15 +8265,16 @@ move-end-of-line (let ((goal-column 0) (line-move-visual nil)) (and (line-move arg t) - ;; With bidi reordering, we may not be at bol, - ;; so make sure we are. - (skip-chars-backward "^\n") - (not (bobp)) - (progn - (while (and (not (bobp)) (invisible-p (1- (point)))) - (goto-char (previous-single-char-property-change - (point) 'invisible))) - (backward-char 1))) + (if (minibufferp) t + ;; With bidi reordering, we may not be at bol, + ;; so make sure we are. + (skip-chars-backward "^\n") + (not (bobp)) + (progn + (while (and (not (bobp)) (invisible-p (1- (point)))) + (goto-char (previous-single-char-property-change + (point) 'invisible))) + (backward-char 1)))) (point))))) (goto-char newpos) (if (and (> (point) newpos) --=-=-= Content-Type: text/plain However, when the text after the prompt ends before window-width, typing C-e with point within the prompt still moves to the end of the text, even with this patch. I currently don't see a way to confine the movement to the prompt field in this case without changing line-move-1, probably the code involving the test (zerop (vertical-motion 1)). I could try to do that, but maybe it's better just to retain the current behavior of move-end-of-line in the minibuffer, but make it consistent with respect to the length of the text after the prompt, as the first patch does. Steve Berman --=-=-=--