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

[Eli Zaretskii <eliz@gnu.org>]

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