* bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer @ 2023-09-14 16:51 Stephen Berman 2023-09-14 17:26 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Stephen Berman @ 2023-09-14 16:51 UTC (permalink / raw) To: 65980 [-- Attachment #1: Type: text/plain, Size: 1915 bytes --] 0. emacs -Q Sanity checks: 1. Type a command that prompts in the minibuffer and includes text that ends before window-width, resulting e.g. in this in the minibuffer: Find file: ~/src/emacs/emacs-master/INSTALL 2. 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. 3. Typing M-< moves point to the beginning of the prompt and then typing C-e moves point to the end of the file name. Change the input: 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. In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.6) of 2023-09-13 built on strobelfs2 Repository revision: 9838f786ded35fe49bbe84dd78af84df1337adbf Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 System Description: Linux From Scratch r12.0-19 Configured using: 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig' [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: line-move-1 patch --] [-- Type: text/x-patch, Size: 570 bytes --] diff --git a/lisp/simple.el b/lisp/simple.el index 35dd0f59e29..564265d8c60 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8053,8 +8053,9 @@ line-move-1 ;; We avoid vertical-motion when possible ;; because that has to fontify. (forward-line 1)) - ;; Otherwise move a more sophisticated way. - ((zerop (vertical-motion 1)) + ;; Otherwise move a more sophisticated way, unless + ;; we're in the minibuffer. + ((or (zerop (vertical-motion 1)) (minibufferp)) (if (not noerror) (signal 'end-of-buffer nil) (setq done t)))) ^ permalink raw reply related [flat|nested] 7+ messages in thread
* bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer 2023-09-14 16:51 bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer Stephen Berman @ 2023-09-14 17:26 ` Eli Zaretskii 2023-09-14 20:37 ` Stephen Berman 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2023-09-14 17:26 UTC (permalink / raw) To: Stephen Berman; +Cc: 65980 > 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). With fields, you are not supposed to use M-<, only C-a. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer 2023-09-14 17:26 ` Eli Zaretskii @ 2023-09-14 20:37 ` Stephen Berman 2023-09-15 5:40 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Stephen Berman @ 2023-09-14 20:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 65980 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer 2023-09-14 20:37 ` Stephen Berman @ 2023-09-15 5:40 ` Eli Zaretskii 2023-09-15 12:35 ` Stephen Berman 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2023-09-15 5:40 UTC (permalink / raw) To: Stephen Berman; +Cc: 65980 > 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer 2023-09-15 5:40 ` Eli Zaretskii @ 2023-09-15 12:35 ` Stephen Berman 2023-09-16 7:56 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Stephen Berman @ 2023-09-15 12:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 65980 [-- Attachment #1: Type: text/plain, Size: 1538 bytes --] On Fri, 15 Sep 2023 08:40:25 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> 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? Sure. I think the easiest way is simply to take your observation about inhibit-field-text-motion and confine it to the minibuffer: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: move-end-of-line patch 1 --] [-- Type: text/x-patch, Size: 483 bytes --] diff --git a/lisp/simple.el b/lisp/simple.el index 35dd0f59e29..1f987a30abb 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8263,7 +8263,8 @@ move-end-of-line (let ((newpos (save-excursion (let ((goal-column 0) - (line-move-visual nil)) + (line-move-visual nil) + (inhibit-field-text-motion (minibufferp))) (and (line-move arg t) ;; With bidi reordering, we may not be at bol, ;; so make sure we are. [-- Attachment #3: Type: text/plain, Size: 587 bytes --] I see no need to change move-beginning-of-line, because it already behaves the same regardless of the length of the text after the prompt, namely, moving to the start of the text instead of the start of the prompt, and this is useful behavior. This does, however, raise the question of whether invoking move-end-of-line with point within the prompt string should just move to the end of the prompt, which would make it more like the mirror image of move-beginning-of-line in the minibuffer. This is easy to do for the case of the text after the prompt extending beyond window-width: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #4: move-end-of-line patch 2 --] [-- Type: text/x-patch, Size: 1170 bytes --] diff --git a/lisp/simple.el b/lisp/simple.el index 35dd0f59e29..d676fe46611 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8265,15 +8265,16 @@ move-end-of-line (let ((goal-column 0) (line-move-visual nil)) (and (line-move arg t) - ;; With bidi reordering, we may not be at bol, - ;; so make sure we are. - (skip-chars-backward "^\n") - (not (bobp)) - (progn - (while (and (not (bobp)) (invisible-p (1- (point)))) - (goto-char (previous-single-char-property-change - (point) 'invisible))) - (backward-char 1))) + (if (minibufferp) t + ;; With bidi reordering, we may not be at bol, + ;; so make sure we are. + (skip-chars-backward "^\n") + (not (bobp)) + (progn + (while (and (not (bobp)) (invisible-p (1- (point)))) + (goto-char (previous-single-char-property-change + (point) 'invisible))) + (backward-char 1)))) (point))))) (goto-char newpos) (if (and (> (point) newpos) [-- Attachment #5: Type: text/plain, Size: 588 bytes --] 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. Steve Berman ^ permalink raw reply related [flat|nested] 7+ messages in thread
* bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer 2023-09-15 12:35 ` Stephen Berman @ 2023-09-16 7:56 ` Eli Zaretskii 2023-09-16 12:02 ` Stephen Berman 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2023-09-16 7:56 UTC (permalink / raw) To: Stephen Berman; +Cc: 65980 > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer 2023-09-16 7:56 ` Eli Zaretskii @ 2023-09-16 12:02 ` Stephen Berman 0 siblings, 0 replies; 7+ messages in thread From: Stephen Berman @ 2023-09-16 12:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 65980-done On Sat, 16 Sep 2023 10:56:27 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> 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. Done in commit 33ff4fed03d and closing the bug. Thanks. Steve Berman ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-09-16 12:02 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-09-14 16:51 bug#65980: 30.0.50; C-e behaves surprisingly in minibuffer Stephen Berman 2023-09-14 17:26 ` Eli Zaretskii 2023-09-14 20:37 ` Stephen Berman 2023-09-15 5:40 ` Eli Zaretskii 2023-09-15 12:35 ` Stephen Berman 2023-09-16 7:56 ` Eli Zaretskii 2023-09-16 12:02 ` Stephen Berman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).