all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Unhelpful text in C-h v search-default-mode
@ 2023-10-24  9:45 Alan Mackenzie
  2023-10-25  6:43 ` Juri Linkov
  2023-12-29  7:12 ` Juri Linkov
  0 siblings, 2 replies; 13+ messages in thread
From: Alan Mackenzie @ 2023-10-24  9:45 UTC (permalink / raw)
  To: emacs-devel

Hello, Emacs.

In a recent master branch Emacs, (not with -Q), from an info buffer, I
did C-h v search-default-mode.  The text printed in *Help* included this:

    Its value is
    #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
    Original value was nil
    Local in buffer *info*<3>; global value is nil

..  This is quite frankly entirely unhelpful; it gives no way to find out
what the lambda is, in particular, no way to get to its source code.  It
isn't even possible to disassemble the function.

After a good deal of searching, I think I found the pertinent source
code, but am not sure, namely in isearch.el L4685, right near the end:

      (setq-local isearch-fold-quotes-mode--state
                  (buffer-local-set-state
                   search-default-mode
                   (lambda (string &optional _lax)
                     (thread-last
                       (regexp-quote string)
                       (replace-regexp-in-string "`" "[`‘]")
                       (replace-regexp-in-string "'" "['’]")
                       (replace-regexp-in-string "\"" "[\"""]")))))

..  Here, this customisable variable search-default-mode gets set to a
lambda function.  The problem could have been avoided if the extra effort
to come up with a symbol for this function had been expended, and the
function written separately as a defun with a name.

I am asking people to be careful not to use lambda forms like this,
instead always prefering defun and a name.

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-10-24  9:45 Unhelpful text in C-h v search-default-mode Alan Mackenzie
@ 2023-10-25  6:43 ` Juri Linkov
  2023-12-29  7:12 ` Juri Linkov
  1 sibling, 0 replies; 13+ messages in thread
From: Juri Linkov @ 2023-10-25  6:43 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> In a recent master branch Emacs, (not with -Q), from an info buffer, I
> did C-h v search-default-mode.  The text printed in *Help* included this:
>
>     Its value is
>     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
>     Original value was nil
>     Local in buffer *info*<3>; global value is nil
>
> ..  This is quite frankly entirely unhelpful; it gives no way to find out
> what the lambda is, in particular, no way to get to its source code.  It
> isn't even possible to disassemble the function.
>
> After a good deal of searching, I think I found the pertinent source
> code, but am not sure, namely in isearch.el L4685, right near the end:
>
>       (setq-local isearch-fold-quotes-mode--state
>                   (buffer-local-set-state
>                    search-default-mode
>                    (lambda (string &optional _lax)
>                      (thread-last
>                        (regexp-quote string)
>                        (replace-regexp-in-string "`" "[`‘]")
>                        (replace-regexp-in-string "'" "['’]")
>                        (replace-regexp-in-string "\"" "[\"""]")))))
>
> ..  Here, this customisable variable search-default-mode gets set to a
> lambda function.  The problem could have been avoided if the extra effort
> to come up with a symbol for this function had been expended, and the
> function written separately as a defun with a name.
>
> I am asking people to be careful not to use lambda forms like this,
> instead always prefering defun and a name.

A good name for the new function would be 'isearch-fold-quotes-regexp'
modeled after the existing 'isearch-symbol-regexp', 'char-fold-to-regexp'.



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-10-24  9:45 Unhelpful text in C-h v search-default-mode Alan Mackenzie
  2023-10-25  6:43 ` Juri Linkov
@ 2023-12-29  7:12 ` Juri Linkov
  2023-12-29  7:21   ` Emanuel Berg
                     ` (2 more replies)
  1 sibling, 3 replies; 13+ messages in thread
From: Juri Linkov @ 2023-12-29  7:12 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> In a recent master branch Emacs, (not with -Q), from an info buffer, I
> did C-h v search-default-mode.  The text printed in *Help* included this:
>
>     Its value is
>     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
>     Original value was nil
>     Local in buffer *info*<3>; global value is nil
>
> ..  This is quite frankly entirely unhelpful; it gives no way to find out
> what the lambda is, in particular, no way to get to its source code.  It
> isn't even possible to disassemble the function.

Another example:

0. emacs -Q
1. M-x list-timers

   *     0.1s     t show-paren-function
   *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>

I wonder how users are supposed to know what function it is?
Searching by the delay number 0.5 reveals this lambda comes from

        (setq jit-lock-context-timer
              (run-with-idle-timer jit-lock-context-time t
                                   (lambda ()
                                     (unless jit-lock--antiblink-grace-timer
                                       (jit-lock-context-fontify)))))



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29  7:12 ` Juri Linkov
@ 2023-12-29  7:21   ` Emanuel Berg
  2023-12-29  7:50   ` Eli Zaretskii
  2023-12-29 10:01   ` Alan Mackenzie
  2 siblings, 0 replies; 13+ messages in thread
From: Emanuel Berg @ 2023-12-29  7:21 UTC (permalink / raw)
  To: emacs-devel

Juri Linkov wrote:

>> In a recent master branch Emacs, (not with -Q), from an info buffer, I
>> did C-h v search-default-mode.  The text printed in *Help* included this:
>>
>>     Its value is
>>     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
>>     Original value was nil
>>     Local in buffer *info*<3>; global value is nil
>>
>> ..  This is quite frankly entirely unhelpful; it gives no way to find out
>> what the lambda is, in particular, no way to get to its source code.  It
>> isn't even possible to disassemble the function.
>
> Another example:
>
> 0. emacs -Q
> 1. M-x list-timers
>
>    *     0.1s     t show-paren-function
>    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
>
> I wonder how users are supposed to know what function it is?
> Searching by the delay number 0.5 reveals this lambda comes
> from
>
>         (setq jit-lock-context-timer
>               (run-with-idle-timer jit-lock-context-time t
>                                    (lambda ()
>                                      (unless jit-lock--antiblink-grace-timer
>                                        (jit-lock-context-fontify)))))

One will know it by not using an anonymous function (a lambda)
but making a proper function and giving it a descriptive name,
as you see with `show-paren-function' in your own example :)

-- 
underground experts united
https://dataswamp.org/~incal




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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29  7:12 ` Juri Linkov
  2023-12-29  7:21   ` Emanuel Berg
@ 2023-12-29  7:50   ` Eli Zaretskii
  2023-12-29  7:54     ` Eli Zaretskii
  2023-12-29 10:01   ` Alan Mackenzie
  2 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2023-12-29  7:50 UTC (permalink / raw)
  To: Juri Linkov; +Cc: acm, emacs-devel

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Fri, 29 Dec 2023 09:12:49 +0200
> 
> > In a recent master branch Emacs, (not with -Q), from an info buffer, I
> > did C-h v search-default-mode.  The text printed in *Help* included this:
> >
> >     Its value is
> >     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
> >     Original value was nil
> >     Local in buffer *info*<3>; global value is nil
> >
> > ..  This is quite frankly entirely unhelpful; it gives no way to find out
> > what the lambda is, in particular, no way to get to its source code.  It
> > isn't even possible to disassemble the function.
> 
> Another example:
> 
> 0. emacs -Q
> 1. M-x list-timers
> 
>    *     0.1s     t show-paren-function
>    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
> 
> I wonder how users are supposed to know what function it is?
> Searching by the delay number 0.5 reveals this lambda comes from
> 
>         (setq jit-lock-context-timer
>               (run-with-idle-timer jit-lock-context-time t
>                                    (lambda ()
>                                      (unless jit-lock--antiblink-grace-timer
>                                        (jit-lock-context-fontify)))))
> 

What happens with that in a build without native-compilation? does
what list-timers shows in that case look more friendly?



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29  7:50   ` Eli Zaretskii
@ 2023-12-29  7:54     ` Eli Zaretskii
  2023-12-30 17:40       ` Juri Linkov
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2023-12-29  7:54 UTC (permalink / raw)
  To: juri, acm; +Cc: emacs-devel

> Date: Fri, 29 Dec 2023 09:50:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: acm@muc.de, emacs-devel@gnu.org
> 
> > From: Juri Linkov <juri@linkov.net>
> > Cc: emacs-devel@gnu.org
> > Date: Fri, 29 Dec 2023 09:12:49 +0200
> > 
> > 0. emacs -Q
> > 1. M-x list-timers
> > 
> >    *     0.1s     t show-paren-function
> >    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
> > 
> > I wonder how users are supposed to know what function it is?
> > Searching by the delay number 0.5 reveals this lambda comes from
> > 
> >         (setq jit-lock-context-timer
> >               (run-with-idle-timer jit-lock-context-time t
> >                                    (lambda ()
> >                                      (unless jit-lock--antiblink-grace-timer
> >                                        (jit-lock-context-fontify)))))
> > 
> 
> What happens with that in a build without native-compilation? does
> what list-timers shows in that case look more friendly?

Answering my own question:

               0.2s         0.5s blink-cursor-timer-function
   *           0.1s            t show-paren-function
   *           0.5s      :repeat blink-cursor-start
   *           0.5s            t #f(compiled-function () #<bytecode 0x12cdf98f4135684a> [jit-lock--antiblink-grace-timer jit-lock-context-fontify])

So are you saying that #<bytecode 0x12cdf98f4135684a> is friendlier
than #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>?
If so, please explain how is it friendlier.



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29  7:12 ` Juri Linkov
  2023-12-29  7:21   ` Emanuel Berg
  2023-12-29  7:50   ` Eli Zaretskii
@ 2023-12-29 10:01   ` Alan Mackenzie
  2023-12-29 10:58     ` Emanuel Berg
  2023-12-29 11:45     ` Eli Zaretskii
  2 siblings, 2 replies; 13+ messages in thread
From: Alan Mackenzie @ 2023-12-29 10:01 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

Hello, Juri.

On Fri, Dec 29, 2023 at 09:12:49 +0200, Juri Linkov wrote:
> > In a recent master branch Emacs, (not with -Q), from an info buffer, I
> > did C-h v search-default-mode.  The text printed in *Help* included this:

> >     Its value is
> >     #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
> >     Original value was nil
> >     Local in buffer *info*<3>; global value is nil

> > ..  This is quite frankly entirely unhelpful; it gives no way to find out
> > what the lambda is, in particular, no way to get to its source code.  It
> > isn't even possible to disassemble the function.

> Another example:

> 0. emacs -Q
> 1. M-x list-timers

>    *     0.1s     t show-paren-function
>    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>

> I wonder how users are supposed to know what function it is?
> Searching by the delay number 0.5 reveals this lambda comes from

>         (setq jit-lock-context-timer
>               (run-with-idle-timer jit-lock-context-time t
>                                    (lambda ()
>                                      (unless jit-lock--antiblink-grace-timer
>                                        (jit-lock-context-fontify)))))

The new feature I've been working on for a couple of months should fix
this problem, too.  I'm making steady progress, currently being stuck on
cl-generic.el, due to its appalling lack of documentation.

Incidentally, why do we need the long string of hex digits in the subr
names F616e....6461_anonymous_lambda_109?  These  are simply the ASCII
codes for "anonymous_lambda", and would appear to be utterly
superfluous.  They serve only to make it more difficult to use the
function name, or to talk about it, and they make the list-timers output
much wider than it need be.

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29 10:01   ` Alan Mackenzie
@ 2023-12-29 10:58     ` Emanuel Berg
  2023-12-30 17:43       ` Juri Linkov
  2023-12-29 11:45     ` Eli Zaretskii
  1 sibling, 1 reply; 13+ messages in thread
From: Emanuel Berg @ 2023-12-29 10:58 UTC (permalink / raw)
  To: emacs-devel

Alan Mackenzie wrote:

> Incidentally, why do we need the long string of hex digits
> in the subr names F616e....6461_anonymous_lambda_109?
> These are simply the ASCII codes for "anonymous_lambda"

Impressive that you just saw that!

I had to spend a lot of time before I even realized the
initial "F" is for function, i.e. not part of the hex string.

You just made one mistake, hex 2d is actually the hyphen, "-".
Yeah, this is what happens to people who rely on skills.

I found the code one the web and spent some time adopting it
to my style. But the credit for solving the problem belongs to
the SX user Inaimathi (see URL below).

As a side note, I know not everyone likes cl-lib and `cl-loop'
in particular but here at least I am very appreciative of the
below solution, style aspects not the least.

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/hex.el
;;
;; original code:
;;   https://stackoverflow.com/a/12007656

(require 'cl-lib)

(defun decode-hex (str)
  (apply #'concat
    (cl-loop
      for i from 0 to (1- (/ (length str) 2))
      for hex-byte = (substring str (* 2 i) (* 2 (1+ i)))
      collect (format "%c" (string-to-number hex-byte 16)) )))

;; (decode-hex "616e6f6e796d6f75732d6c616d626461") ; anonymous-lambda

(provide 'hex)

-- 
underground experts united
https://dataswamp.org/~incal




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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29 10:01   ` Alan Mackenzie
  2023-12-29 10:58     ` Emanuel Berg
@ 2023-12-29 11:45     ` Eli Zaretskii
  2023-12-29 20:19       ` Andrea Corallo
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2023-12-29 11:45 UTC (permalink / raw)
  To: Alan Mackenzie, Andrea Corallo; +Cc: juri, emacs-devel

> Date: Fri, 29 Dec 2023 10:01:35 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Incidentally, why do we need the long string of hex digits in the subr
> names F616e....6461_anonymous_lambda_109?  These  are simply the ASCII
> codes for "anonymous_lambda", and would appear to be utterly
> superfluous.  They serve only to make it more difficult to use the
> function name, or to talk about it, and they make the list-timers output
> much wider than it need be.

Let's ask Andrea (CC'ed) to tell why he decided to use this notation.



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29 11:45     ` Eli Zaretskii
@ 2023-12-29 20:19       ` Andrea Corallo
  0 siblings, 0 replies; 13+ messages in thread
From: Andrea Corallo @ 2023-12-29 20:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Alan Mackenzie, juri, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 29 Dec 2023 10:01:35 +0000
>> Cc: emacs-devel@gnu.org
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> Incidentally, why do we need the long string of hex digits in the subr
>> names F616e....6461_anonymous_lambda_109?  These  are simply the ASCII
>> codes for "anonymous_lambda", and would appear to be utterly
>> superfluous.  They serve only to make it more difficult to use the
>> function name, or to talk about it, and they make the list-timers output
>> much wider than it need be.
>
> Let's ask Andrea (CC'ed) to tell why he decided to use this notation.

I believe it was just to have a unique name, for that probably at the
time I just used the C name.  I welcome patches to improve this if we
feel is important.

  Andrea



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29  7:54     ` Eli Zaretskii
@ 2023-12-30 17:40       ` Juri Linkov
  0 siblings, 0 replies; 13+ messages in thread
From: Juri Linkov @ 2023-12-30 17:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: acm, emacs-devel

>> > 1. M-x list-timers
>> >
>> >    *     0.1s     t show-paren-function
>> >    *     0.5s     t #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>
>> >
>> > I wonder how users are supposed to know what function it is?
>> > Searching by the delay number 0.5 reveals this lambda comes from
>> >
>> >         (setq jit-lock-context-timer
>> >               (run-with-idle-timer jit-lock-context-time t
>> >                                    (lambda ()
>> >                                      (unless jit-lock--antiblink-grace-timer
>> >                                        (jit-lock-context-fontify)))))
>> >
>>
>> What happens with that in a build without native-compilation? does
>> what list-timers shows in that case look more friendly?
>
> Answering my own question:
>
>   0.2s    0.5s blink-cursor-timer-function
> * 0.1s       t show-paren-function
> * 0.5s :repeat blink-cursor-start
> * 0.5s       t #f(compiled-function () #<bytecode 0x12cdf98f4135684a>
>                [jit-lock--antiblink-grace-timer jit-lock-context-fontify])
>
> So are you saying that #<bytecode 0x12cdf98f4135684a> is friendlier
> than #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_13>?
> If so, please explain how is it friendlier.

At least it contains symbols like 'jit-lock-context-fontify'
that provide a hint what is this function about, and
it's possible to grep these symbols.  Hopefully Alan could
improve the readability of these cryptic names.



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-29 10:58     ` Emanuel Berg
@ 2023-12-30 17:43       ` Juri Linkov
  2023-12-31  3:23         ` Emanuel Berg
  0 siblings, 1 reply; 13+ messages in thread
From: Juri Linkov @ 2023-12-30 17:43 UTC (permalink / raw)
  To: emacs-devel

>> Incidentally, why do we need the long string of hex digits
>> in the subr names F616e....6461_anonymous_lambda_109?
>> These are simply the ASCII codes for "anonymous_lambda"
>
> Impressive that you just saw that!
>
> I had to spend a lot of time before I even realized the
> initial "F" is for function, i.e. not part of the hex string.

Interesting.  I didn't know that
#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
contains an "encrypted" message:

(replace-regexp-in-string ".."
 (lambda (hex) (string (string-to-number hex 16)))
 "616e6f6e796d6f75732d6c616d626461")
=> "anonymous-lambda"



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

* Re: Unhelpful text in C-h v search-default-mode
  2023-12-30 17:43       ` Juri Linkov
@ 2023-12-31  3:23         ` Emanuel Berg
  0 siblings, 0 replies; 13+ messages in thread
From: Emanuel Berg @ 2023-12-31  3:23 UTC (permalink / raw)
  To: emacs-devel

Juri Linkov wrote:

>>> Incidentally, why do we need the long string of hex digits
>>> in the subr names F616e....6461_anonymous_lambda_109?
>>> These are simply the ASCII codes for "anonymous_lambda"
>>
>> Impressive that you just saw that!
>>
>> I had to spend a lot of time before I even realized the
>> initial "F" is for function, i.e. not part of the
>> hex string.
>
> Interesting. I didn't know that
> #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
> contains an "encrypted" message

Yeah, it is amazing you can still have this much fun with Emacs
after all these years using it every day!

> (replace-regexp-in-string ".."
>  (lambda (hex) (string (string-to-number hex 16)))
>  "616e6f6e796d6f75732d6c616d626461")
> => "anonymous-lambda"

Right, even tho I really appreciate the way `cl-loop' solved
the translation in my previous post I have to give it to you,
your solution is cleaner.

It is closer in style to this shell script and Unix tool
parsing which does the same thing:

$ str=$(printf '616e6f6e796d6f75732d6c616d626461' | sed 's,..,\\x&,g')
$ printf '%b\n' "$str"
anonymous-lambda

Anyway I added it to my hex.el file with a reference to your
post on the gnu.emacs.devel archives, see URL below.

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/hex.el
;;
;; original code:
;;   https://stackoverflow.com/a/12007656
;;   https://lists.gnu.org/archive/html/emacs-devel/2023-12/msg00947.html

(require 'cl-lib)

(defun decode-hex-2 (str)
  (replace-regexp-in-string ".."
    (lambda (hex) (string (string-to-number hex 16)))
    str) )

;; (decode-hex-2 "616e6f6e796d6f75732d6c616d626461")

(defun decode-hex (str)
  (apply #'concat
    (cl-loop
      for i from 0 to (1- (/ (length str) 2))
      for hex-byte = (substring str (* 2 i) (* 2 (1+ i)))
      collect (format "%c" (string-to-number hex-byte 16)) )))

;; (decode-hex "616e6f6e796d6f75732d6c616d626461")

(provide 'hex)

-- 
underground experts united
https://dataswamp.org/~incal




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

end of thread, other threads:[~2023-12-31  3:23 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-24  9:45 Unhelpful text in C-h v search-default-mode Alan Mackenzie
2023-10-25  6:43 ` Juri Linkov
2023-12-29  7:12 ` Juri Linkov
2023-12-29  7:21   ` Emanuel Berg
2023-12-29  7:50   ` Eli Zaretskii
2023-12-29  7:54     ` Eli Zaretskii
2023-12-30 17:40       ` Juri Linkov
2023-12-29 10:01   ` Alan Mackenzie
2023-12-29 10:58     ` Emanuel Berg
2023-12-30 17:43       ` Juri Linkov
2023-12-31  3:23         ` Emanuel Berg
2023-12-29 11:45     ` Eli Zaretskii
2023-12-29 20:19       ` Andrea Corallo

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.