all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
@ 2024-01-29 18:49 Spencer Baugh
  2024-01-30 17:28 ` Juri Linkov
  0 siblings, 1 reply; 10+ messages in thread
From: Spencer Baugh @ 2024-01-29 18:49 UTC (permalink / raw)
  To: 68801; +Cc: Juri Linkov


1. emacs -Q
2. In scratch:
(current- M-<tab>
3. Observe *Completions* pops up.
4. RET
5. *Completions* goes away and a newline is inserted.

Compare:

1. emacs -Q --eval '(setq minibuffer-visible-completions t)'
2. In scratch:
(current- M-<tab>
3. Observe *Completions* pops up.
4. RET
5. *Completions* goes away but no newline is inserted, and "No match" is
   printed.

I think the behavior with minibuffer-visible-completions=t is
unintuitive.  And it just duplicates what you can achieve with C-g
(closes *Completions*), so it's not very useful.

Even if I do:
(current- M-<tab> buf RET

which is sufficient to uniquely identify current-buffer, RET does not
complete to current-buffer, instead it just says "No match".

With minibuffer-visible-completions=t, I suggest RET with no completion
selected in completion-in-region should exit completion and insert a
newline.

Or maybe, slightly more radically, RET with no completion selected in
completion-in-region should select the first matching completion given
the current completion region?  At least one user expected that
behavior.

Another alternative is that RET doesn't close *Completions* at all,
which would match minibuffer behavior better.  I'm not a huge fan of
that, but it's more useful than the current behavior of RET.

Since there are a few alternatives, perhaps we could have a defcustom
for the RET behavior in completion-in-region.  I think the default
should be closing *Completions* and inserting a newline, since that
matches minibuffer-visible-completions=nil.

If this sounds reasonable I can write a patch implementing these.


In GNU Emacs 30.0.50 (build 24, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2024-01-29 built on
 igm-qws-u22796a Repository revision:
 cbc8bdc1386a4bc9c420d8ab06b844c6f6928c35 Repository branch: master
 Windowing system distributor 'The X.Org Foundation', version
 11.0.12011000 System Description: Rocky Linux 8.9 (Green Obsidian)

Configured using:
 'configure -C 'CFLAGS=-O0 -g3' --with-gif=ifavailable
 --with-x-toolkit=lucid'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr dabbrev emacsbug message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty move-toolbar make-network-process emacs)

Memory information:
((conses 16 65716 19738) (symbols 48 9598 0) (strings 32 22938 2513)
 (string-bytes 1 684815) (vectors 16 9358)
 (vector-slots 8 112024 10425) (floats 8 42 15) (intervals 56 264 0)
 (buffers 976 10))





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-01-29 18:49 bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected Spencer Baugh
@ 2024-01-30 17:28 ` Juri Linkov
  2024-01-30 20:21   ` Spencer Baugh
  0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2024-01-30 17:28 UTC (permalink / raw)
  To: Spencer Baugh; +Cc: 68801

> Since there are a few alternatives, perhaps we could have a defcustom
> for the RET behavior in completion-in-region.  I think the default
> should be closing *Completions* and inserting a newline, since that
> matches minibuffer-visible-completions=nil.
>
> If this sounds reasonable I can write a patch implementing these.

Sorry, I have no opinion - this is such a gray area, I never tried
to type RET with an unselected completion candidate.

But at least the current behavior makes sense since it's like
in Isearch mode where RET just exits Isearch, whereas some other
keys exit Isearch and do their usual job.





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-01-30 17:28 ` Juri Linkov
@ 2024-01-30 20:21   ` Spencer Baugh
  2024-01-31  7:58     ` Juri Linkov
  0 siblings, 1 reply; 10+ messages in thread
From: Spencer Baugh @ 2024-01-30 20:21 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 68801

Juri Linkov <juri@linkov.net> writes:
>> Since there are a few alternatives, perhaps we could have a defcustom
>> for the RET behavior in completion-in-region.  I think the default
>> should be closing *Completions* and inserting a newline, since that
>> matches minibuffer-visible-completions=nil.
>>
>> If this sounds reasonable I can write a patch implementing these.
>
> Sorry, I have no opinion - this is such a gray area, I never tried
> to type RET with an unselected completion candidate.
>
> But at least the current behavior makes sense since it's like
> in Isearch mode where RET just exits Isearch, whereas some other
> keys exit Isearch and do their usual job.

Fair.  So that may make sense as an optional behavior.

Still, I think the behavior of completion-in-region with
minibuffer-visible-completions=nil is more relevant, and the default
should match that.

Here's a simple patch: What if minibuffer-visible-completions just only
overrides RET when there's a selected completion?  See below.  Could
this make sense?

In general, now RET with minibuffer-visible-completions=t will do
whatever RET did when minibuffer-visible-completions=nil, except that
when there's a selected completion RET will choose it.  That seems
simple and easy to understand to me.

(Really, I think something like this behavior for RET could be made the
default, even when minibuffer-visible-completions=nil)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 45aab398078..688018fd07f 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3161,7 +3161,7 @@ minibuffer-visible-completions
   :type 'boolean
   :version "30.1")
 
-(defun minibuffer-visible-completions-bind (binding)
+(defun minibuffer-visible-completions-bind (binding &optional require-selected)
   "Use BINDING when completions are visible.
 Return an item that is enabled only when a window
 displaying the *Completions* buffer exists."
@@ -3169,9 +3169,13 @@ minibuffer-visible-completions-bind
     "" ,binding
     :filter ,(lambda (cmd)
                (when-let ((window (get-buffer-window "*Completions*" 0)))
-                 (when (eq (buffer-local-value 'completion-reference-buffer
-                                               (window-buffer window))
-                           (window-buffer (active-minibuffer-window)))
+                 (when (and (eq (buffer-local-value 'completion-reference-buffer
+                                                    (window-buffer window))
+                                (window-buffer (active-minibuffer-window)))
+                            (if require-selected
+                                (with-current-buffer (window-buffer window)
+                                  (get-text-property (point) 'completion--string))
+                              t))
                    cmd)))))
 
 (defvar-keymap minibuffer-visible-completions-map
@@ -3180,7 +3184,7 @@ minibuffer-visible-completions-map
   "<right>" (minibuffer-visible-completions-bind #'minibuffer-next-completion)
   "<up>"    (minibuffer-visible-completions-bind #'minibuffer-previous-line-completion)
   "<down>"  (minibuffer-visible-completions-bind #'minibuffer-next-line-completion)
-  "RET"     (minibuffer-visible-completions-bind #'minibuffer-choose-completion-or-exit)
+  "RET"     (minibuffer-visible-completions-bind #'minibuffer-choose-completion-or-exit t)
   "C-g"     (minibuffer-visible-completions-bind #'minibuffer-hide-completions))
 \f
 ;;; Completion tables.





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-01-30 20:21   ` Spencer Baugh
@ 2024-01-31  7:58     ` Juri Linkov
  2024-02-09  7:17       ` Juri Linkov
  0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2024-01-31  7:58 UTC (permalink / raw)
  To: Spencer Baugh; +Cc: 68801

> Here's a simple patch: What if minibuffer-visible-completions just only
> overrides RET when there's a selected completion?  See below.  Could
> this make sense?

Yes, this makes sense.  I'll try your patch for a while.

> (Really, I think something like this behavior for RET could be made the
> default, even when minibuffer-visible-completions=nil)

I don't understand what would this mean for minibuffer-visible-completions=nil.





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-01-31  7:58     ` Juri Linkov
@ 2024-02-09  7:17       ` Juri Linkov
  2024-02-10 18:14         ` sbaugh
  0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2024-02-09  7:17 UTC (permalink / raw)
  To: Spencer Baugh; +Cc: 68801

>> Here's a simple patch: What if minibuffer-visible-completions just only
>> overrides RET when there's a selected completion?  See below.  Could
>> this make sense?
>
> Yes, this makes sense.  I'll try your patch for a while.

Thanks for the patch, it works nicely.

Could you please write a commit message for this patch.





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-02-09  7:17       ` Juri Linkov
@ 2024-02-10 18:14         ` sbaugh
  2024-02-11 17:59           ` Juri Linkov
  0 siblings, 1 reply; 10+ messages in thread
From: sbaugh @ 2024-02-10 18:14 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 68801, Spencer Baugh

Juri Linkov <juri@linkov.net> writes:
>>> Here's a simple patch: What if minibuffer-visible-completions just only
>>> overrides RET when there's a selected completion?  See below.  Could
>>> this make sense?
>>
>> Yes, this makes sense.  I'll try your patch for a while.
>
> Thanks for the patch, it works nicely.
>
> Could you please write a commit message for this patch.

The annoying thing is that this breaks the enhancement to
completion-show-help I recently made.  When a completion is not
selected, RET isn't bound, so the help shows "Click or type M-x
minibuffer-choose-completion-or-exit on a completion to select it."

I'm not sure the right way to fix that.  Selectively binding RET based
on whether a completion is selected feels sketchy anyway, it may confuse
users because e.g. C-h c RET won't work.

Maybe instead we should always bind RET, but if no completion is
selected, we run the command that RET was bound to before
completion-in-region-mode started?

Alternatively... as a completely separate point, I'd like
completion-in-region to select the first completion candidate by
default.  I think that's useful in some cases and, for
completion-in-region, doesn't have any negatives: we couldn't do it in
the minibuffer because it would interfere with accepting the default,
but there are no defaults in completion-in-region.

If we make c-i-r select the first completion candidate by default, that
would both:

- Make the completion-show-help help render correctly with the "only
  override RET when there's a selected completion" patch.

- Partially mitigate the RET issue all on its own

Wdyt?





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-02-10 18:14         ` sbaugh
@ 2024-02-11 17:59           ` Juri Linkov
  2024-02-11 21:02             ` sbaugh
  0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2024-02-11 17:59 UTC (permalink / raw)
  To: sbaugh; +Cc: 68801, Spencer Baugh

> The annoying thing is that this breaks the enhancement to
> completion-show-help I recently made.  When a completion is not
> selected, RET isn't bound, so the help shows "Click or type M-x
> minibuffer-choose-completion-or-exit on a completion to select it."
>
> I'm not sure the right way to fix that.  Selectively binding RET based
> on whether a completion is selected feels sketchy anyway, it may confuse
> users because e.g. C-h c RET won't work.
>
> Maybe instead we should always bind RET, but if no completion is
> selected, we run the command that RET was bound to before
> completion-in-region-mode started?

Then 'minibuffer-choose-completion-or-exit' could be more smart
to run whatever command was bound to RET initially, instead of
using the hard-coded 'minibuffer-complete-and-exit'.
But this might require juggling with keymaps.

> Alternatively... as a completely separate point, I'd like
> completion-in-region to select the first completion candidate by
> default.  I think that's useful in some cases and, for
> completion-in-region, doesn't have any negatives: we couldn't do it in
> the minibuffer because it would interfere with accepting the default,
> but there are no defaults in completion-in-region.
>
> If we make c-i-r select the first completion candidate by default, that
> would both:
>
> - Make the completion-show-help help render correctly with the "only
>   override RET when there's a selected completion" patch.
>
> - Partially mitigate the RET issue all on its own

Calling 'first-completion' makes sense even for the minibuffer,
at least optionally.





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-02-11 17:59           ` Juri Linkov
@ 2024-02-11 21:02             ` sbaugh
  2024-02-16 14:34               ` Spencer Baugh
  0 siblings, 1 reply; 10+ messages in thread
From: sbaugh @ 2024-02-11 21:02 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 68801, Spencer Baugh

Juri Linkov <juri@linkov.net> writes:

>> The annoying thing is that this breaks the enhancement to
>> completion-show-help I recently made.  When a completion is not
>> selected, RET isn't bound, so the help shows "Click or type M-x
>> minibuffer-choose-completion-or-exit on a completion to select it."
>>
>> I'm not sure the right way to fix that.  Selectively binding RET based
>> on whether a completion is selected feels sketchy anyway, it may confuse
>> users because e.g. C-h c RET won't work.
>>
>> Maybe instead we should always bind RET, but if no completion is
>> selected, we run the command that RET was bound to before
>> completion-in-region-mode started?
>
> Then 'minibuffer-choose-completion-or-exit' could be more smart
> to run whatever command was bound to RET initially, instead of
> using the hard-coded 'minibuffer-complete-and-exit'.
> But this might require juggling with keymaps.

Indeed, tricky.  And since minibuffer-choose-completion-or-exit could be
bound to other keys, not just RET, we shouldn't hardcode it to run what
was bound to RET, too - it should run whatever it replaced.

Maybe if there's no completion selected, it could push this-command-keys
back on to unread-command-events, then disable
completion-in-region-mode?  Then Emacs would just do key lookup again
for us.

>> Alternatively... as a completely separate point, I'd like
>> completion-in-region to select the first completion candidate by
>> default.  I think that's useful in some cases and, for
>> completion-in-region, doesn't have any negatives: we couldn't do it in
>> the minibuffer because it would interfere with accepting the default,
>> but there are no defaults in completion-in-region.
>>
>> If we make c-i-r select the first completion candidate by default, that
>> would both:
>>
>> - Make the completion-show-help help render correctly with the "only
>>   override RET when there's a selected completion" patch.
>>
>> - Partially mitigate the RET issue all on its own
>
> Calling 'first-completion' makes sense even for the minibuffer,
> at least optionally.

What about this simple patch?

If minibuffer-visible-completions=nil, it just calls first-completion.
This doesn't meaningfully change anything, since previously M-RET would
just no-op in that situation.  And it's actually quite useful, because
it makes M-RET useful without having to ever actually do M-<down>; one
can just type text to narrow the completions and then hit M-RET.  Which
is sometimes nice.

If minibuffer-visible-completions=t, it calls first-completion only when
there's no minibuffer-default; that way a simple RET will still select
the minibuffer default.

diff --git a/lisp/simple.el b/lisp/simple.el
index 8246b9cab81..715ab672655 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -10355,7 +10355,10 @@ completion-setup-function
                      "Type \\[minibuffer-choose-completion] on a completion to select it.\n")))
           (insert (substitute-command-keys
 		   "Type \\[minibuffer-next-completion] or \\[minibuffer-previous-completion] \
-to move point between completions.\n\n")))))))
+to move point between completions.\n\n"))))
+      (unless (and minibuffer-visible-completions minibuffer-default)
+        (with-minibuffer-completions-window
+          (first-completion))))))
 
 (add-hook 'completion-setup-hook #'completion-setup-function)
 





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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-02-11 21:02             ` sbaugh
@ 2024-02-16 14:34               ` Spencer Baugh
  2024-02-18  7:46                 ` Juri Linkov
  0 siblings, 1 reply; 10+ messages in thread
From: Spencer Baugh @ 2024-02-16 14:34 UTC (permalink / raw)
  To: sbaugh; +Cc: 68801, Juri Linkov

sbaugh@catern.com writes:
>>> Alternatively... as a completely separate point, I'd like
>>> completion-in-region to select the first completion candidate by
>>> default.  I think that's useful in some cases and, for
>>> completion-in-region, doesn't have any negatives: we couldn't do it in
>>> the minibuffer because it would interfere with accepting the default,
>>> but there are no defaults in completion-in-region.
>>>
>>> If we make c-i-r select the first completion candidate by default, that
>>> would both:
>>>
>>> - Make the completion-show-help help render correctly with the "only
>>>   override RET when there's a selected completion" patch.
>>>
>>> - Partially mitigate the RET issue all on its own
>>
>> Calling 'first-completion' makes sense even for the minibuffer,
>> at least optionally.
>
> What about this simple patch?
>
> If minibuffer-visible-completions=nil, it just calls first-completion.
> This doesn't meaningfully change anything, since previously M-RET would
> just no-op in that situation.  And it's actually quite useful, because
> it makes M-RET useful without having to ever actually do M-<down>; one
> can just type text to narrow the completions and then hit M-RET.  Which
> is sometimes nice.
>
> If minibuffer-visible-completions=t, it calls first-completion only when
> there's no minibuffer-default; that way a simple RET will still select
> the minibuffer default.
>
> diff --git a/lisp/simple.el b/lisp/simple.el
> index 8246b9cab81..715ab672655 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -10355,7 +10355,10 @@ completion-setup-function
>                       "Type \\[minibuffer-choose-completion] on a completion to select it.\n")))
>            (insert (substitute-command-keys
>  		   "Type \\[minibuffer-next-completion] or \\[minibuffer-previous-completion] \
> -to move point between completions.\n\n")))))))
> +to move point between completions.\n\n"))))
> +      (unless (and minibuffer-visible-completions minibuffer-default)
> +        (with-minibuffer-completions-window
> +          (first-completion))))))
>  
>  (add-hook 'completion-setup-hook #'completion-setup-function)
>  

I found selecting first-completion in the minibuffer to be annoying, so
now I'm trying with the following instead (which also fixes the
highlight to actually be shown):

(defun minibuffer-cir-first-completion ()
  "Move point to the first completion in the *Completions* window."
  (when completion-in-region-mode
    (with-selected-window (get-buffer-window standard-output 0)
      (when completions-highlight-face
        (setq-local cursor-face-highlight-nonselected-window t))
      (first-completion))))
(add-hook 'completion-setup-hook #'minibuffer-cir-first-completion 90)






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

* bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected
  2024-02-16 14:34               ` Spencer Baugh
@ 2024-02-18  7:46                 ` Juri Linkov
  0 siblings, 0 replies; 10+ messages in thread
From: Juri Linkov @ 2024-02-18  7:46 UTC (permalink / raw)
  To: Spencer Baugh; +Cc: 68801, sbaugh

> I found selecting first-completion in the minibuffer to be annoying, so
> now I'm trying with the following instead (which also fixes the
> highlight to actually be shown):
>
> (defun minibuffer-cir-first-completion ()
>   "Move point to the first completion in the *Completions* window."
>   (when completion-in-region-mode
>     (with-selected-window (get-buffer-window standard-output 0)
>       (when completions-highlight-face
>         (setq-local cursor-face-highlight-nonselected-window t))
>       (first-completion))))
> (add-hook 'completion-setup-hook #'minibuffer-cir-first-completion 90)

I noticed the problem with highlighting in your previous patch too.
Although I'm not sure why 'first-completion' didn't update
the highlighting in your previous patch.  'completion-setup-function'
enables 'completions-highlight':

      ;; Maybe enable cursor completions-highlight.
      (when completions-highlight-face
        (cursor-face-highlight-mode 1))

before you called 'first-completion' at the end of 'completion-setup-function'.





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

end of thread, other threads:[~2024-02-18  7:46 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-29 18:49 bug#68801: 30.0.50; minibuffer-visible-completions=t makes RET in completion-in-region a no-op with nothing selected Spencer Baugh
2024-01-30 17:28 ` Juri Linkov
2024-01-30 20:21   ` Spencer Baugh
2024-01-31  7:58     ` Juri Linkov
2024-02-09  7:17       ` Juri Linkov
2024-02-10 18:14         ` sbaugh
2024-02-11 17:59           ` Juri Linkov
2024-02-11 21:02             ` sbaugh
2024-02-16 14:34               ` Spencer Baugh
2024-02-18  7:46                 ` 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.