[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: |
Fri, 15 Sep 2023 08:40:25 +0300 |
> 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?