bug#3447: suggest minibuffer M-< go to start of text

bug#3447: suggest minibuffer M-< go to start of text

[Kevin Ryde]

In the minibuffer it'd be good if M-<, currently `beginning-of-buffer',
went to the start of the editable text rather than the start of the
prompt.  The start of editable text would match what C-a
`move-beginning-of-line' now does.

Dunno if it'd be best to have a function recognising "field" stuff, or
just a different keybinding in the minibuffer.  I've been using the
couple of lines below.  It's good when you've got a multiple lines in
the minibuffer.


(defun my-minibuffer-beginning-of-buffer ()
  (interactive)
  (or (and (fboundp 'region-active-p) ;; new in emacs23
           (region-active-p))
      (push-mark))
  (if (<= (point) (minibuffer-prompt-end))
      (goto-char (point-min))
    (goto-char (minibuffer-prompt-end))))
(define-key minibuffer-local-map "\M-<" 'my-minibuffer-beginning-of-buffer)




In GNU Emacs 22.3.1 (i486-pc-linux-gnu, GTK+ Version 2.14.7)
 of 2009-03-31 on raven, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs22:/etc/emacs:/usr/local/share/emacs/22.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.3/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.3/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

bug#3447: suggest minibuffer M-< go to start of text

[Lars Ingebrigtsen]

Kevin Ryde <user42@zip.com.au> writes:

> Dunno if it'd be best to have a function recognising "field" stuff, or
> just a different keybinding in the minibuffer.  I've been using the
> couple of lines below.  It's good when you've got a multiple lines in
> the minibuffer.
>
> (defun my-minibuffer-beginning-of-buffer ()
>   (interactive)
>   (or (and (fboundp 'region-active-p) ;; new in emacs23
>            (region-active-p))
>       (push-mark))
>   (if (<= (point) (minibuffer-prompt-end))
>       (goto-char (point-min))
>     (goto-char (minibuffer-prompt-end))))
> (define-key minibuffer-local-map "\M-<" 'my-minibuffer-beginning-of-buffer)

I think something like this would be a very good idea.  I frequently
have long, multiline expressions in the minibuffer, and `M-<' not taking
me to the start of the editable data is annoying.

Does anybody object to making a change like this?  (It'll have to be
modernised a bit, of course.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3447: suggest minibuffer M-< go to start of text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 30 Sep 2019 10:23:42 +0200
> Cc: 3447@debbugs.gnu.org
> 
> > (defun my-minibuffer-beginning-of-buffer ()
> >   (interactive)
> >   (or (and (fboundp 'region-active-p) ;; new in emacs23
> >            (region-active-p))
> >       (push-mark))
> >   (if (<= (point) (minibuffer-prompt-end))
> >       (goto-char (point-min))
> >     (goto-char (minibuffer-prompt-end))))
> > (define-key minibuffer-local-map "\M-<" 'my-minibuffer-beginning-of-buffer)
> 
> I think something like this would be a very good idea.  I frequently
> have long, multiline expressions in the minibuffer, and `M-<' not taking
> me to the start of the editable data is annoying.
> 
> Does anybody object to making a change like this?

As an opt-in behavior, please.  We can make it the default later, if
there's enough demand.

bug#3447: suggest minibuffer M-< go to start of text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> As an opt-in behavior, please.  We can make it the default later, if
> there's enough demand.

I can do that, but after using this for a bit, it just seems like very
natural behaviour, which makes me wonder whether anybody really enjoys
the previous behaviour.  I mean, there's very little of use you can do
before the end of the minibuffer prompt.  The only use case I can see is
if you want to copy the entire buffer contents to the kill ring...
but...  how often is that done?

Perhaps we could just do the change below (calling it out in NEWS) and
see whether anybody complains?  And if they do, we'll introduce the
variable.

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 3fa637f2ac..20be32f307 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2233,6 +2233,7 @@ completion-help-at-point
 
 (let ((map minibuffer-local-map))
   (define-key map "\C-g" 'abort-recursive-edit)
+  (define-key map "\M-<" 'minibuffer-beginning-of-buffer)
   (define-key map "\r" 'exit-minibuffer)
   (define-key map "\n" 'exit-minibuffer))
 
@@ -3589,6 +3590,32 @@ minibuffer-insert-file-name-at-point
     (when file-name-at-point
       (insert file-name-at-point))))
 
+(defun minibuffer-beginning-of-buffer (&optional arg)
+  "Move to the logical beginning of the minibuffer.
+This command behaves like `beginning-of-buffer', but if point is
+after the end of the prompt, move to the end of the prompt.
+Otherwise move to the start of the buffer."
+  (declare (interactive-only "use `(goto-char (point-min))' instead."))
+  (interactive "^P")
+  (when (or (consp arg)
+            (region-active-p))
+    (push-mark))
+  (goto-char (cond
+              ;; We want to go N/10th of the way from the beginning.
+              ((and arg (not (consp arg)))
+	       (+ (point-min) 1
+		  (/ (* (- (point-max) (point-min))
+                        (prefix-numeric-value arg))
+                     10)))
+              ;; Go to the start of the buffer.
+              ((<= (point) (minibuffer-prompt-end))
+	       (point-min))
+              ;; Go to the end of the minibuffer.
+              (t
+               (minibuffer-prompt-end))))
+  (when (and arg (not (consp arg)))
+    (forward-line 1)))
+
 (provide 'minibuffer)
 
 ;;; minibuffer.el ends here

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3447: suggest minibuffer M-< go to start of text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: user42@zip.com.au,  3447@debbugs.gnu.org
> Date: Tue, 01 Oct 2019 13:58:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > As an opt-in behavior, please.  We can make it the default later, if
> > there's enough demand.
> 
> I can do that, but after using this for a bit, it just seems like very
> natural behaviour, which makes me wonder whether anybody really enjoys
> the previous behaviour.  I mean, there's very little of use you can do
> before the end of the minibuffer prompt.  The only use case I can see is
> if you want to copy the entire buffer contents to the kill ring...
> but...  how often is that done?

I understand that this is your impression, but that's just a single
person's impression.  The change in behavior is not insignificant.

> Perhaps we could just do the change below (calling it out in NEWS) and
> see whether anybody complains?  And if they do, we'll introduce the
> variable.

The problem with the complaints is that they usually come only after
Emacs is released, and by that time it is too late.  So let's have the
defcustom, please.

bug#3447: suggest minibuffer M-< go to start of text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The problem with the complaints is that they usually come only after
> Emacs is released, and by that time it is too late.  So let's have the
> defcustom, please.

OK; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3447: suggest minibuffer M-< go to start of text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 3447@debbugs.gnu.org,  user42@zip.com.au
> Date: Tue, 01 Oct 2019 15:02:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The problem with the complaints is that they usually come only after
> > Emacs is released, and by that time it is too late.  So let's have the
> > defcustom, please.
> 
> OK; done.

Thanks.

bug#3447: suggest minibuffer M-< go to start of text

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

reopen 3447
quit

>> (define-key minibuffer-local-map "\M-<" 'my-minibuffer-beginning-of-buffer)
>
> I think something like this would be a very good idea.  I frequently
> have long, multiline expressions in the minibuffer, and `M-<' not taking
> me to the start of the editable data is annoying.
>
> Does anybody object to making a change like this?  (It'll have to be
> modernised a bit, of course.)

This still doesn't work with <C-home>.  This can be fixed
by remapping beginning-of-buffer in the patch below.

Like 'C-a' goes to the end of the prompt exactly like <home>,
there is no reason not to do the same for 'M-<' and <C-home>.

Moreover, we don't add defcustoms for simple key bindings
because keybinding are configured with the help of define-key.

This patch should do the right thing:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: minibuffer-remap-beginning-of-buffer.patch --]
[-- Type: text/x-diff, Size: 1646 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6e72eb73f9..d4b3cb8297 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2240,7 +2240,7 @@ completion-help-at-point
 
 (let ((map minibuffer-local-map))
   (define-key map "\C-g" 'abort-recursive-edit)
-  (define-key map "\M-<" 'minibuffer-beginning-of-buffer)
+  (define-key map [remap beginning-of-buffer] 'minibuffer-beginning-of-buffer)
 
   (define-key map [remap recenter-top-bottom] 'minibuffer-recenter-top-bottom)
   (define-key map [remap scroll-up-command] 'minibuffer-scroll-up-command)
@@ -2546,14 +2546,6 @@ insert-default-directory
 `set-visited-file-name'."
   :type 'boolean)
 
-(defcustom minibuffer-beginning-of-buffer-movement nil
-  "Control how the `M-<' command in the minibuffer behaves.
-If non-nil, the command will go to the end of the prompt (if
-point is after the end of the prompt).  If nil, it will behave
-like the `beginning-of-buffer' command."
-  :version "27.1"
-  :type 'boolean)
-
 ;; Not always defined, but only called if next-read-file-uses-dialog-p says so.
 (declare-function x-file-dialog "xfns.c"
                   (prompt dir &optional default-filename mustmatch only-dir-p))
@@ -3674,8 +3666,7 @@ minibuffer-beginning-of-buffer
                         (prefix-numeric-value arg))
                      10)))
               ;; Go to the start of the buffer.
-              ((or (null minibuffer-beginning-of-buffer-movement)
-                   (<= (point) (minibuffer-prompt-end)))
+              ((<= (point) (minibuffer-prompt-end))
 	       (point-min))
               ;; Go to the end of the minibuffer.
               (t

bug#3447: suggest minibuffer M-< go to start of text

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This still doesn't work with <C-home>.  This can be fixed
> by remapping beginning-of-buffer in the patch below.
>
> Like 'C-a' goes to the end of the prompt exactly like <home>,
> there is no reason not to do the same for 'M-<' and <C-home>.

Looks good to me.

> Moreover, we don't add defcustoms for simple key bindings
> because keybinding are configured with the help of define-key.

Eli wanted the behaviour not to change by default.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3447: suggest minibuffer M-< go to start of text

[Juri Linkov]

>> This still doesn't work with <C-home>.  This can be fixed
>> by remapping beginning-of-buffer in the patch below.
>>
>> Like 'C-a' goes to the end of the prompt exactly like <home>,
>> there is no reason not to do the same for 'M-<' and <C-home>.
>
> Looks good to me.
>
>> Moreover, we don't add defcustoms for simple key bindings
>> because keybinding are configured with the help of define-key.
>
> Eli wanted the behaviour not to change by default.

Eli, do you think it would be better to change the default
because 'C-a' and <home> already go to the end of the prompt?

0.01% of users who for some unknown reasons might prefer it
to go to the beginning of the minibuffer, could easily rebind
the key back with define-key one-liner.

bug#3447: suggest minibuffer M-< go to start of text

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 13 Nov 2019 23:16:16 +0200
> Cc: 3447@debbugs.gnu.org, Kevin Ryde <user42@zip.com.au>
> 
> >> Moreover, we don't add defcustoms for simple key bindings
> >> because keybinding are configured with the help of define-key.
> >
> > Eli wanted the behaviour not to change by default.
> 
> Eli, do you think it would be better to change the default
> because 'C-a' and <home> already go to the end of the prompt?

No, because you are actually removing any way for users to go to the
beginning of the minibuffer.

> 0.01% of users who for some unknown reasons might prefer it
> to go to the beginning of the minibuffer, could easily rebind
> the key back with define-key one-liner.

Sorry, I don't believe that number has any basis.

I once agreed to changing the meaning of UP and DOWN arrows in the
minibuffer, through similar arguments, and since then not one day
passes that I don't regret that, because it drives me mad that
sometimes UP shows the previous history element and sometimes I need
to type M-p instead.  I'm very sorry, but this change, if done, will
have to be an opt-in change (and I prefer for it not to be done at
all).

bug#3447: suggest minibuffer M-< go to start of text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli, do you think it would be better to change the default
>> because 'C-a' and <home> already go to the end of the prompt?
>
> No, because you are actually removing any way for users to go to the
> beginning of the minibuffer.

Doesn't hitting `M-<' twice go to the start of the minibuffer with the
new code?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3447: suggest minibuffer M-< go to start of text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  3447@debbugs.gnu.org,  user42@zip.com.au
> Date: Fri, 15 Nov 2019 08:47:54 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Eli, do you think it would be better to change the default
> >> because 'C-a' and <home> already go to the end of the prompt?
> >
> > No, because you are actually removing any way for users to go to the
> > beginning of the minibuffer.
> 
> Doesn't hitting `M-<' twice go to the start of the minibuffer with the
> new code?

Let me rephrase: you are actually removing any way for users to go to
the beginning of the minibuffer with a single command.

bug#3447: suggest minibuffer M-< go to start of text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Let me rephrase: you are actually removing any way for users to go to
> the beginning of the minibuffer with a single command.

That's true, but we use this convention all over Emacs -- you have to
hit `C-a' twice a bunch of places to get to the start of the line.  This
is no different. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3447: suggest minibuffer M-< go to start of text

[Juri Linkov]

> Doesn't hitting `M-<' twice go to the start of the minibuffer with the
> new code?

Indeed there is no reason for `M-<' to differ from `C-a' where hitting
twice goes to the start of the line like in the message-mode header.