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