GNU bug report logs - #65980
30.0.50; C-e behaves surprisingly in minibuffer

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 65980 <at> debbugs.gnu.org
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 <at> gmx.net>
> Cc: 65980 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.