bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer
Date: Thu, 14 Sep 2023 20:26:40 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]