all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Thoughts on replacing macros with static inline functions
@ 2022-11-14 18:05 Brent Pappas
  2022-11-15 12:45 ` Eli Zaretskii
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Brent Pappas @ 2022-11-14 18:05 UTC (permalink / raw)
  To: emacs-devel@gnu.org

Title: Thoughts on replacing macros with static inline functions

Hi,

I noticed that Emacs code sometimes uses macros where a static inline function
would appear to work equally as well.
For instance, consider the macro PAD defined in src/xsettings.c

#define PAD(nr)    (((nr) + 3) & ~3)

I imagine this could be turned into a function like so:

static inline int PAD(int nr)    { return (((nr) + 3) & ~3); }

The reason why one would want to replace macros with functions is because
functions are often easier to reason about than macros.
The GNU C Preprocessor manual even has a list of pitfalls one can fall into
when programming with macros.
So it may be worthwhile to turn such macros into functions to prevent
developers from accidentally falling into one of these pitfalls.

How interested would the Emacs community be in porting macros to functions?


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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-14 18:05 Thoughts on replacing macros with static inline functions Brent Pappas
@ 2022-11-15 12:45 ` Eli Zaretskii
  2022-11-18  5:05   ` Richard Stallman
  2022-11-15 13:49 ` Po Lu
  2022-11-15 14:10 ` Stefan Monnier
  2 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2022-11-15 12:45 UTC (permalink / raw)
  To: Brent Pappas; +Cc: emacs-devel

> From: Brent Pappas <pappasbrent@Knights.ucf.edu>
> Date: Mon, 14 Nov 2022 18:05:15 +0000
> msip_labels: 
> 
> I noticed that Emacs code sometimes uses macros where a static inline function
> would appear to work equally as well.
> For instance, consider the macro PAD defined in src/xsettings.c
> 
> #define PAD(nr)    (((nr) + 3) & ~3)
> 
> I imagine this could be turned into a function like so:
> 
> static inline int PAD(int nr)    { return (((nr) + 3) & ~3); }

This is only equivalent in an optimized build, where modern compilers
usually inline such functions.  Emacs developers (yours truly
included) frequently run unoptimized builds because optimized code can
be tricky to debug.  Using functions in an unoptimized build can slow
down Emacs, especially if the macro you want to replace is used in
inner loops that are "hot spots" in Emacs.

> The reason why one would want to replace macros with functions is because
> functions are often easier to reason about than macros.
> The GNU C Preprocessor manual even has a list of pitfalls one can fall into
> when programming with macros.
> So it may be worthwhile to turn such macros into functions to prevent
> developers from accidentally falling into one of these pitfalls.
> 
> How interested would the Emacs community be in porting macros to functions?

I'd prefer not to do this en masse.  Certain specific cases could be
considered on a case by case basis.  But even here, changes like this
tend to make the code less familiar for people who have many years of
hacking Emacs under their belts, so the reason for the conversion
would have to be very convincing for me to agree.

Thanks.



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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-14 18:05 Thoughts on replacing macros with static inline functions Brent Pappas
  2022-11-15 12:45 ` Eli Zaretskii
@ 2022-11-15 13:49 ` Po Lu
  2022-11-15 15:54   ` xenodasein--- via Emacs development discussions.
  2022-11-15 14:10 ` Stefan Monnier
  2 siblings, 1 reply; 18+ messages in thread
From: Po Lu @ 2022-11-15 13:49 UTC (permalink / raw)
  To: Brent Pappas; +Cc: emacs-devel@gnu.org

Brent Pappas <pappasbrent@Knights.ucf.edu> writes:

> Title: Thoughts on replacing macros with static inline functions
>
> Hi,
>
> I noticed that Emacs code sometimes uses macros where a static inline function
> would appear to work equally as well.
> For instance, consider the macro PAD defined in src/xsettings.c
>
> #define PAD(nr)    (((nr) + 3) & ~3)
>
> I imagine this could be turned into a function like so:
>
> static inline int PAD(int nr)    { return (((nr) + 3) & ~3); }

I find that rather ugly.  PAD is an example of an extremely trivial
expression that should really be a macro.

> How interested would the Emacs community be in porting macros to functions?

Not very, in this case.  That exact PAD macro is not only an idiom used
throughout the Emacs X11 code, it is more-or-less an idiom of the entire
X Window System, copied around and used extensively throughout the X
sample server, Xlib, and C-language clients.

In addition, we try to avoid undue changes to working code, so giving
carte blanche to change macros to static functions is not something we
really want to do.  But if you want to do that to a few big, ugly,
macros around an area in which you are making actual changes, please go
ahead.



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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-14 18:05 Thoughts on replacing macros with static inline functions Brent Pappas
  2022-11-15 12:45 ` Eli Zaretskii
  2022-11-15 13:49 ` Po Lu
@ 2022-11-15 14:10 ` Stefan Monnier
  2 siblings, 0 replies; 18+ messages in thread
From: Stefan Monnier @ 2022-11-15 14:10 UTC (permalink / raw)
  To: Brent Pappas; +Cc: emacs-devel@gnu.org

> How interested would the Emacs community be in porting macros to functions?

Most of the macros are there for historical reasons.
We do change macros to functions, for all the reasons you mention.
But we prefer to do it little by little as we touch the
corresponding code.


        Sefan




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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-15 13:49 ` Po Lu
@ 2022-11-15 15:54   ` xenodasein--- via Emacs development discussions.
  0 siblings, 0 replies; 18+ messages in thread
From: xenodasein--- via Emacs development discussions. @ 2022-11-15 15:54 UTC (permalink / raw)
  To: Po Lu; +Cc: Brent Pappas, emacs-devel@gnu.org

Nov 15, 2022, 13:49 by luangruo@yahoo.com:

> Brent Pappas <pappasbrent@Knights.ucf.edu> writes:
>
>> Title: Thoughts on replacing macros with static inline functions
>> ...
>>
>>
> I find that rather ugly.  PAD is an example of an extremely trivial
> expression that should really be a macro.
>
>> How interested would the Emacs community be in porting macros to functions?
>>
>
> Not very, in this case.  That exact PAD macro is not only an idiom used
> throughout the Emacs X11 code, it is more-or-less an idiom of the entire
> X Window System, copied around and used extensively throughout the X
> sample server, Xlib, and C-language clients.
>
> In addition, we try to avoid undue changes to working code, so giving
> carte blanche to change macros to static functions is not something we
> really want to do.  But if you want to do that to a few big, ugly,
> macros around an area in which you are making actual changes, please go
> ahead.
>

You answer in a tone that means you speak for everyone else, is this
intentional if so why?




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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-15 12:45 ` Eli Zaretskii
@ 2022-11-18  5:05   ` Richard Stallman
  2022-11-18  6:19     ` xenodasein--- via Emacs development discussions.
  0 siblings, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2022-11-18  5:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: pappasbrent, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I agree -- there is nothing wrong with macros, and we should
not make it or goal to eliminate the use of macros.
Macros have pitfalls, which are consequences of their basic nature,
but we know how to avoid them, and have documented the methods.

The GNU C Language Introduction and Reference Manual advises users on
how to deal with these and many other pitfalls of the C language.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  5:05   ` Richard Stallman
@ 2022-11-18  6:19     ` xenodasein--- via Emacs development discussions.
  2022-11-18  6:27       ` Po Lu
                         ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: xenodasein--- via Emacs development discussions. @ 2022-11-18  6:19 UTC (permalink / raw)
  To: Richard Stallman; +Cc: Eli Zaretskii, pappasbrent, emacs-devel

Nov 18, 2022, 05:05 by rms@gnu.org:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I agree -- there is nothing wrong with macros, and we should
> not make it or goal to eliminate the use of macros.
> Macros have pitfalls, which are consequences of their basic nature,
> but we know how to avoid them, and have documented the methods.
>
> The GNU C Language Introduction and Reference Manual advises users on
> how to deal with these and many other pitfalls of the C language.
>
> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (> https://internethalloffame.org> )
>

Why do you not consider __attribute__((always_inline)) an improvement
over macros where applicable?




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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  6:19     ` xenodasein--- via Emacs development discussions.
@ 2022-11-18  6:27       ` Po Lu
  2022-11-18  6:32         ` xenodasein--- via Emacs development discussions.
  2022-11-18  8:34         ` Eli Zaretskii
  2022-11-18  6:59       ` tomas
  2022-11-18 14:53       ` Stefan Monnier
  2 siblings, 2 replies; 18+ messages in thread
From: Po Lu @ 2022-11-18  6:27 UTC (permalink / raw)
  To: xenodasein--- via Emacs development discussions.
  Cc: Richard Stallman, xenodasein, Eli Zaretskii, pappasbrent

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Why do you not consider __attribute__((always_inline)) an improvement
> over macros where applicable?

And exactly where is __attribute__((always_inline)) present?  Only on
GCC, right?  What about Sun C, and other C99 compilers?

And how is an additional function an improvement over extremely trivial
macros, like these:

#define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
#define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
#define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)

?



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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  6:27       ` Po Lu
@ 2022-11-18  6:32         ` xenodasein--- via Emacs development discussions.
  2022-11-18  7:29           ` Po Lu
  2022-11-18  8:34         ` Eli Zaretskii
  1 sibling, 1 reply; 18+ messages in thread
From: xenodasein--- via Emacs development discussions. @ 2022-11-18  6:32 UTC (permalink / raw)
  To: Po Lu
  Cc: xenodasein--- viaEmacs development discussions., Richard Stallman,
	Eli Zaretskii, pappasbrent

Nov 18, 2022, 06:27 by luangruo@yahoo.com:

> xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> Why do you not consider __attribute__((always_inline)) an improvement
>> over macros where applicable?
>>
>
> And exactly where is __attribute__((always_inline)) present?  Only on
> GCC, right?  What about Sun C, and other C99 compilers?
>
> And how is an additional function an improvement over extremely trivial
> macros, like these:
>
> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)
>
> ?
>

Lookup why functions are considered an improvement over macros.

As for compiler support, I bet the time spent debugging where there is
support is going to dwarf where isn't, so trade-off is clear.





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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  6:19     ` xenodasein--- via Emacs development discussions.
  2022-11-18  6:27       ` Po Lu
@ 2022-11-18  6:59       ` tomas
  2022-11-18  7:12         ` xenodasein--- via Emacs development discussions.
  2022-11-18 14:53       ` Stefan Monnier
  2 siblings, 1 reply; 18+ messages in thread
From: tomas @ 2022-11-18  6:59 UTC (permalink / raw)
  To: emacs-devel

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

On Fri, Nov 18, 2022 at 07:19:45AM +0100, xenodasein--- via Emacs development discussions. wrote:

[...]

> Why do you not consider __attribute__((always_inline)) an improvement
> over macros where applicable?

I think you spelled it yourself: "where applicable": this is
something which has to be considered on a case by case basis.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  6:59       ` tomas
@ 2022-11-18  7:12         ` xenodasein--- via Emacs development discussions.
  0 siblings, 0 replies; 18+ messages in thread
From: xenodasein--- via Emacs development discussions. @ 2022-11-18  7:12 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

Nov 18, 2022, 06:59 by tomas@tuxteam.de:

> On Fri, Nov 18, 2022 at 07:19:45AM +0100, xenodasein--- via Emacs development discussions. wrote:
>
> [...]
>
>> Why do you not consider __attribute__((always_inline)) an improvement
>> over macros where applicable?
>>
>
> I think you spelled it yourself: "where applicable": this is
> something which has to be considered on a case by case basis.
>
> Cheers
> -- 
> t
>

For you and me sure, I was curious about Richard's opinion.




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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  6:32         ` xenodasein--- via Emacs development discussions.
@ 2022-11-18  7:29           ` Po Lu
  0 siblings, 0 replies; 18+ messages in thread
From: Po Lu @ 2022-11-18  7:29 UTC (permalink / raw)
  To: xenodasein
  Cc: xenodasein--- viaEmacs development discussions., Richard Stallman,
	Eli Zaretskii, pappasbrent

xenodasein@tutanota.de writes:

> Lookup why functions are considered an improvement over macros.

I don't.

> As for compiler support, I bet the time spent debugging where there is
> support is going to dwarf where isn't, so trade-off is clear.

You mean, trading debugging time for runtime? That tradeoff was already
made the moment Emacs was written in C, and besides, modern debuginfo
formats already support macros.




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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  6:27       ` Po Lu
  2022-11-18  6:32         ` xenodasein--- via Emacs development discussions.
@ 2022-11-18  8:34         ` Eli Zaretskii
  2022-11-18 11:31           ` xenodasein--- via Emacs development discussions.
  1 sibling, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2022-11-18  8:34 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel, rms, xenodasein, pappasbrent

> From: Po Lu <luangruo@yahoo.com>
> Cc: Richard Stallman <rms@gnu.org>,  xenodasein@tutanota.de,  Eli Zaretskii
>  <eliz@gnu.org>,  pappasbrent@knights.ucf.edu
> Date: Fri, 18 Nov 2022 14:27:09 +0800
> 
> And how is an additional function an improvement over extremely trivial
> macros, like these:
> 
> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)

The purpose of macros such as the above is to explain the meaning of
the code in human-readable terms.  Replacing this by functions makes
no more sense than replacing "c = a + b;" with a function.



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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  8:34         ` Eli Zaretskii
@ 2022-11-18 11:31           ` xenodasein--- via Emacs development discussions.
  2022-11-18 11:43             ` Po Lu
  2022-11-18 12:00             ` Eli Zaretskii
  0 siblings, 2 replies; 18+ messages in thread
From: xenodasein--- via Emacs development discussions. @ 2022-11-18 11:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, emacs-devel, rms, pappasbrent

Nov 18, 2022, 08:34 by eliz@gnu.org:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Richard Stallman <rms@gnu.org>,  xenodasein@tutanota.de,  Eli Zaretskii
>>  <eliz@gnu.org>,  pappasbrent@knights.ucf.edu
>> Date: Fri, 18 Nov 2022 14:27:09 +0800
>>
>> And how is an additional function an improvement over extremely trivial
>> macros, like these:
>>
>> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
>> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
>> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)
>>
>
> The purpose of macros such as the above is to explain the meaning of
> the code in human-readable terms.  Replacing this by functions makes
> no more sense than replacing "c = a + b;" with a function.
>

Right?  Who needs a proper API when you can have paranoid parentheses
macros with bit hackery!




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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18 11:31           ` xenodasein--- via Emacs development discussions.
@ 2022-11-18 11:43             ` Po Lu
  2022-11-18 12:00             ` Eli Zaretskii
  1 sibling, 0 replies; 18+ messages in thread
From: Po Lu @ 2022-11-18 11:43 UTC (permalink / raw)
  To: xenodasein; +Cc: Eli Zaretskii, emacs-devel, rms, pappasbrent

xenodasein@tutanota.de writes:

> Right?  Who needs a proper API when you can have paranoid parentheses
> macros with bit hackery!

And why would there be an API, much less a ``proper'' one, to extract
status flags from a Motif drag-and-drop message (a single CARD32?)



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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18 11:31           ` xenodasein--- via Emacs development discussions.
  2022-11-18 11:43             ` Po Lu
@ 2022-11-18 12:00             ` Eli Zaretskii
  1 sibling, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2022-11-18 12:00 UTC (permalink / raw)
  To: xenodasein; +Cc: luangruo, emacs-devel, rms, pappasbrent

> Date: Fri, 18 Nov 2022 12:31:59 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org, rms@gnu.org,
> 	pappasbrent@knights.ucf.edu
> 
> Nov 18, 2022, 08:34 by eliz@gnu.org:
> 
> >> #define XM_DRAG_REASON(originator, code)	((code) | ((originator) << 7))
> >> #define XM_DRAG_REASON_ORIGINATOR(reason)	(((reason) & 0x80) ? 1 : 0)
> >> #define XM_DRAG_REASON_CODE(reason)		((reason) & 0x7f)
> >>
> >
> > The purpose of macros such as the above is to explain the meaning of
> > the code in human-readable terms.  Replacing this by functions makes
> > no more sense than replacing "c = a + b;" with a function.
> >
> 
> Right?  Who needs a proper API when you can have paranoid parentheses
> macros with bit hackery!

Bitwise operations are first-class citizens in C code, so your sarcasm
is misguided.



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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18  6:19     ` xenodasein--- via Emacs development discussions.
  2022-11-18  6:27       ` Po Lu
  2022-11-18  6:59       ` tomas
@ 2022-11-18 14:53       ` Stefan Monnier
  2022-11-18 16:16         ` Dr. Arne Babenhauserheide
  2 siblings, 1 reply; 18+ messages in thread
From: Stefan Monnier @ 2022-11-18 14:53 UTC (permalink / raw)
  To: xenodasein--- via Emacs development discussions.
  Cc: Richard Stallman, xenodasein, Eli Zaretskii, pappasbrent

> Why do you not consider __attribute__((always_inline)) an improvement
> over macros where applicable?

Can we drop this discussion.  AFAIK all those who matter already
explained clearly that we generally agree it's an improvement, but that
it's not enough of an improvement to justify making the change just for
the sake of it.

IOW we all agree on the general idea, we just disagree on the degrees
and I see no way we'll convince each other to agree on what degree
is right.  So we just have to tolerate other people's preferences, with
the understanding that none of us is *right*.


        Stefan




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

* Re: Thoughts on replacing macros with static inline functions
  2022-11-18 14:53       ` Stefan Monnier
@ 2022-11-18 16:16         ` Dr. Arne Babenhauserheide
  0 siblings, 0 replies; 18+ messages in thread
From: Dr. Arne Babenhauserheide @ 2022-11-18 16:16 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Richard Stallman, xenodasein, Eli Zaretskii, pappasbrent,
	emacs-devel

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


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

>> Why do you not consider __attribute__((always_inline)) an improvement
>> over macros where applicable?
>
> Can we drop this discussion.  AFAIK all those who matter already
> explained clearly that we generally agree it's an improvement, but that
> it's not enough of an improvement to justify making the change just for
> the sake of it.

Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1121 bytes --]

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

end of thread, other threads:[~2022-11-18 16:16 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-14 18:05 Thoughts on replacing macros with static inline functions Brent Pappas
2022-11-15 12:45 ` Eli Zaretskii
2022-11-18  5:05   ` Richard Stallman
2022-11-18  6:19     ` xenodasein--- via Emacs development discussions.
2022-11-18  6:27       ` Po Lu
2022-11-18  6:32         ` xenodasein--- via Emacs development discussions.
2022-11-18  7:29           ` Po Lu
2022-11-18  8:34         ` Eli Zaretskii
2022-11-18 11:31           ` xenodasein--- via Emacs development discussions.
2022-11-18 11:43             ` Po Lu
2022-11-18 12:00             ` Eli Zaretskii
2022-11-18  6:59       ` tomas
2022-11-18  7:12         ` xenodasein--- via Emacs development discussions.
2022-11-18 14:53       ` Stefan Monnier
2022-11-18 16:16         ` Dr. Arne Babenhauserheide
2022-11-15 13:49 ` Po Lu
2022-11-15 15:54   ` xenodasein--- via Emacs development discussions.
2022-11-15 14:10 ` Stefan Monnier

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.