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.