bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

0. emacs -Q
Sanity checks:
1. Type a command that prompts in the minibuffer and includes text that
   ends before window-width, resulting e.g. in this in the minibuffer:
   Find file: ~/src/emacs/emacs-master/INSTALL
2. Typing C-a moves point to the beginning of the file name and then
   typing C-e moves point to the end of the file name.
3. Typing M-< moves point to the beginning of the prompt and then typing
   C-e moves point to the end of the file name.
Change the input:
4. Now type a command that includes text that extends beyond
   window-width, resulting e.g. in this in the minibuffer:
   Find file: ~/src/emacs/emacs-master/java/org/gnu/emacs/EmacsLauncherPreferencesActivity.java
5. Typing C-a moves point to the beginning of the file name and then
   typing C-e moves point to the end of the file name (same as step 2).
Here's the surprising behavior:
6. Typing M-< moves point to the beginning of the prompt but now typing
   C-e fails to move point.  And if you move point to any position
   within the prompt, e.g. M-f to put point after "Find", then typing
   C-e moves point to the beginning of the prompt.

It certainly seems like a bug that C-e, i.e. move-end-of-line, fails to
move to the end of the line in step 6, and the inconsistency between the
results in step 3 and step 6 also seems like a bug.  The attached patch
ensures that C-e in step 6 moves to the end of the file name, as in step
2, and should only affect the use of C-e in the minibuffer.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.6) of 2023-09-13 built on strobelfs2
Repository revision: 9838f786ded35fe49bbe84dd78af84df1337adbf
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Linux From Scratch r12.0-19

Configured using:
 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: line-move-1 patch --]
[-- Type: text/x-patch, Size: 570 bytes --]

diff --git a/lisp/simple.el b/lisp/simple.el
index 35dd0f59e29..564265d8c60 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8053,8 +8053,9 @@ line-move-1
 		  ;; We avoid vertical-motion when possible
 		  ;; because that has to fontify.
 		  (forward-line 1))
-		 ;; Otherwise move a more sophisticated way.
-		 ((zerop (vertical-motion 1))
+		 ;; Otherwise move a more sophisticated way, unless
+		 ;; we're in the minibuffer.
+		 ((or (zerop (vertical-motion 1)) (minibufferp))
 		  (if (not noerror)
 		      (signal 'end-of-buffer nil)
 		    (setq done t))))

bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Thu, 14 Sep 2023 18:51:36 +0200
> 
> 4. Now type a command that includes text that extends beyond
>    window-width, resulting e.g. in this in the minibuffer:
>    Find file: ~/src/emacs/emacs-master/java/org/gnu/emacs/EmacsLauncherPreferencesActivity.java
> 5. Typing C-a moves point to the beginning of the file name and then
>    typing C-e moves point to the end of the file name (same as step 2).
> Here's the surprising behavior:
> 6. Typing M-< moves point to the beginning of the prompt but now typing
>    C-e fails to move point.  And if you move point to any position
>    within the prompt, e.g. M-f to put point after "Find", then typing
>    C-e moves point to the beginning of the prompt.
> 
> It certainly seems like a bug that C-e, i.e. move-end-of-line, fails to
> move to the end of the line in step 6, and the inconsistency between the
> results in step 3 and step 6 also seems like a bug.  The attached patch
> ensures that C-e in step 6 moves to the end of the file name, as in step
> 2, and should only affect the use of C-e in the minibuffer.

It's because if 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).

With fields, you are not supposed to use M-<, only C-a.

bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

[Stephen Berman]

On Thu, 14 Sep 2023 20:26:40 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Thu, 14 Sep 2023 18:51:36 +0200
>> 
>> 4. Now type a command that includes text that extends beyond
>>    window-width, resulting e.g. in this in the minibuffer:
>>    Find file:
>> ~/src/emacs/emacs-master/java/org/gnu/emacs/EmacsLauncherPreferencesActivity.java
>> 5. Typing C-a moves point to the beginning of the file name and then
>>    typing C-e moves point to the end of the file name (same as step 2).
>> Here's the surprising behavior:
>> 6. Typing M-< moves point to the beginning of the prompt but now typing
>>    C-e fails to move point.  And if you move point to any position
>>    within the prompt, e.g. M-f to put point after "Find", then typing
>>    C-e moves point to the beginning of the prompt.
>> 
>> It certainly seems like a bug that C-e, i.e. move-end-of-line, fails to
>> move to the end of the line in step 6, and the inconsistency between the
>> results in step 3 and step 6 also seems like a bug.  The attached patch
>> ensures that C-e in step 6 moves to the end of the file name, as in step
>> 2, and should only affect the use of C-e in the minibuffer.
>
> It's because if 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?

> With fields, you are not supposed to use M-<, only C-a.

Then perhaps that should be documented in the Emacs manual, since this
is a user issue.  That manual currently makes no mention of either
inhibit-field-text-motion or fields in the sense of the field property.
But I don't think these (or at least the variable) should have to be a
user concern, what matters is that Emacs behaves as documented.  That is
the raison d'être of my patch.  Of course, if it introduces other
problems, then it has to be either improved or dispensed with.

Steve Berman

bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> 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?

bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

On Fri, 15 Sep 2023 08:40:25 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: move-end-of-line patch 1 --]
[-- Type: text/x-patch, Size: 483 bytes --]

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.

[-- Attachment #3: Type: text/plain, Size: 587 bytes --]


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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: move-end-of-line patch 2 --]
[-- Type: text/x-patch, Size: 1170 bytes --]

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)

[-- Attachment #5: Type: text/plain, Size: 588 bytes --]


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

bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 65980@debbugs.gnu.org
> Date: Fri, 15 Sep 2023 14:35:50 +0200
> 
> > 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:

Thanks, please install your first patch on the emacs-29 branch.

> 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.

I agree.

bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer

[Stephen Berman]

On Sat, 16 Sep 2023 10:56:27 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 65980@debbugs.gnu.org
>> Date: Fri, 15 Sep 2023 14:35:50 +0200
>>
>> > 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:
>
> Thanks, please install your first patch on the emacs-29 branch.

Done in commit 33ff4fed03d and closing the bug.  Thanks.

Steve Berman