unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [PATCH] Speed up project-kill-buffers
@ 2021-05-03  9:43 Philip Kaludercic
  2021-05-03 12:46 ` Stefan Monnier
  2021-05-03 21:43 ` Dmitry Gutov
  0 siblings, 2 replies; 17+ messages in thread
From: Philip Kaludercic @ 2021-05-03  9:43 UTC (permalink / raw)
  To: emacs-devel

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


Hi,

I've noticed that sometimes project-kill-buffers is noticeably slow, and
it seems like it's has to do with project--buffer-list working on remote
files. The function goes through every buffer and calls
(project-current), even if the buffer is related to a remote file that
cannot be part of the current project.

The patch I attach below is a simple fix to avoid checking files that
cannot be part of the current project. Or are there any edge-cases that
this code approach breaks?

-- 
	Philip K.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Avoid-Tramp-buffers-when-possible.patch --]
[-- Type: text/x-diff, Size: 1246 bytes --]

From 8b45502da8281826fa2da02a317546bc99f51069 Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Mon, 3 May 2021 11:35:41 +0200
Subject: [PATCH] Avoid Tramp buffers when possible

* project.el (project--buffer-list): Add file-remote-p check
---
 lisp/progmodes/project.el | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index d47d9d77e6..33827136a1 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1120,11 +1120,14 @@ project-kill-buffer-conditions
 
 (defun project--buffer-list (pr)
   "Return the list of all buffers in project PR."
-  (let (bufs)
+  (let ((remote-project-p (file-remote-p (project-root pr)))
+        bufs)
     (dolist (buf (buffer-list))
-      (when (equal pr
-                   (with-current-buffer buf
-                     (project-current)))
+      (when (and (let ((remote (file-remote-p (buffer-local-value 'default-directory buf))))
+                   (if remote-project-p remote (not remote)))
+                 (equal pr
+                        (with-current-buffer buf
+                          (project-current))))
         (push buf bufs)))
     (nreverse bufs)))
 
-- 
2.30.2


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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03  9:43 [PATCH] Speed up project-kill-buffers Philip Kaludercic
@ 2021-05-03 12:46 ` Stefan Monnier
  2021-05-03 13:06   ` Philip Kaludercic
  2021-05-03 21:43 ` Dmitry Gutov
  1 sibling, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2021-05-03 12:46 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel

>  (defun project--buffer-list (pr)
>    "Return the list of all buffers in project PR."
> -  (let (bufs)
> +  (let ((remote-project-p (file-remote-p (project-root pr)))
> +        bufs)
>      (dolist (buf (buffer-list))
> -      (when (equal pr
> -                   (with-current-buffer buf
> -                     (project-current)))
> +      (when (and (let ((remote (file-remote-p (buffer-local-value 'default-directory buf))))
> +                   (if remote-project-p remote (not remote)))
> +                 (equal pr
> +                        (with-current-buffer buf
> +                          (project-current))))
>          (push buf bufs)))
>      (nreverse bufs)))

How 'bout using `file-in-directory-p`?


        Stefan




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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 12:46 ` Stefan Monnier
@ 2021-05-03 13:06   ` Philip Kaludercic
  2021-05-03 13:24     ` Stefan Monnier
  0 siblings, 1 reply; 17+ messages in thread
From: Philip Kaludercic @ 2021-05-03 13:06 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  (defun project--buffer-list (pr)
>>    "Return the list of all buffers in project PR."
>> -  (let (bufs)
>> +  (let ((remote-project-p (file-remote-p (project-root pr)))
>> +        bufs)
>>      (dolist (buf (buffer-list))
>> -      (when (equal pr
>> -                   (with-current-buffer buf
>> -                     (project-current)))
>> +      (when (and (let ((remote (file-remote-p (buffer-local-value 'default-directory buf))))
>> +                   (if remote-project-p remote (not remote)))
>> +                 (equal pr
>> +                        (with-current-buffer buf
>> +                          (project-current))))
>>          (push buf bufs)))
>>      (nreverse bufs)))
>
> How 'bout using `file-in-directory-p`?

I didn't know about that function! Just tried it out and it seems that
the patch below is even faster, as project-current does not have to be
invoked for every buffer, remote or not.

>         Stefan
>

-- 
	Philip K.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Reduce-number-of-method-invocations-in-project-buffe.patch --]
[-- Type: text/x-diff, Size: 1136 bytes --]

From eb9f32e1007eaa90a1b5487ac009b38182d6260b Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Mon, 3 May 2021 11:35:41 +0200
Subject: [PATCH] Reduce number of method invocations in project--buffer-list

* project.el (project--buffer-list): Use file-in-directory-p
---
 lisp/progmodes/project.el | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index d47d9d77e6..aa2fc1690f 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1120,11 +1120,12 @@ project-kill-buffer-conditions
 
 (defun project--buffer-list (pr)
   "Return the list of all buffers in project PR."
-  (let (bufs)
+  (let ((root (project-root pr))
+        bufs)
     (dolist (buf (buffer-list))
-      (when (equal pr
-                   (with-current-buffer buf
-                     (project-current)))
+      (when-let ((file (or (buffer-file-name buf)
+                           (buffer-local-value 'default-directory buf)))
+                 ((file-in-directory-p file root)))
         (push buf bufs)))
     (nreverse bufs)))
 
-- 
2.30.2


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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 13:06   ` Philip Kaludercic
@ 2021-05-03 13:24     ` Stefan Monnier
  2021-05-03 17:25       ` Philip Kaludercic
  2021-05-08 12:03       ` Stephen Leake
  0 siblings, 2 replies; 17+ messages in thread
From: Stefan Monnier @ 2021-05-03 13:24 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel

> I didn't know about that function! Just tried it out and it seems that
> the patch below is even faster, as project-current does not have to be
> invoked for every buffer, remote or not.

I think it might misbehave if you have projects nested in the directory
of other projects, tho.


        Stefan




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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 13:24     ` Stefan Monnier
@ 2021-05-03 17:25       ` Philip Kaludercic
  2021-05-03 21:12         ` Dmitry Gutov
  2021-05-08 12:03       ` Stephen Leake
  1 sibling, 1 reply; 17+ messages in thread
From: Philip Kaludercic @ 2021-05-03 17:25 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I didn't know about that function! Just tried it out and it seems that
>> the patch below is even faster, as project-current does not have to be
>> invoked for every buffer, remote or not.
>
> I think it might misbehave if you have projects nested in the directory
> of other projects, tho.

That is true, but this leads to the more general question of whether a
sub-project is part of the super-project or not? Is there any reason to
intrinsically prefer one over the other?

>         Stefan

-- 
	Philip K.



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 17:25       ` Philip Kaludercic
@ 2021-05-03 21:12         ` Dmitry Gutov
  0 siblings, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-03 21:12 UTC (permalink / raw)
  To: Philip Kaludercic, Stefan Monnier; +Cc: emacs-devel

On 03.05.2021 20:25, Philip Kaludercic wrote:
> That is true, but this leads to the more general question of whether a
> sub-project is part of the super-project or not? Is there any reason to
> intrinsically prefer one over the other?

If sub-project is part of the super-project, what makes it a separate 
project, then? If we do consider it separate, I think it makes sense to 
only kill buffers belonging to it, but not the parent. And vice versa.

Ultimately, it's a non-trivial question, and we'll probably delegate it 
to project backends as well. That will still require getting the current 
project.

We also want to support arbitrary project-finding strategies which 
dosn't depend on the parent directory (see commit 4ca13d98c9eb and the 
referenced discussion).



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03  9:43 [PATCH] Speed up project-kill-buffers Philip Kaludercic
  2021-05-03 12:46 ` Stefan Monnier
@ 2021-05-03 21:43 ` Dmitry Gutov
  2021-05-03 22:45   ` Stefan Monnier
  1 sibling, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-03 21:43 UTC (permalink / raw)
  To: Philip Kaludercic, emacs-devel

Hi Philip,

On 03.05.2021 12:43, Philip Kaludercic wrote:
> I've noticed that sometimes project-kill-buffers is noticeably slow, and
> it seems like it's has to do with project--buffer-list working on remote
> files. The function goes through every buffer and calls
> (project-current), even if the buffer is related to a remote file that
> cannot be part of the current project.
> 
> The patch I attach below is a simple fix to avoid checking files that
> cannot be part of the current project. Or are there any edge-cases that
> this code approach breaks?

In theory, files on different hosts could be part of the same "project" 
(in Eli's sense, see 
https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00051.html and 
the other messages in that thread), but we'll get there when we get 
there. Probably by adding a method like project-contains-file-p.

In the meantime (until somebody complains), the patch like this should 
be fine. I haven't found any significant difference in performance, but 
I don't have Tramp buffers in the current session.

Pushed to master, thanks.

If we do believe that a project can only span one host, we could also 
change the check like this:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 33827136a1..6f911e4fbe 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1120,11 +1120,11 @@ project-kill-buffer-conditions

  (defun project--buffer-list (pr)
    "Return the list of all buffers in project PR."
-  (let ((remote-project-p (file-remote-p (project-root pr)))
+  (let ((conn (file-remote-p (project-root pr)))
          bufs)
      (dolist (buf (buffer-list))
-      (when (and (let ((remote (file-remote-p (buffer-local-value 
'default-directory buf))))
-                   (if remote-project-p remote (not remote)))
+      (when (and (equal conn
+                        (file-remote-p (buffer-local-value 
'default-directory buf)))
                   (equal pr
                          (with-current-buffer buf
                            (project-current))))

WDYT?



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 21:43 ` Dmitry Gutov
@ 2021-05-03 22:45   ` Stefan Monnier
  2021-05-03 22:46     ` Dmitry Gutov
  0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2021-05-03 22:45 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Philip Kaludercic, emacs-devel

>> I've noticed that sometimes project-kill-buffers is noticeably slow, and
>> it seems like it's has to do with project--buffer-list working on remote
>> files. The function goes through every buffer and calls
>> (project-current), even if the buffer is related to a remote file that
>> cannot be part of the current project.
>> The patch I attach below is a simple fix to avoid checking files that
>> cannot be part of the current project. Or are there any edge-cases that
>> this code approach breaks?
>
> In theory, files on different hosts could be part of the same "project" (in
> Eli's sense, see
> https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00051.html and the
> other messages in that thread), but we'll get there when we get
> there. Probably by adding a method like project-contains-file-p.

Of course, we could also make the check super fast by keeping the
"current project" in a buffer-local var, and then just look for buffers
which have an `eq` value in that var.  That would be both faster than
`file-in-directory-p` and more arguably more correct.


        Stefan




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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 22:45   ` Stefan Monnier
@ 2021-05-03 22:46     ` Dmitry Gutov
  2021-05-04  6:25       ` tomas
  0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-03 22:46 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Philip Kaludercic, emacs-devel

On 04.05.2021 01:45, Stefan Monnier wrote:
> Of course, we could also make the check super fast by keeping the
> "current project" in a buffer-local var, and then just look for buffers
> which have an `eq` value in that var.  That would be both faster than
> `file-in-directory-p` and more arguably more correct.

Until the user changes some project setting and the "current project" 
becomes not current anymore.



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 22:46     ` Dmitry Gutov
@ 2021-05-04  6:25       ` tomas
  2021-05-04 10:40         ` Dmitry Gutov
  0 siblings, 1 reply; 17+ messages in thread
From: tomas @ 2021-05-04  6:25 UTC (permalink / raw)
  To: emacs-devel

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

On Tue, May 04, 2021 at 01:46:43AM +0300, Dmitry Gutov wrote:
> On 04.05.2021 01:45, Stefan Monnier wrote:
> >Of course, we could also make the check super fast by keeping the
> >"current project" in a buffer-local var, and then just look for buffers
> >which have an `eq` value in that var.  That would be both faster than
> >`file-in-directory-p` and more arguably more correct.
> 
> Until the user changes some project setting and the "current
> project" becomes not current anymore.

All that looks to me like a classical caching problem, with cache
invalidation protocols and things.

(Don't take me too seriously, though. I've no skin in this game).

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-04  6:25       ` tomas
@ 2021-05-04 10:40         ` Dmitry Gutov
  2021-05-04 11:26           ` tomas
  0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-04 10:40 UTC (permalink / raw)
  To: tomas, emacs-devel

On 04.05.2021 09:25, tomas@tuxteam.de wrote:
> All that looks to me like a classical caching problem, with cache
> invalidation protocols and things.

Sure. I'm just not in a hurry to add the cache if it limits possible 
applications, since the current performance seems adequate most of the time.

Better explore the applications first.



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-04 10:40         ` Dmitry Gutov
@ 2021-05-04 11:26           ` tomas
  0 siblings, 0 replies; 17+ messages in thread
From: tomas @ 2021-05-04 11:26 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: emacs-devel

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

On Tue, May 04, 2021 at 01:40:18PM +0300, Dmitry Gutov wrote:
> On 04.05.2021 09:25, tomas@tuxteam.de wrote:
> >All that looks to me like a classical caching problem [...]

> Sure. I'm just not in a hurry to add the cache if it limits possible
> applications, since the current performance seems adequate most of
> the time.
> 
> Better explore the applications first.

Makes sense, thanks :)

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-03 13:24     ` Stefan Monnier
  2021-05-03 17:25       ` Philip Kaludercic
@ 2021-05-08 12:03       ` Stephen Leake
  2021-05-08 12:30         ` Philip Kaludercic
  2021-05-08 17:10         ` Dmitry Gutov
  1 sibling, 2 replies; 17+ messages in thread
From: Stephen Leake @ 2021-05-08 12:03 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Philip Kaludercic, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I didn't know about that function! Just tried it out and it seems that
>> the patch below is even faster, as project-current does not have to be
>> invoked for every buffer, remote or not.
>
> I think it might misbehave if you have projects nested in the directory
> of other projects, tho.

There are also projects that do not have a single root; an Emacs elisp
project (which has load-path as roots), any project with dependent
external libraries.

You can check (member file (project-files prj)), but that's about the
same as your first patch.

-- 
-- Stephe



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-08 12:03       ` Stephen Leake
@ 2021-05-08 12:30         ` Philip Kaludercic
  2021-05-08 13:05           ` Philip Kaludercic
  2021-05-08 17:01           ` Dmitry Gutov
  2021-05-08 17:10         ` Dmitry Gutov
  1 sibling, 2 replies; 17+ messages in thread
From: Philip Kaludercic @ 2021-05-08 12:30 UTC (permalink / raw)
  To: Stephen Leake; +Cc: Stefan Monnier, emacs-devel

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I didn't know about that function! Just tried it out and it seems that
>>> the patch below is even faster, as project-current does not have to be
>>> invoked for every buffer, remote or not.
>>
>> I think it might misbehave if you have projects nested in the directory
>> of other projects, tho.
>
> There are also projects that do not have a single root; an Emacs elisp
> project (which has load-path as roots), any project with dependent
> external libraries.
>
> You can check (member file (project-files prj)), but that's about the
> same as your first patch.

So maybe something like 

    (let ((root (project-root proj))
          (extr (project-external-roots proj)))
      (member file (project-files proj (cons root extr))))

?

-- 
	Philip K.



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-08 12:30         ` Philip Kaludercic
@ 2021-05-08 13:05           ` Philip Kaludercic
  2021-05-08 17:01           ` Dmitry Gutov
  1 sibling, 0 replies; 17+ messages in thread
From: Philip Kaludercic @ 2021-05-08 13:05 UTC (permalink / raw)
  To: Stephen Leake; +Cc: Stefan Monnier, emacs-devel

Philip Kaludercic <philipk@posteo.net> writes:

> So maybe something like 
>
>     (let ((root (project-root proj))
>           (extr (project-external-roots proj)))
>       (member file (project-files proj (cons root extr))))

I realize that one issue here is that external roots could be shared by
multiple projects, so you wouldn't want to kill them when cleaning up
after a project even if you would want to have them listed.

> ?

-- 
	Philip K.



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-08 12:30         ` Philip Kaludercic
  2021-05-08 13:05           ` Philip Kaludercic
@ 2021-05-08 17:01           ` Dmitry Gutov
  1 sibling, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-08 17:01 UTC (permalink / raw)
  To: Philip Kaludercic, Stephen Leake; +Cc: Stefan Monnier, emacs-devel

On 08.05.2021 15:30, Philip Kaludercic wrote:
> So maybe something like
> 
>      (let ((root (project-root proj))
>            (extr (project-external-roots proj)))
>        (member file (project-files proj (cons root extr))))

I don't think you'll like the performance characteristics of this 
approach. ;-)



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

* Re: [PATCH] Speed up project-kill-buffers
  2021-05-08 12:03       ` Stephen Leake
  2021-05-08 12:30         ` Philip Kaludercic
@ 2021-05-08 17:10         ` Dmitry Gutov
  1 sibling, 0 replies; 17+ messages in thread
From: Dmitry Gutov @ 2021-05-08 17:10 UTC (permalink / raw)
  To: Stephen Leake, Stefan Monnier; +Cc: Philip Kaludercic, emacs-devel

Hi Stephen,

On 08.05.2021 15:03, Stephen Leake wrote:
> There are also projects that do not have a single root; an Emacs elisp
> project (which has load-path as roots), any project with dependent
> external libraries.

This is not really than different.

The VC backend has load-path in external roots (which can have 
counterparts in "dependency libraries" in other languages).

When we close such project, though, we usually don't want to kill any of 
the buffers belonging to external libraries (they might as well be part 
of some other project, e.g. one that the current depends on).

To support arbitrarily-shaped projects, though, we can introduce a 
method like 'project-contains-buffer?'. Which you would implement with 
'member'. The performance could be okay if your projects are small 
enough. It doesn't handle non-file-visiting buffers, though.



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

end of thread, other threads:[~2021-05-08 17:10 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-03  9:43 [PATCH] Speed up project-kill-buffers Philip Kaludercic
2021-05-03 12:46 ` Stefan Monnier
2021-05-03 13:06   ` Philip Kaludercic
2021-05-03 13:24     ` Stefan Monnier
2021-05-03 17:25       ` Philip Kaludercic
2021-05-03 21:12         ` Dmitry Gutov
2021-05-08 12:03       ` Stephen Leake
2021-05-08 12:30         ` Philip Kaludercic
2021-05-08 13:05           ` Philip Kaludercic
2021-05-08 17:01           ` Dmitry Gutov
2021-05-08 17:10         ` Dmitry Gutov
2021-05-03 21:43 ` Dmitry Gutov
2021-05-03 22:45   ` Stefan Monnier
2021-05-03 22:46     ` Dmitry Gutov
2021-05-04  6:25       ` tomas
2021-05-04 10:40         ` Dmitry Gutov
2021-05-04 11:26           ` tomas

unofficial mirror of emacs-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-devel/0 emacs-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-devel emacs-devel/ https://yhetil.org/emacs-devel \
		emacs-devel@gnu.org
	public-inbox-index emacs-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.devel
	nntp://news.gmane.io/gmane.emacs.devel


code repositories for project(s) associated with this inbox:

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

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git