* bug#54656: 29.0.50; [menu] key is not read anymore
@ 2022-03-31 19:41 dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-01 1:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-03-31 19:41 UTC (permalink / raw)
To: 54656
Hi,
After compiling from master I found my [menu] key not usable anymore
within emacs.
It don't show with C-h c
It show in xev
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
of 2022-03-31 built on localhost
Repository revision: 948181df9cbdcc8845fc3662e2007d8e09f48c71
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --build x86_64-linux-gnu --prefix=/opt/emacs
--with-mailutils --with-sound=yes --without-gconf --without-gsettings
--with-x=yes --without-toolkit-scroll-bars --with-x-toolkit=gtk3
--with-json --with-native-compilation --with-xwidgets
build_alias=x86_64-linux-gnu 'CFLAGS=-O2 -Wall ''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG JSON LIBSELINUX
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
SQLITE3 THREADS TIFF X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB
Important settings:
value of $LANG: en_US
locale-coding-system: utf-8
Load-path shadows:
/home/user/.emacs.d/elpa/transient-0.3.7/transient hides /opt/emacs/share/emacs/29.0.50/lisp/transient
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-03-31 19:41 bug#54656: 29.0.50; [menu] key is not read anymore dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-01 1:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-01 21:34 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-02 23:39 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-01 1:20 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656
dal-blazej@onenetbeyond.org writes:
> Hi,
>
> After compiling from master I found my [menu] key not usable anymore
> within emacs.
>
> It don't show with C-h c
> It show in xev
>
What happens if you run Emacs like this?
emacs -q -xrm 'Emacs.useXIM: false'
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-01 1:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-01 21:34 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-02 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-02 23:39 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-01 21:34 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
> What happens if you run Emacs like this?
>
> emacs -q -xrm 'Emacs.useXIM: false'
The key is still not read.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-01 21:34 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-02 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-02 15:51 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-02 1:00 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656
dal-blazej@onenetbeyond.org writes:
> The key is still not read.
Okay, please put a breakpoint here:
/* Common for all keysym input events. */
XSETFRAME (inev.ie.frame_or_window, f);
=======> inev.ie.modifiers
= x_x_to_emacs_modifiers (FRAME_DISPLAY_INFO (f), modifiers);
inev.ie.timestamp = xkey.time;
and show the value of `keysym' when you press the menu key.
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-02 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-02 15:51 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-03 0:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-02 15:51 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
Po Lu <luangruo@yahoo.com> writes:
> Okay, please put a breakpoint here:
>
> /* Common for all keysym input events. */
> XSETFRAME (inev.ie.frame_or_window, f);
> =======> inev.ie.modifiers
> = x_x_to_emacs_modifiers (FRAME_DISPLAY_INFO (f), modifiers);
> inev.ie.timestamp = xkey.time;
>
>
> and show the value of `keysym' when you press the menu key.
Nothing : gdb use the break point for any other key, but not for menu.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-01 1:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-01 21:34 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-02 23:39 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-02 23:39 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
> What happens if you run Emacs like this?
>
> emacs -q -xrm 'Emacs.useXIM: false'
Still no joy.
Is this issue reproductible on another computer ?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-02 15:51 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-03 0:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 0:03 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-03 0:35 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656
dal-blazej@onenetbeyond.org writes:
> Nothing : gdb use the break point for any other key, but not for menu.
Okay, can you place a breakpoint on `x_display_set_last_user_time' and
see if it gets called when you press the menu key?
Thanks in advance.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-03 0:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-04 0:03 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 0:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-04 0:03 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
> Okay, can you place a breakpoint on `x_display_set_last_user_time' and
> see if it gets called when you press the menu key?
Sorry I lack comprehension of the gdb and C.
If I place a breakpoint on :
> static void
> x_display_set_last_user_time (struct x_display_info *dpyinfo, Time time)
> {
> ...
It is called to many time while initiating Emacs and I cannot verify the
keypress. How do I do that the right way ?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-04 0:03 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-04 0:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 9:31 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-04 0:18 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656
dal-blazej@onenetbeyond.org writes:
> Sorry I lack comprehension of the gdb and C.
>
> If I place a breakpoint on :
>
>> static void
>> x_display_set_last_user_time (struct x_display_info *dpyinfo, Time time)
>> {
>> ...
>
> It is called to many time while initiating Emacs and I cannot verify the
> keypress. How do I do that the right way ?
Ah, sorry. Place the breakpoint here instead, inside the function
`handle_one_xevent':
case KeyPress:
==> x_display_set_last_user_time (dpyinfo, event->xkey.time);
ignore_next_mouse_click_timeout = 0;
coding = Qlatin_1;
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-04 0:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-04 9:31 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 11:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-04 9:31 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
It is triggered :
> Thread 1 "emacs" hit Breakpoint 1, handle_one_xevent (dpyinfo=0x55555774f800, event=0x7fffffffd700, finish=0x555555beabb8 <current_finish>, hold_quit=0x7fffffffd970) at xterm.c:5240
> 5240 dpyinfo->last_user_time = time;
> (gdb) s
> 13844 x_display_set_last_user_time (dpyinfo, event->xkey.time);
> (gdb) s
> 0x000055555568a997 in x_display_set_last_user_time (time=119383756, dpyinfo=0x55555774f800) at xterm.c:5240
> 5240 dpyinfo->last_user_time = time;
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-04 9:31 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-04 11:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-21 14:18 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-04 11:09 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656
dal-blazej@onenetbeyond.org writes:
> It is triggered :
>
>> Thread 1 "emacs" hit Breakpoint 1, handle_one_xevent
>> (dpyinfo=0x55555774f800, event=0x7fffffffd700, finish=0x555555beabb8
>> <current_finish>, hold_quit=0x7fffffffd970) at xterm.c:5240
>> 5240 dpyinfo->last_user_time = time;
>> (gdb) s
>> 13844 x_display_set_last_user_time (dpyinfo, event->xkey.time);
>> (gdb) s
>> 0x000055555568a997 in x_display_set_last_user_time (time=119383756, dpyinfo=0x55555774f800) at xterm.c:5240
>> 5240 dpyinfo->last_user_time = time;
I guess what you have to do is to step through each statement until you
find out why it isn't reaching this piece of handle_one_xevent:
#if defined XK_ISO_Lock && defined XK_ISO_Last_Group_Lock
|| (XK_ISO_Lock <= orig_keysym
&& orig_keysym <= XK_ISO_Last_Group_Lock)
#endif
))
{
STORE_KEYSYM_FOR_DEBUG (keysym);
/* make_lispy_event will convert this to a symbolic
key. */
inev.ie.kind = NON_ASCII_KEYSTROKE_EVENT;
inev.ie.code = keysym;
====> goto done_keysym;
}
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-04 11:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-21 14:18 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-22 0:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-21 14:18 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
> I guess what you have to do is to step through each statement until you
> find out why it isn't reaching this piece of handle_one_xevent:
It seems the key is ... initialized to 0 ?
(gdb) p xkey
$13 = {type = 0, serial = 0, send_event = 1466608144,
display = 0x898f22a9e227e100, window = 140737488343872, root = 93824994679155,
subwindow = 0, time = 93824993826130, x = 2, y = 0, x_root = 0, y_root = 0,
state = 0, keycode = 0, same_screen = 0}
(gdb) s
(gdb) p xkey.state
$14 = 0
(gdb) s
x_emacs_to_x_modifiers (dpyinfo=0x555557727a00, state=0) at lisp.h:1155
(gdb) p a
$15 = {i = {0, 1045149306}, d = 1.2904777690891933e-08}
(gdb) s
Fget (symbol=0x0, propname=0xaf80) at lisp.h:747
[...]
(gdb) u
x_emacs_to_x_modifiers (dpyinfo=0x555557727a00, state=0) at xterm.c:9546
(gdb) p tem
$21 = (Lisp_Object) 0x0
[...]
(gdb) n
handle_one_xevent (dpyinfo=0x555557727a00, event=0x7fffffffd5e0,
finish=0x555555beabb8 <current_finish>, hold_quit=0x7fffffffd850)
at xterm.c:13926
(gdb) p xkey.state
$30 = 0
At some point gdb prints
(gpb) n
0x00007ffff760623f in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0
and I am unable to continue my inspection.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-21 14:18 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-22 0:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-22 13:57 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-22 0:51 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656
dal-blazej@onenetbeyond.org writes:
>> I guess what you have to do is to step through each statement until you
>> find out why it isn't reaching this piece of handle_one_xevent:
>
> It seems the key is ... initialized to 0 ?
>
> (gdb) p xkey
> $13 = {type = 0, serial = 0, send_event = 1466608144,
> display = 0x898f22a9e227e100, window = 140737488343872, root = 93824994679155,
> subwindow = 0, time = 93824993826130, x = 2, y = 0, x_root = 0, y_root = 0,
> state = 0, keycode = 0, same_screen = 0}
I think your Emacs is out of date, since this shouldn't be possible if
the breakpoint was set to the location I asked.
> [...]
>
> (gdb) u
> x_emacs_to_x_modifiers (dpyinfo=0x555557727a00, state=0) at xterm.c:9546
>
> (gdb) p tem
> $21 = (Lisp_Object) 0x0
>
> [...]
>
> (gdb) n
> handle_one_xevent (dpyinfo=0x555557727a00, event=0x7fffffffd5e0,
> finish=0x555555beabb8 <current_finish>, hold_quit=0x7fffffffd850)
> at xterm.c:13926
I think your copy of Emacs is very out of date. Please rebuild and try
again.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-22 0:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-22 13:57 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-23 0:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-22 13:57 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
Hi,
Po Lu <luangruo@yahoo.com> writes:
> dal-blazej@onenetbeyond.org writes:
>
>>> I guess what you have to do is to step through each statement until you
>>> find out why it isn't reaching this piece of handle_one_xevent:
>>
>> It seems the key is ... initialized to 0 ?
>>
>> (gdb) p xkey
>> $13 = {type = 0, serial = 0, send_event = 1466608144,
>> display = 0x898f22a9e227e100, window = 140737488343872, root =
>> 93824994679155,
>> subwindow = 0, time = 93824993826130, x = 2, y = 0, x_root = 0, y_root = 0,
>> state = 0, keycode = 0, same_screen = 0}
>
> I think your Emacs is out of date, since this shouldn't be possible if
> the breakpoint was set to the location I asked.
You asked me to find out why this position was not reachable, so I set
breakpoints ahead... Again, setting at the position asked does not trigger.
I have rebuilt today. I have still at some point :
(gdb) n
0x00007ffff760623f in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0
(gdb) n
Cannot find bounds of current function.
...
Setting it to
if (f != 0)
{
==> KeySym keysym, orig_keysym;
/* al%imercury@uunet.uu.net says that making this 81
instead of 80 fixed a bug whereby meta chars made
his Emacs hang.
(gdb) p keysym
$1 = 4596353178100193889
(gdb) p orig_keysym
$2 = <optimized out>
(gdb) p xkey
$6 = {type = 2, serial = 2027, send_event = 0, display = 0x0, window = 0,
root = 0, subwindow = 2, time = 9223372036854775822, x = 0, y = 0, x_root = 0,
y_root = 0, state = 0, keycode = 0, same_screen = 0}
Eventually you may try to reproduce that issue with
$ xdotool key Menu
?
Thanks
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-22 13:57 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-23 0:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-24 19:25 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-23 0:15 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656
dal-blazej@onenetbeyond.org writes:
> You asked me to find out why this position was not reachable, so I set
> breakpoints ahead... Again, setting at the position asked does not trigger.
>
> I have rebuilt today. I have still at some point :
>
> (gdb) n
> 0x00007ffff760623f in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0
> (gdb) n
> Cannot find bounds of current function.
That isn't a problem, though you might want to install debug info for
GTK. You don't have to look in any function other than
handle_one_xevent.
> ...
>
> Setting it to
>
> if (f != 0)
> {
> ==> KeySym keysym, orig_keysym;
> /* al%imercury@uunet.uu.net says that making this 81
> instead of 80 fixed a bug whereby meta chars made
> his Emacs hang.
>
> (gdb) p keysym
> $1 = 4596353178100193889
>
> (gdb) p orig_keysym
> $2 = <optimized out>
You will have to proceed some more, I guess.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-23 0:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-24 19:25 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-25 2:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 17+ messages in thread
From: dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-24 19:25 UTC (permalink / raw)
To: Po Lu; +Cc: 54656
I read "strange behaviour: Emacs ignoring one key on my keyboard," on
emacs-help today and tried.
$ xmodmap -e 'clear Mod4'
The key is now again responsive.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#54656: 29.0.50; [menu] key is not read anymore
2022-04-24 19:25 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-04-25 2:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-04-25 2:10 UTC (permalink / raw)
To: dal-blazej; +Cc: 54656-done
dal-blazej@onenetbeyond.org writes:
> I read "strange behaviour: Emacs ignoring one key on my keyboard," on
> emacs-help today and tried.
>
> $ xmodmap -e 'clear Mod4'
>
> The key is now again responsive.
Then that's intended behavior, not a bug, so I'm closing this bug
report.
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-04-25 2:10 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-03-31 19:41 bug#54656: 29.0.50; [menu] key is not read anymore dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-01 1:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-01 21:34 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-02 1:00 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-02 15:51 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-03 0:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 0:03 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 0:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 9:31 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-04 11:09 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-21 14:18 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-22 0:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-22 13:57 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-23 0:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-24 19:25 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-25 2:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-02 23:39 ` dal-blazej--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
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.