* Quit and Close Emacs Special Windows
[not found] <87ftaej5pp.fsf.ref@ergus.i-did-not-set--mail-host-address--so-tickle-me>
@ 2020-06-29 14:40 ` Ergus
2020-06-29 15:09 ` Drew Adams
2020-06-30 17:04 ` Stefan Monnier
0 siblings, 2 replies; 14+ messages in thread
From: Ergus @ 2020-06-29 14:40 UTC (permalink / raw)
To: emacs-devel
Hi:
I have been reading this site:
https://christiantietze.de/posts/2019/10/emacs-quit-special-windows/
and I am wondering why we don't provide an option to enable this
behaviour by default in some cases without needing the "hack" in the
link. It doesn't seems to be too complex to implement right?
I know it is just a detail, but in some cases (like when using man or
compile mode, or reading a function documentation, or after executing
magit commands) it doesn't make sense to keep the buffer in the buffer
list after pressing q in 90% of the times.
Could we consider to add this as (for example) an option to enable it by
default OR add a customisable list with the modes where the user could
desire to have this behaviour?
Best,
Ergus
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Quit and Close Emacs Special Windows
2020-06-29 14:40 ` Quit and Close Emacs Special Windows Ergus
@ 2020-06-29 15:09 ` Drew Adams
2020-06-29 16:13 ` Yuan Fu
` (2 more replies)
2020-06-30 17:04 ` Stefan Monnier
1 sibling, 3 replies; 14+ messages in thread
From: Drew Adams @ 2020-06-29 15:09 UTC (permalink / raw)
To: Ergus, emacs-devel
> I have been reading this site:
>
> https://urldefense.com/v3/__https://christiantietze.de/posts/2019/10/emacs-
> quit-special-
> windows/__;!!GqivPVa7Brio!MYwcdeIdWpFMGgsvTIkt5Vbrg69dFCUgHqpfuyAyObkHKL7IAog
> HWMmQFaH3DjBy$
>
> and I am wondering why we don't provide an option to enable this
> behaviour by default in some cases without needing the "hack" in the
> link. It doesn't seems to be too complex to implement right?
>
> I know it is just a detail, but in some cases (like when using man or
> compile mode, or reading a function documentation, or after executing
> magit commands) it doesn't make sense to keep the buffer in the buffer
> list after pressing q in 90% of the times.
>
> Could we consider to add this as (for example) an option to enable it by
> default OR add a customisable list with the modes where the user could
> desire to have this behaviour?
FWIW, I do this:
(defun quit-window-delete (&optional kill window)
"Quit WINDOW, deleting it, and bury its buffer.
WINDOW must be a live window and defaults to the selected one.
With prefix argument KILL non-nil, kill the buffer instead of
burying it.
This is similar to the version of `quit-window' that Emacs had before
the introduction of `quit-restore-window'. It ignores the information
stored in WINDOW's `quit-restore' window parameter.
It deletes the WINDOW more often, rather than switching to another
buffer in it. If WINDOW is alone in its frame then the frame is
deleted or iconified, according to option `frame-auto-hide-function'."
(interactive "P")
(set-window-parameter
window 'quit-restore `(frame frame nil ,(current-buffer)))
(quit-restore-window window (if kill 'kill 'bury)))
(global-set-key [remap quit-window] 'quit-window-delete)
I also use dedicated windows for buffers with names `*...*',
and I make frame "hiding" delete frames rather than iconify.
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
(setq frame-auto-hide-function 'delete-frame)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-06-29 15:09 ` Drew Adams
@ 2020-06-29 16:13 ` Yuan Fu
2020-06-29 16:45 ` Ergus
2020-06-30 2:44 ` Stefan Monnier
2 siblings, 0 replies; 14+ messages in thread
From: Yuan Fu @ 2020-06-29 16:13 UTC (permalink / raw)
To: Drew Adams; +Cc: Ergus, emacs-devel
I use a similar “smart” quit function. When a special buffer pops up creating a new window, I want that window disappear when quit; but if the special buffer reused a window, I want Emacs to keep the window and restore the original buffer. Here is what I use:
(defun ghelp-close ()
"Close ghelp buffer/window."
(interactive)
(cl-loop for buffer1 in (window-prev-buffers)
for buffer = (car buffer1)
for is-ghelp = (eq 'ghelp-page-mode
(buffer-local-value
'major-mode buffer))
if (not is-ghelp)
do (switch-to-buffer buffer)
and return nil
finally (delete-window)))
Here, instead of looking for special-mode, I look for ghelp-page-mode, but the idea is the same. I look at the buffer history of the window and restore previous buffer if I can find one, if not, I delete the window.
Yuan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-06-29 15:09 ` Drew Adams
2020-06-29 16:13 ` Yuan Fu
@ 2020-06-29 16:45 ` Ergus
2020-06-29 17:00 ` Drew Adams
2020-06-30 2:44 ` Stefan Monnier
2 siblings, 1 reply; 14+ messages in thread
From: Ergus @ 2020-06-29 16:45 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel
On Mon, Jun 29, 2020 at 03:09:59PM +0000, Drew Adams wrote:
Hi Drew:
1) Should we provide a custom variable to conditionally enable the
set-window-parameter part of your code within quit-window?
2) I am not very trained in lisp, so I must ask if you think that this
changes is general enough for all the buffers like: Help, man, Compile,
magit etc?? and won't conflict with others?
if 1 && 2): as this is your code, could you please add the changes if
nobody has any concern about it?
Best and thanks,
Ergus
>
>FWIW, I do this:
>
>(defun quit-window-delete (&optional kill window)
> "Quit WINDOW, deleting it, and bury its buffer.
>WINDOW must be a live window and defaults to the selected one.
>With prefix argument KILL non-nil, kill the buffer instead of
>burying it.
>
>This is similar to the version of `quit-window' that Emacs had before
>the introduction of `quit-restore-window'. It ignores the information
>stored in WINDOW's `quit-restore' window parameter.
>
>It deletes the WINDOW more often, rather than switching to another
>buffer in it. If WINDOW is alone in its frame then the frame is
>deleted or iconified, according to option `frame-auto-hide-function'."
> (interactive "P")
> (set-window-parameter
> window 'quit-restore `(frame frame nil ,(current-buffer)))
> (quit-restore-window window (if kill 'kill 'bury)))
>
>(global-set-key [remap quit-window] 'quit-window-delete)
>
>I also use dedicated windows for buffers with names `*...*',
>and I make frame "hiding" delete frames rather than iconify.
>
>(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
>(setq frame-auto-hide-function 'delete-frame)
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Quit and Close Emacs Special Windows
2020-06-29 16:45 ` Ergus
@ 2020-06-29 17:00 ` Drew Adams
2020-06-29 17:22 ` Ergus
0 siblings, 1 reply; 14+ messages in thread
From: Drew Adams @ 2020-06-29 17:00 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel
Hi Ergus
> >FWIW, I do this:
> >
> >(defun quit-window-delete (&optional kill window)
> > "Quit WINDOW, deleting it, and bury its buffer.
> >WINDOW must be a live window and defaults to the selected one.
> >With prefix argument KILL non-nil, kill the buffer instead of
> >burying it.
> >
> >This is similar to the version of `quit-window' that Emacs had before
> >the introduction of `quit-restore-window'. It ignores the information
> >stored in WINDOW's `quit-restore' window parameter.
> >
> >It deletes the WINDOW more often, rather than switching to another
> >buffer in it. If WINDOW is alone in its frame then the frame is
> >deleted or iconified, according to option `frame-auto-hide-function'."
> > (interactive "P")
> > (set-window-parameter
> > window 'quit-restore `(frame frame nil ,(current-buffer)))
> > (quit-restore-window window (if kill 'kill 'bury)))
> >
> >(global-set-key [remap quit-window] 'quit-window-delete)
> >
> >I also use dedicated windows for buffers with names `*...*',
> >and I make frame "hiding" delete frames rather than iconify.
> >
> >(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
> >(setq frame-auto-hide-function 'delete-frame)
>
>
> 1) Should we provide a custom variable to conditionally enable the
> set-window-parameter part of your code within quit-window?
>
> 2) I am not very trained in lisp, so I must ask if you think that
> this changes is general enough for all the buffers like: Help,
> man, Compile, magit etc?? and won't conflict with others?
>
> if 1 && 2): as this is your code, could you please add the
> changes if nobody has any concern about it?
No idea; sorry. I'm just saying what I do.
The definition of `quit-window-delete' that I use
has this comment:
;; Candidate as a replacement for `quit-window',
;; at least when used interactively. For example:
;; (define-key global-map [remap quit-window] 'quit-window-delete)
;;
;; Thanks to Martin Rudalics for suggestions.
Someone else will need to make changes to Emacs, if
such is decided.
The things I mentioned don't necessarily belong
together for others. For me they make sense together.
For example, making buffers `*...*' special-display
is unrelated to quitting help buffers with `q'.
But for me it makes sense. I show all such buffers
in their own dedicated window (frame, in fact), and
when I use `q' to quit the buffer I want to delete
the frame. I imagine that at least some others won't
want such behavior.
Do I think that it would be good to have a simple way
to get `q' to delete the window? Yes. Do I think it
would be good to have a simple way for `q' to delete
a one-window frame? Yes. But someone else will need
to think about and decide whether that's helpful in
general and, if so, what's the best way to offer it.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-06-29 17:00 ` Drew Adams
@ 2020-06-29 17:22 ` Ergus
0 siblings, 0 replies; 14+ messages in thread
From: Ergus @ 2020-06-29 17:22 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel
On Mon, Jun 29, 2020 at 05:00:01PM +0000, Drew Adams wrote:
>
>No idea; sorry. I'm just saying what I do.
>
>The definition of `quit-window-delete' that I use
>has this comment:
>
> ;; Candidate as a replacement for `quit-window',
> ;; at least when used interactively. For example:
> ;; (define-key global-map [remap quit-window] 'quit-window-delete)
> ;;
> ;; Thanks to Martin Rudalics for suggestions.
>
>Someone else will need to make changes to Emacs, if
>such is decided.
>
>The things I mentioned don't necessarily belong
>together for others. For me they make sense together.
>
>For example, making buffers `*...*' special-display
>is unrelated to quitting help buffers with `q'.
>
I tried your code for making buffers `*...*' special-display and as I
only use -nw the behavior is not good. The first time I call commands
like `man' nothing happens in the front but the buffer starts in the
backend.
In gui the behavior is fine as expected.
>But for me it makes sense. I show all such buffers
>in their own dedicated window (frame, in fact), and
>when I use `q' to quit the buffer I want to delete
>the frame. I imagine that at least some others won't
>want such behavior.
>
>Do I think that it would be good to have a simple way
>to get `q' to delete the window? Yes. Do I think it
>would be good to have a simple way for `q' to delete
>a one-window frame? Yes. But someone else will need
>to think about and decide whether that's helpful in
>general and, if so, what's the best way to offer it.
I think that with a simple variable and an `or` in the condition will be
good enough (something like quit-always-kill or so).
The only corned case I can imagine so far is the case where quit-window
is not called from `q' in not *...* buffers. But I don't know if that
even happen.
Hopefully someone will come with a better solution...
Best,
Ergus.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-06-29 15:09 ` Drew Adams
2020-06-29 16:13 ` Yuan Fu
2020-06-29 16:45 ` Ergus
@ 2020-06-30 2:44 ` Stefan Monnier
2020-06-30 3:24 ` Drew Adams
2 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2020-06-30 2:44 UTC (permalink / raw)
To: Drew Adams; +Cc: Ergus, emacs-devel
Hi Drew,
What does this have to do with Ergus's message?
[ Except that they both mention windows and buffers. ]
Stefan
Drew Adams [2020-06-29 15:09:59] wrote:
>> I have been reading this site:
>>
>> https://urldefense.com/v3/__https://christiantietze.de/posts/2019/10/emacs-
>> quit-special-
>> windows/__;!!GqivPVa7Brio!MYwcdeIdWpFMGgsvTIkt5Vbrg69dFCUgHqpfuyAyObkHKL7IAog
>> HWMmQFaH3DjBy$
>>
>> and I am wondering why we don't provide an option to enable this
>> behaviour by default in some cases without needing the "hack" in the
>> link. It doesn't seems to be too complex to implement right?
>>
>> I know it is just a detail, but in some cases (like when using man or
>> compile mode, or reading a function documentation, or after executing
>> magit commands) it doesn't make sense to keep the buffer in the buffer
>> list after pressing q in 90% of the times.
>>
>> Could we consider to add this as (for example) an option to enable it by
>> default OR add a customisable list with the modes where the user could
>> desire to have this behaviour?
>
> FWIW, I do this:
>
> (defun quit-window-delete (&optional kill window)
> "Quit WINDOW, deleting it, and bury its buffer.
> WINDOW must be a live window and defaults to the selected one.
> With prefix argument KILL non-nil, kill the buffer instead of
> burying it.
>
> This is similar to the version of `quit-window' that Emacs had before
> the introduction of `quit-restore-window'. It ignores the information
> stored in WINDOW's `quit-restore' window parameter.
>
> It deletes the WINDOW more often, rather than switching to another
> buffer in it. If WINDOW is alone in its frame then the frame is
> deleted or iconified, according to option `frame-auto-hide-function'."
> (interactive "P")
> (set-window-parameter
> window 'quit-restore `(frame frame nil ,(current-buffer)))
> (quit-restore-window window (if kill 'kill 'bury)))
>
> (global-set-key [remap quit-window] 'quit-window-delete)
>
> I also use dedicated windows for buffers with names `*...*',
> and I make frame "hiding" delete frames rather than iconify.
>
> (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
> (setq frame-auto-hide-function 'delete-frame)
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Quit and Close Emacs Special Windows
2020-06-30 2:44 ` Stefan Monnier
@ 2020-06-30 3:24 ` Drew Adams
2020-06-30 4:27 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Drew Adams @ 2020-06-30 3:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Ergus, emacs-devel
> What does this have to do with Ergus's message?
> [ Except that they both mention windows and buffers. ]
If it doesn't, please ignore. I thought it did
(and I thought Ergus thought so too). Sorry if
I was mistaken.
I thought he was asking about having `q' in such
buffers delete the window more often, instead of
preferring to restore some other buffer in it.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-06-30 3:24 ` Drew Adams
@ 2020-06-30 4:27 ` Stefan Monnier
2020-06-30 15:39 ` Drew Adams
0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2020-06-30 4:27 UTC (permalink / raw)
To: Drew Adams; +Cc: Ergus, emacs-devel
> If it doesn't, please ignore. I thought it did
> (and I thought Ergus thought so too). Sorry if
> I was mistaken.
>
> I thought he was asking about having `q' in such
> buffers delete the window more often, instead of
> preferring to restore some other buffer in it.
Maybe it does have to do with it, I don't know.
There's much too much implicit in those messages.
Please clarify.
E.g. Ergus says:
I know it is just a detail, but in some cases (like when using man or
compile mode, or reading a function documentation, or after executing
magit commands) it doesn't make sense to keep the buffer in the buffer
list after pressing q in 90% of the times.
so to me it seems like this doesn't have to do with whether windows get
deleted but with whether buffers are kept (maybe at all, or maybe only
in the buffer lists).
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Quit and Close Emacs Special Windows
2020-06-30 4:27 ` Stefan Monnier
@ 2020-06-30 15:39 ` Drew Adams
0 siblings, 0 replies; 14+ messages in thread
From: Drew Adams @ 2020-06-30 15:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Ergus, emacs-devel
> > If it doesn't, please ignore. I thought it did
> > (and I thought Ergus thought so too). Sorry if
> > I was mistaken.
> >
> > I thought he was asking about having `q' in such
> > buffers delete the window more often, instead of
> > preferring to restore some other buffer in it.
>
> Maybe it does have to do with it, I don't know.
> There's much too much implicit in those messages.
> Please clarify.
>
> E.g. Ergus says:
>
> I know it is just a detail, but in some cases (like when using man or
> compile mode, or reading a function documentation, or after executing
> magit commands) it doesn't make sense to keep the buffer in the buffer
> list after pressing q in 90% of the times.
>
> so to me it seems like this doesn't have to do with whether windows get
> deleted but with whether buffers are kept (maybe at all, or maybe only
> in the buffer lists).
Yes, I saw that too. But the overall question
seemed to me to be about deleting the window.
And that was the point of the blog he linked
to, which he said does what he wants. The blog
title is "Quit and Close Emacs Special Windows
Like Help and Compilation Results".
I agree that the original problem to be solved
wasn't specified too clearly.
I notice (in various places) that some users say
"buffer" when they really mean "window" - it's
pretty common on emacs.SE, for instance.
Anyway, you understand my (mis?)interpretation
of the question now, and thus my response. If
my response was off-topic, sorry about that.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-06-29 14:40 ` Quit and Close Emacs Special Windows Ergus
2020-06-29 15:09 ` Drew Adams
@ 2020-06-30 17:04 ` Stefan Monnier
2020-07-01 1:31 ` Ergus
1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2020-06-30 17:04 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel
> I have been reading this site:
>
> https://christiantietze.de/posts/2019/10/emacs-quit-special-windows/
>
> and I am wondering why we don't provide an option to enable this
> behaviour by default in some cases without needing the "hack" in the
> link. It doesn't seems to be too complex to implement right?
What do you mean by "this behavior"?
I just tried
emacs -Q
M-x compile
..select the compilation window...
q
and sure enough I was back to a single-window setup.
So, IIUC we already provide "this behavior".
> I know it is just a detail, but in some cases (like when using man or
> compile mode, or reading a function documentation, or after executing
> magit commands) it doesn't make sense to keep the buffer in the buffer
> list after pressing q in 90% of the times.
I don't understand the connection with the previous paragraph.
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-06-30 17:04 ` Stefan Monnier
@ 2020-07-01 1:31 ` Ergus
2020-07-01 3:47 ` Yuan Fu
2020-07-01 13:55 ` Drew Adams
0 siblings, 2 replies; 14+ messages in thread
From: Ergus @ 2020-07-01 1:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
Hi Stefan:
As "this behavior" I mean that pressing q effectively closes the buffer instead of keeping it around in the buffer list. When working in big projects with too many files usually there are too many *-...-* buffers (magit, compile, man, logs...). And the user needs to keep closing them constantly (with C-u q or explicitly)
This is not only annoying some times (for example for rotating buffers with C-x right) but also is somehow unnatural for term users who are used to call ex. man from the terminal and quit quickly to continue.
On June 30, 2020 7:04:57 PM GMT+02:00, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I have been reading this site:
>>
>> https://christiantietze.de/posts/2019/10/emacs-quit-special-windows/
>>
>> and I am wondering why we don't provide an option to enable this
>> behaviour by default in some cases without needing the "hack" in the
>> link. It doesn't seems to be too complex to implement right?
>
>What do you mean by "this behavior"?
>
>I just tried
>
> emacs -Q
> M-x compile
> ..select the compilation window...
> q
>
>and sure enough I was back to a single-window setup.
>So, IIUC we already provide "this behavior".
>
>> I know it is just a detail, but in some cases (like when using man or
>> compile mode, or reading a function documentation, or after executing
>> magit commands) it doesn't make sense to keep the buffer in the
>buffer
>> list after pressing q in 90% of the times.
>
>I don't understand the connection with the previous paragraph.
>
>
> Stefan
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2273 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Quit and Close Emacs Special Windows
2020-07-01 1:31 ` Ergus
@ 2020-07-01 3:47 ` Yuan Fu
2020-07-01 13:55 ` Drew Adams
1 sibling, 0 replies; 14+ messages in thread
From: Yuan Fu @ 2020-07-01 3:47 UTC (permalink / raw)
To: Ergus; +Cc: Stefan Monnier, emacs-devel
> On Jun 30, 2020, at 9:31 PM, Ergus <spacibba@aol.com> wrote:
>
> Hi Stefan:
>
> As "this behavior" I mean that pressing q effectively closes the buffer instead of keeping it around in the buffer list. When working in big projects with too many files usually there are too many *-...-* buffers (magit, compile, man, logs...). And the user needs to keep closing them constantly (with C-u q or explicitly)
> This is not only annoying some times (for example for rotating buffers with C-x right) but also is somehow unnatural for term users who are used to call ex. man from the terminal and quit quickly to continue.
For that you might want to consider M-x clean-buffer-list.
Yuan
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Quit and Close Emacs Special Windows
2020-07-01 1:31 ` Ergus
2020-07-01 3:47 ` Yuan Fu
@ 2020-07-01 13:55 ` Drew Adams
1 sibling, 0 replies; 14+ messages in thread
From: Drew Adams @ 2020-07-01 13:55 UTC (permalink / raw)
To: Ergus, Stefan Monnier; +Cc: emacs-devel
> As "this behavior" I mean that pressing q
> effectively closes the buffer instead of keeping
> it around in the buffer list. When working in
> big projects with too many files usually there
> are too many *-...-* buffers (magit, compile,
> man, logs...).
>
> And the user needs to keep closing them
> constantly (with C-u q or explicitly)
OK, so Stefan was right. This is about not only
deleting the window but also killing the buffer.
I don't think you ever mentioned `C-u' with `q'
before (but I could be mistaken). I thought you
were only interested in deleting the window.
The code I showed was only about deleting the
window.
(FWIW, the Emacs jargon uses "kill" a buffer and
"delete" a window, not "close" a buffer.)
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-07-01 13:55 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87ftaej5pp.fsf.ref@ergus.i-did-not-set--mail-host-address--so-tickle-me>
2020-06-29 14:40 ` Quit and Close Emacs Special Windows Ergus
2020-06-29 15:09 ` Drew Adams
2020-06-29 16:13 ` Yuan Fu
2020-06-29 16:45 ` Ergus
2020-06-29 17:00 ` Drew Adams
2020-06-29 17:22 ` Ergus
2020-06-30 2:44 ` Stefan Monnier
2020-06-30 3:24 ` Drew Adams
2020-06-30 4:27 ` Stefan Monnier
2020-06-30 15:39 ` Drew Adams
2020-06-30 17:04 ` Stefan Monnier
2020-07-01 1:31 ` Ergus
2020-07-01 3:47 ` Yuan Fu
2020-07-01 13:55 ` Drew Adams
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).