* bug#75636: GTK memory leaks
@ 2025-01-17 20:15 Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 9:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-17 20:15 UTC (permalink / raw)
To: 75636, luangruo
Creating and destroying GTK frames (using gtkutil.c, not PGTK) currently
leaks some memory, particularly when using tool bars.
1. The input "multicontext" created by:
imc = gtk_im_multicontext_new ();
g_object_ref (imc);
is only unref'd once when destroying the frame. This leaves the
refcount at 1 and leaks the object.
2. free_frame_tool_bar is never called in my experiments, so the toolbar
widget isn't destroyed.
This isn't usually a problem because it's just a small memory leak, but
on the feature/igc branch, user data passed to glib must be protected in
a special GC root structure; such structures accumulate when running in
GTK, eventually reducing GC performance significantly.
Unfortunately, valgrind doesn't seem to catch these memory leaks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-17 20:15 bug#75636: GTK memory leaks Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-18 9:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 11:49 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-18 9:10 UTC (permalink / raw)
To: Pip Cet; +Cc: 75636
Pip Cet <pipcet@protonmail.com> writes:
> Creating and destroying GTK frames (using gtkutil.c, not PGTK) currently
> leaks some memory, particularly when using tool bars.
>
> 1. The input "multicontext" created by:
>
> imc = gtk_im_multicontext_new ();
> g_object_ref (imc);
>
> is only unref'd once when destroying the frame. This leaves the
> refcount at 1 and leaks the object.
Strange, I was under the impression that IM contexts descended from
GInitiallyUnowned. Evidently they don't, and as such, removing the
g_object_ref will suffice.
> 2. free_frame_tool_bar is never called in my experiments, so the toolbar
> widget isn't destroyed.
It is only supposed to be called when a frame's tool bar is disabled.
while it is x_free_frame_resources that should release all resources
when a frame is to be destroyed.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-18 9:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-18 11:49 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-19 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-18 11:49 UTC (permalink / raw)
To: Po Lu; +Cc: 75636
"Po Lu" <luangruo@yahoo.com> writes:
> Pip Cet <pipcet@protonmail.com> writes:
>
>> Creating and destroying GTK frames (using gtkutil.c, not PGTK) currently
>> leaks some memory, particularly when using tool bars.
>>
>> 1. The input "multicontext" created by:
>>
>> imc = gtk_im_multicontext_new ();
>> g_object_ref (imc);
>>
>> is only unref'd once when destroying the frame. This leaves the
>> refcount at 1 and leaks the object.
>
> Strange, I was under the impression that IM contexts descended from
> GInitiallyUnowned. Evidently they don't, and as such, removing the
> g_object_ref will suffice.
Thanks! I'll just do that, then? I think it's okay only to do it on
master, as it's a minor bug in the !HAVE_MPS case.
>> 2. free_frame_tool_bar is never called in my experiments, so the toolbar
>> widget isn't destroyed.
>
> It is only supposed to be called when a frame's tool bar is disabled.
> while it is x_free_frame_resources that should release all resources
> when a frame is to be destroyed.
Thanks! I'll come up with a patch and discuss it further for this one,
because it's not quite trivial.
Pip
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-18 11:49 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-19 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 11:24 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-19 0:53 UTC (permalink / raw)
To: Pip Cet; +Cc: 75636
Pip Cet <pipcet@protonmail.com> writes:
> "Po Lu" <luangruo@yahoo.com> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>> Creating and destroying GTK frames (using gtkutil.c, not PGTK) currently
>>> leaks some memory, particularly when using tool bars.
>>>
>>> 1. The input "multicontext" created by:
>>>
>>> imc = gtk_im_multicontext_new ();
>>> g_object_ref (imc);
>>>
>>> is only unref'd once when destroying the frame. This leaves the
>>> refcount at 1 and leaks the object.
>>
>> Strange, I was under the impression that IM contexts descended from
>> GInitiallyUnowned. Evidently they don't, and as such, removing the
>> g_object_ref will suffice.
>
> Thanks! I'll just do that, then? I think it's okay only to do it on
> master, as it's a minor bug in the !HAVE_MPS case.
Sounds good to me.
>>> 2. free_frame_tool_bar is never called in my experiments, so the toolbar
>>> widget isn't destroyed.
>>
>> It is only supposed to be called when a frame's tool bar is disabled.
>> while it is x_free_frame_resources that should release all resources
>> when a frame is to be destroyed.
>
> Thanks! I'll come up with a patch and discuss it further for this one,
> because it's not quite trivial.
>
> Pip
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-19 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-21 11:24 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 18:33 ` Stefan Kangas
2025-01-22 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 10+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-21 11:24 UTC (permalink / raw)
To: Po Lu; +Cc: 75636
"Po Lu" <luangruo@yahoo.com> writes:
> Pip Cet <pipcet@protonmail.com> writes:
>
>> "Po Lu" <luangruo@yahoo.com> writes:
>>
>>> Pip Cet <pipcet@protonmail.com> writes:
>>>
>>>> Creating and destroying GTK frames (using gtkutil.c, not PGTK) currently
>>>> leaks some memory, particularly when using tool bars.
>>>>
>>>> 1. The input "multicontext" created by:
>>>>
>>>> imc = gtk_im_multicontext_new ();
>>>> g_object_ref (imc);
>>>>
>>>> is only unref'd once when destroying the frame. This leaves the
>>>> refcount at 1 and leaks the object.
>>>
>>> Strange, I was under the impression that IM contexts descended from
>>> GInitiallyUnowned. Evidently they don't, and as such, removing the
>>> g_object_ref will suffice.
>>
>> Thanks! I'll just do that, then? I think it's okay only to do it on
>> master, as it's a minor bug in the !HAVE_MPS case.
>
> Sounds good to me.
>
>>>> 2. free_frame_tool_bar is never called in my experiments, so the toolbar
>>>> widget isn't destroyed.
>>>
>>> It is only supposed to be called when a frame's tool bar is disabled.
>>> while it is x_free_frame_resources that should release all resources
>>> when a frame is to be destroyed.
>>
>> Thanks! I'll come up with a patch and discuss it further for this one,
>> because it's not quite trivial.
>>
>> Pip
>
> Thanks.
This showed up during testing, but might ultimately have been because I
deleted the new frame too soon. I can only reproduce it on the
feature/igc branch, but that might be because the timing is different on
that branch.
When we create the initial tool bar, f->tool_bar_items is still Qnil.
In that case, we don't pack the toolbar widget, but create it and
connect signals to it.
xg_free_frame_widgets does not explicitly delete the toolbar, which
works only if it's packed and destroyed implicitly.
I think this is right, and the bug isn't reproducible on the master
branch only because of timing differences:
commit 5ed4aaa986dbf75f8565f4d8cdd3d1d1b38b6142 (HEAD)
Author: Pip Cet <pipcet@protonmail.com>
Destroy GTK tool bar widget if it was never attached (bug#75636)
* src/gtkutil.c (xg_free_frame_widgets): Call gtk_widget_destroy on an
unpacked toolbar widget.
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 0e9dd4dfe11..97582a524da 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1885,6 +1885,12 @@ xg_free_frame_widgets (struct frame *f)
if (tbinfo)
xfree (tbinfo);
+ if (x->toolbar_widget && !x->toolbar_is_packed)
+ {
+ gtk_widget_destroy (x->toolbar_widget);
+ x->toolbar_widget = NULL;
+ }
+
/* x_free_frame_resources should have taken care of it */
#ifndef HAVE_PGTK
#ifdef HAVE_XDBE
I think this second patch might also avoid future compiler warnings:
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 97582a524da..73e9f778c75 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -6123,8 +6123,7 @@ free_frame_tool_bar (struct frame *f)
else
gtk_widget_destroy (x->toolbar_widget);
- x->toolbar_widget = 0;
- x->toolbar_widget = 0;
+ x->toolbar_widget = NULL;
x->toolbar_is_packed = false;
FRAME_TOOLBAR_TOP_HEIGHT (f) = FRAME_TOOLBAR_BOTTOM_HEIGHT (f) = 0;
FRAME_TOOLBAR_LEFT_WIDTH (f) = FRAME_TOOLBAR_RIGHT_WIDTH (f) = 0;
If we can apply the first, minor patch, I think this bug can be closed;
if I run into further GTK issues, I'll open a new one.
Pip
^ permalink raw reply related [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-21 11:24 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-21 18:33 ` Stefan Kangas
2025-01-22 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 10+ messages in thread
From: Stefan Kangas @ 2025-01-21 18:33 UTC (permalink / raw)
To: Pip Cet, Po Lu; +Cc: 75636
Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:
> I think this second patch might also avoid future compiler warnings:
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index 97582a524da..73e9f778c75 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -6123,8 +6123,7 @@ free_frame_tool_bar (struct frame *f)
> else
> gtk_widget_destroy (x->toolbar_widget);
>
> - x->toolbar_widget = 0;
> - x->toolbar_widget = 0;
> + x->toolbar_widget = NULL;
> x->toolbar_is_packed = false;
> FRAME_TOOLBAR_TOP_HEIGHT (f) = FRAME_TOOLBAR_BOTTOM_HEIGHT (f) = 0;
> FRAME_TOOLBAR_LEFT_WIDTH (f) = FRAME_TOOLBAR_RIGHT_WIDTH (f) = 0;
LGTM.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-21 11:24 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 18:33 ` Stefan Kangas
@ 2025-01-22 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-22 1:06 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
` (2 more replies)
1 sibling, 3 replies; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-22 0:42 UTC (permalink / raw)
To: Pip Cet; +Cc: 75636
Pip Cet <pipcet@protonmail.com> writes:
> "Po Lu" <luangruo@yahoo.com> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>> "Po Lu" <luangruo@yahoo.com> writes:
>>>
>>>> Pip Cet <pipcet@protonmail.com> writes:
>>>>
>>>>> Creating and destroying GTK frames (using gtkutil.c, not PGTK) currently
>>>>> leaks some memory, particularly when using tool bars.
>>>>>
>>>>> 1. The input "multicontext" created by:
>>>>>
>>>>> imc = gtk_im_multicontext_new ();
>>>>> g_object_ref (imc);
>>>>>
>>>>> is only unref'd once when destroying the frame. This leaves the
>>>>> refcount at 1 and leaks the object.
>>>>
>>>> Strange, I was under the impression that IM contexts descended from
>>>> GInitiallyUnowned. Evidently they don't, and as such, removing the
>>>> g_object_ref will suffice.
>>>
>>> Thanks! I'll just do that, then? I think it's okay only to do it on
>>> master, as it's a minor bug in the !HAVE_MPS case.
>>
>> Sounds good to me.
>>
>>>>> 2. free_frame_tool_bar is never called in my experiments, so the toolbar
>>>>> widget isn't destroyed.
>>>>
>>>> It is only supposed to be called when a frame's tool bar is disabled.
>>>> while it is x_free_frame_resources that should release all resources
>>>> when a frame is to be destroyed.
>>>
>>> Thanks! I'll come up with a patch and discuss it further for this one,
>>> because it's not quite trivial.
>>>
>>> Pip
>>
>> Thanks.
>
> This showed up during testing, but might ultimately have been because I
> deleted the new frame too soon. I can only reproduce it on the
> feature/igc branch, but that might be because the timing is different on
> that branch.
>
> When we create the initial tool bar, f->tool_bar_items is still Qnil.
> In that case, we don't pack the toolbar widget, but create it and
> connect signals to it.
>
> xg_free_frame_widgets does not explicitly delete the toolbar, which
> works only if it's packed and destroyed implicitly.
>
> I think this is right, and the bug isn't reproducible on the master
> branch only because of timing differences:
>
> commit 5ed4aaa986dbf75f8565f4d8cdd3d1d1b38b6142 (HEAD)
> Author: Pip Cet <pipcet@protonmail.com>
>
> Destroy GTK tool bar widget if it was never attached (bug#75636)
>
> * src/gtkutil.c (xg_free_frame_widgets): Call gtk_widget_destroy on an
> unpacked toolbar widget.
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index 0e9dd4dfe11..97582a524da 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -1885,6 +1885,12 @@ xg_free_frame_widgets (struct frame *f)
> if (tbinfo)
> xfree (tbinfo);
>
> + if (x->toolbar_widget && !x->toolbar_is_packed)
> + {
> + gtk_widget_destroy (x->toolbar_widget);
> + x->toolbar_widget = NULL;
> + }
> +
> /* x_free_frame_resources should have taken care of it */
> #ifndef HAVE_PGTK
> #ifdef HAVE_XDBE
LGTM.
> I think this second patch might also avoid future compiler warnings:
>
> diff --git a/src/gtkutil.c b/src/gtkutil.c
> index 97582a524da..73e9f778c75 100644
> --- a/src/gtkutil.c
> +++ b/src/gtkutil.c
> @@ -6123,8 +6123,7 @@ free_frame_tool_bar (struct frame *f)
> else
> gtk_widget_destroy (x->toolbar_widget);
>
> - x->toolbar_widget = 0;
> - x->toolbar_widget = 0;
> + x->toolbar_widget = NULL;
> x->toolbar_is_packed = false;
0 as the rhs of an assignment to a pointer variable is taken for a NULL
pointer, so there's no issue with the existing code. Indeed on many
systems NULL is simply defined to 0.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-22 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-22 1:06 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-01 23:31 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 21:41 ` Stefan Kangas
2 siblings, 0 replies; 10+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-22 1:06 UTC (permalink / raw)
To: Po Lu; +Cc: 75636
"Po Lu" <luangruo@yahoo.com> writes:
>> commit 5ed4aaa986dbf75f8565f4d8cdd3d1d1b38b6142 (HEAD)
>> Author: Pip Cet <pipcet@protonmail.com>
>>
>> Destroy GTK tool bar widget if it was never attached (bug#75636)
>>
>> * src/gtkutil.c (xg_free_frame_widgets): Call gtk_widget_destroy on an
>> unpacked toolbar widget.
>>
>> diff --git a/src/gtkutil.c b/src/gtkutil.c
>> index 0e9dd4dfe11..97582a524da 100644
>> --- a/src/gtkutil.c
>> +++ b/src/gtkutil.c
>> @@ -1885,6 +1885,12 @@ xg_free_frame_widgets (struct frame *f)
>> if (tbinfo)
>> xfree (tbinfo);
>>
>> + if (x->toolbar_widget && !x->toolbar_is_packed)
>> + {
>> + gtk_widget_destroy (x->toolbar_widget);
>> + x->toolbar_widget = NULL;
>> + }
>> +
>> /* x_free_frame_resources should have taken care of it */
>> #ifndef HAVE_PGTK
>> #ifdef HAVE_XDBE
>
> LGTM.
Thanks, pushed.
Just to clarify why I suspect this is more important than it looks: on
the feature/igc branch, a leak like this means the frame and all objects
referenced by it will become unfreeable. The problem is not the GTK
memory usage, it's that MPS has no way of indicating "if this object is
still alive, don't move it" without simultaneously keeping it alive.
(At some point we might allow the frame to be moved even though GTK owns
a pointer to a pointer to it. After the merge...)
>> I think this second patch might also avoid future compiler warnings:
>>
>> diff --git a/src/gtkutil.c b/src/gtkutil.c
>> index 97582a524da..73e9f778c75 100644
>> --- a/src/gtkutil.c
>> +++ b/src/gtkutil.c
>> @@ -6123,8 +6123,7 @@ free_frame_tool_bar (struct frame *f)
>> else
>> gtk_widget_destroy (x->toolbar_widget);
>>
>> - x->toolbar_widget = 0;
>> - x->toolbar_widget = 0;
>> + x->toolbar_widget = NULL;
>> x->toolbar_is_packed = false;
>
> 0 as the rhs of an assignment to a pointer variable is taken for a NULL
> pointer, so there's no issue with the existing code. Indeed on many
> systems NULL is simply defined to 0.
The issue with the old code (I've pushed this part by now) was the
duplicated assignment. I think compilers will start to warn about that
much sooner than about the correct (if very, very slightly deprecated)
usage of plain 0 here.
Pip
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-22 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-22 1:06 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-01 23:31 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 21:41 ` Stefan Kangas
2 siblings, 0 replies; 10+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-01 23:31 UTC (permalink / raw)
To: Po Lu; +Cc: 75636-done
Pip Cet <pipcet@protonmail.com> writes:
> "Po Lu" <luangruo@yahoo.com> writes:
>
>>> commit 5ed4aaa986dbf75f8565f4d8cdd3d1d1b38b6142 (HEAD)
>>> Author: Pip Cet <pipcet@protonmail.com>
>>>
>>> Destroy GTK tool bar widget if it was never attached (bug#75636)
>>>
>>> * src/gtkutil.c (xg_free_frame_widgets): Call gtk_widget_destroy on an
>>> unpacked toolbar widget.
>>>
>>> diff --git a/src/gtkutil.c b/src/gtkutil.c
>>> index 0e9dd4dfe11..97582a524da 100644
>>> --- a/src/gtkutil.c
>>> +++ b/src/gtkutil.c
>>> @@ -1885,6 +1885,12 @@ xg_free_frame_widgets (struct frame *f)
>>> if (tbinfo)
>>> xfree (tbinfo);
>>>
>>> + if (x->toolbar_widget && !x->toolbar_is_packed)
>>> + {
>>> + gtk_widget_destroy (x->toolbar_widget);
>>> + x->toolbar_widget = NULL;
>>> + }
>>> +
>>> /* x_free_frame_resources should have taken care of it */
>>> #ifndef HAVE_PGTK
>>> #ifdef HAVE_XDBE
>>
>> LGTM.
>
> Thanks, pushed.
While GTK remains very slow due to MPS limitations and the way we work
around them, I'll file a new bug when we have a way around that, and
closing this one. Thanks!
Pip
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#75636: GTK memory leaks
2025-01-22 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-22 1:06 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-01 23:31 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-03 21:41 ` Stefan Kangas
2 siblings, 0 replies; 10+ messages in thread
From: Stefan Kangas @ 2025-02-03 21:41 UTC (permalink / raw)
To: Po Lu, Pip Cet; +Cc: 75636
Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:
> 0 as the rhs of an assignment to a pointer variable is taken for a NULL
> pointer, so there's no issue with the existing code. Indeed on many
> systems NULL is simply defined to 0.
Both are valid C and compilers won't complain, but it is better to use
the correct type. This means using NULL as the rhs for pointers.
Conversely, we should _not_ use NULL as the rhs if not assigning to a
pointer. Compilers will warn about that one, though.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-02-03 21:41 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-17 20:15 bug#75636: GTK memory leaks Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 9:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-18 11:49 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-19 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 11:24 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-21 18:33 ` Stefan Kangas
2025-01-22 0:42 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-22 1:06 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-01 23:31 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 21:41 ` Stefan Kangas
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.