all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#3447: suggest minibuffer M-< go to start of text
@ 2009-06-01 23:42 Kevin Ryde
  2019-09-30  8:23 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Kevin Ryde @ 2009-06-01 23:42 UTC (permalink / raw)
  To: bug-gnu-emacs

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






^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2009-06-01 23:42 bug#3447: suggest minibuffer M-< go to start of text Kevin Ryde
@ 2019-09-30  8:23 ` Lars Ingebrigtsen
  2019-09-30  8:53   ` Eli Zaretskii
  2019-11-12 22:04   ` Juri Linkov
  0 siblings, 2 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-30  8:23 UTC (permalink / raw)
  To: Kevin Ryde; +Cc: 3447

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-09-30  8:23 ` Lars Ingebrigtsen
@ 2019-09-30  8:53   ` Eli Zaretskii
  2019-10-01 11:58     ` Lars Ingebrigtsen
  2019-11-12 22:04   ` Juri Linkov
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2019-09-30  8:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3447, user42

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-09-30  8:53   ` Eli Zaretskii
@ 2019-10-01 11:58     ` Lars Ingebrigtsen
  2019-10-01 12:28       ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-01 11:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 3447, user42

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





^ permalink raw reply related	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-10-01 11:58     ` Lars Ingebrigtsen
@ 2019-10-01 12:28       ` Eli Zaretskii
  2019-10-01 13:02         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2019-10-01 12:28 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3447, user42

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-10-01 12:28       ` Eli Zaretskii
@ 2019-10-01 13:02         ` Lars Ingebrigtsen
  2019-10-01 13:24           ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-01 13:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 3447, user42

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-10-01 13:02         ` Lars Ingebrigtsen
@ 2019-10-01 13:24           ` Eli Zaretskii
  0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2019-10-01 13:24 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3447, user42

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-09-30  8:23 ` Lars Ingebrigtsen
  2019-09-30  8:53   ` Eli Zaretskii
@ 2019-11-12 22:04   ` Juri Linkov
  2019-11-13  3:25     ` Lars Ingebrigtsen
  1 sibling, 1 reply; 15+ messages in thread
From: Juri Linkov @ 2019-11-12 22:04 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3447, Kevin Ryde

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

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-11-12 22:04   ` Juri Linkov
@ 2019-11-13  3:25     ` Lars Ingebrigtsen
  2019-11-13 21:16       ` Juri Linkov
  0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-13  3:25 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 3447, Kevin Ryde

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-11-13  3:25     ` Lars Ingebrigtsen
@ 2019-11-13 21:16       ` Juri Linkov
  2019-11-14 13:44         ` Eli Zaretskii
  0 siblings, 1 reply; 15+ messages in thread
From: Juri Linkov @ 2019-11-13 21:16 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3447, Kevin Ryde

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-11-13 21:16       ` Juri Linkov
@ 2019-11-14 13:44         ` Eli Zaretskii
  2019-11-15  7:47           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2019-11-14 13:44 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 3447, larsi, user42

> 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).





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-11-14 13:44         ` Eli Zaretskii
@ 2019-11-15  7:47           ` Lars Ingebrigtsen
  2019-11-15  8:43             ` Eli Zaretskii
  2019-11-16 20:15             ` Juri Linkov
  0 siblings, 2 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-15  7:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 3447, user42, Juri Linkov

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-11-15  7:47           ` Lars Ingebrigtsen
@ 2019-11-15  8:43             ` Eli Zaretskii
  2019-11-23 12:51               ` Lars Ingebrigtsen
  2019-11-16 20:15             ` Juri Linkov
  1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2019-11-15  8:43 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3447, user42, juri

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-11-15  7:47           ` Lars Ingebrigtsen
  2019-11-15  8:43             ` Eli Zaretskii
@ 2019-11-16 20:15             ` Juri Linkov
  1 sibling, 0 replies; 15+ messages in thread
From: Juri Linkov @ 2019-11-16 20:15 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 3447, user42

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#3447: suggest minibuffer M-< go to start of text
  2019-11-15  8:43             ` Eli Zaretskii
@ 2019-11-23 12:51               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-23 12:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 3447, user42, juri

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2019-11-23 12:51 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-01 23:42 bug#3447: suggest minibuffer M-< go to start of text Kevin Ryde
2019-09-30  8:23 ` Lars Ingebrigtsen
2019-09-30  8:53   ` Eli Zaretskii
2019-10-01 11:58     ` Lars Ingebrigtsen
2019-10-01 12:28       ` Eli Zaretskii
2019-10-01 13:02         ` Lars Ingebrigtsen
2019-10-01 13:24           ` Eli Zaretskii
2019-11-12 22:04   ` Juri Linkov
2019-11-13  3:25     ` Lars Ingebrigtsen
2019-11-13 21:16       ` Juri Linkov
2019-11-14 13:44         ` Eli Zaretskii
2019-11-15  7:47           ` Lars Ingebrigtsen
2019-11-15  8:43             ` Eli Zaretskii
2019-11-23 12:51               ` Lars Ingebrigtsen
2019-11-16 20:15             ` Juri Linkov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.