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