From: Matthias Dahl <ml_emacs-lists@binary-island.eu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
Date: Thu, 26 Oct 2017 20:56:03 +0200 [thread overview]
Message-ID: <f60200b1-c303-bbc5-9001-2dfc57ad995a@binary-island.eu> (raw)
In-Reply-To: <831slp98ut.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]
Hello Eli...
On 26/10/17 18:23, Eli Zaretskii wrote:
> AFAIK, post-command-hooks cannot be run while we are in sit-for, but I
> guess this is not relevant to the rest of the description?
This probably comes from server.el (server-visit-files) because Magit
uses emacsclient for some of its magic.
I have attached a backtrace, taken during the hang. Unfortunately it is
from a optimized build (would have needed to recompile just now, and I
am a bit in a hurry) but it at least shows the callstack (more or less)
nicely.
> I understand that this timer calls accept-process-output with its
> argument nil, is that correct? If so, isn't that a bug for a timer to
> do that? Doing that runs the risk of eating up output from some
> subprocess for which the foreground Lisp program is waiting.
I haven't actually checked which timer it is, to be quite honest since I
didn't think of it as a bug at all.
Correct me if I am wrong, calling accept-process-output w/o arguments
is expected to be quite harmless and can be useful. If you specify a
specific process, you will most definitely wait at least as long as
it takes for that process to produce any output.
Nevertheless: If am not completely mistaken, there is no data lost at
all. It is read and passed to the filter function which was registered
by the interested party -- otherwise the default filter will simply
append it to the buffer it belongs to.
The only thing that is lost is that it was ever read at all and thus
an endless wait begins.
> So please point out the timer that does this, because I think that
> timer needs to be fixed.
If you still need that, I will do some digging and try to find it.
> We already record the file descriptors on which we wait for process
> output, see compute_non_keyboard_wait_mask. Once
> wait_reading_process_output exits, it clears these records. So it
> should be possible for us to prevent accept-process-output calls
> issued by such runaway timers from waiting on the descriptors that are
> already "taken": if, when we set the bits in the pselect mask, we find
> that some of the descriptors are already watched by the same thread as
> the current thread, we could exclude them from the pselect mask we are
> setting up. Wouldn't that be a better solution? Because AFAIU, your
> solution just avoids an infinite wait, but doesn't avoid losing the
> process output, because it was read by the wrong Lisp code. Right?
Hm... at the moment I don't see where data is lost with my solution.
Maybe I am being totally blind and making a fool out of myself but I
honestly don't see it.
What you suggest could be dangerous as well, depending on how it is
implemented and the circumstances. What fds get excluded in recursive
calls? Only wait_proc ones? Or every one that is watched somewhere up
in the callstack? Depending on what we do, we could end up with an
almost empty list that doesn't get "ready" as easily as one would
have expected by a naked accept-process-output call... and it could thus
potentially stall as well... worst-case, I know.
Just thinking out loud here. I would really need to check this, those
are just my initial thoughts.
> Well, I'd like to eyeball the timer which commits this crime.
If you still do, let me know and I will try to track it down...
So long,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
[-- Attachment #2: emacs-bt.txt --]
[-- Type: text/plain, Size: 10206 bytes --]
#0 0x00007ffff2d49ee3 in __pselect (nfds=<optimized out>, readfds=0x7fffffff8410, writefds=0x7fffffff8490, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>)
at ../sysdeps/unix/sysv/linux/pselect.c:69
#1 0x00000000005c8c6c in really_call_select (arg=0x7fffffff8330) at thread.c:572
#2 0x00000000005c9819 in thread_select (func=<optimized out>, max_fds=max_fds@entry=21, rfds=rfds@entry=0x7fffffff8410, wfds=<optimized out>, efds=efds@entry=0x0,
timeout=timeout@entry=0x7fffffff8a40, sigmask=0x0) at thread.c:595
#3 0x00000000005e2c3b in xg_select (fds_lim=21, rfds=rfds@entry=0x7fffffff8b40, wfds=wfds@entry=0x7fffffff8bc0, efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffff8a40,
sigmask=sigmask@entry=0x0) at xgselect.c:117
#4 0x00000000005aa35d in wait_reading_process_output (time_limit=<optimized out>, nsecs=<optimized out>, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false,
wait_for_cell=..., wait_for_cell@entry=..., wait_proc=0x5874d50, just_wait_proc=0) at process.c:5375
#5 0x00000000005ac2fb in Faccept_process_output (process=..., seconds=..., millisec=..., just_this_one=...) at process.c:4655
#6 0x000000000056aed5 in eval_sub (form=...) at eval.c:2241
#7 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#8 0x000000000056ae14 in eval_sub (form=..., form@entry=...) at eval.c:2183
#9 0x000000000056bd05 in Fwhile (args=...) at eval.c:985
#10 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#11 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#12 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#13 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#14 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#15 0x000000000056b82d in Fcond (args=...) at eval.c:435
#16 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#17 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#18 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#19 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#20 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#21 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#22 0x000000000056c38c in FletX (args=...) at eval.c:900
#23 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#24 0x000000000056b1bd in Fprogn (body=..., body@entry=...) at eval.c:455
#25 0x00000000005625e6 in Fsave_excursion (args=...) at editfns.c:1050
#26 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#27 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#28 0x000000000056b512 in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffff97c0) at eval.c:3042
#29 0x000000000056b6a3 in apply_lambda (fun=..., args=..., count=count@entry=33) at eval.c:2903
#30 0x000000000056ac1a in eval_sub (form=...) at eval.c:2306
#31 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#32 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#33 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#34 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#35 0x000000000056c60b in Flet (args=...) at eval.c:969
#36 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#37 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#38 0x000000000056c60b in Flet (args=...) at eval.c:969
#39 0x000000000056ae14 in eval_sub (form=..., form@entry=...) at eval.c:2183
#40 0x000000000056c9b9 in internal_lisp_condition_case (var=..., bodyform=..., handlers=...) at eval.c:1303
#41 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#42 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#43 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#44 0x000000000056ae14 in eval_sub (form=...) at eval.c:2183
#45 0x000000000056b1bd in Fprogn (body=...) at eval.c:455
#46 0x000000000056b512 in funcall_lambda (fun=..., nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffa228) at eval.c:3042
#47 0x0000000000568bbd in Ffuncall (nargs=1, args=0x7fffffffa220) at eval.c:2780
#48 0x0000000000568c69 in funcall_nil (nargs=<optimized out>, args=<optimized out>) at eval.c:2397
#49 0x000000000056823d in run_hook_with_args (nargs=1, args=0x7fffffffa220, funcall=0x568c60 <funcall_nil>) at eval.c:2574
#50 0x00000000005683d7 in run_hook_with_args (funcall=0x568c60 <funcall_nil>, args=0x7fffffffa220, nargs=1) at eval.c:2524
#51 Frun_hook_with_args (args=0x7fffffffa220, nargs=1) at eval.c:2439
#52 run_hook (hook=...) at eval.c:2587
#53 Frun_hooks (nargs=<optimized out>, args=<optimized out>) at eval.c:2421
#54 0x0000000000568c42 in Ffuncall (nargs=2, args=args@entry=0x7fffffffa310) at eval.c:2766
#55 0x000000000059fa88 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=140737488331568, args=<optimized out>,
args@entry=0x1ffffffa5c8) at bytecode.c:629
#56 0x000000000056b2ae in funcall_lambda (fun=..., nargs=140737488331568, nargs@entry=3, arg_vector=0x1ffffffa5c8, arg_vector@entry=0x7fffffffa5c8) at eval.c:2967
#57 0x0000000000568bbd in Ffuncall (nargs=nargs@entry=4, args=0x7fffffffa5c0) at eval.c:2780
#58 0x000000000056a670 in Fapply (nargs=2, args=0x7fffffffa6d8) at eval.c:2386
#59 0x0000000000568c42 in Ffuncall (nargs=3, args=args@entry=0x7fffffffa6d0) at eval.c:2766
#60 0x000000000059fa88 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=140737488332528, args=<optimized out>,
args@entry=0x1ffffffa948) at bytecode.c:629
#61 0x000000000056b2ae in funcall_lambda (fun=..., nargs=140737488332528, nargs@entry=3, arg_vector=0x1ffffffa948, arg_vector@entry=0x7fffffffa948) at eval.c:2967
#62 0x0000000000568bbd in Ffuncall (nargs=4, args=args@entry=0x7fffffffa940) at eval.c:2780
#63 0x000000000059fa88 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=140737488333160, args=<optimized out>,
args@entry=0x1ffffffac30) at bytecode.c:629
#64 0x000000000056b2ae in funcall_lambda (fun=..., nargs=140737488333160, nargs@entry=7, arg_vector=0x1ffffffac30, arg_vector@entry=0x7fffffffac30) at eval.c:2967
#65 0x0000000000568bbd in Ffuncall (nargs=8, args=args@entry=0x7fffffffac28) at eval.c:2780
#66 0x000000000059fa88 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=140737488333928, args=<optimized out>,
args@entry=0x1ffffffaec0) at bytecode.c:629
#67 0x000000000056b2ae in funcall_lambda (fun=..., nargs=140737488333928, nargs@entry=0, arg_vector=0x1ffffffaec0, arg_vector@entry=0x7fffffffaec0) at eval.c:2967
#68 0x0000000000568bbd in Ffuncall (nargs=1, args=args@entry=0x7fffffffaeb8) at eval.c:2780
#69 0x000000000059fa88 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=140737488334552, args=<optimized out>,
args@entry=0x1ffffffb180) at bytecode.c:629
#70 0x000000000056b2ae in funcall_lambda (fun=..., nargs=140737488334552, nargs@entry=1, arg_vector=0x1ffffffb180, arg_vector@entry=0x7fffffffb180) at eval.c:2967
#71 0x0000000000568bbd in Ffuncall (nargs=2, args=args@entry=0x7fffffffb178) at eval.c:2780
#72 0x000000000059fa88 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=nargs@entry=140737488335352, args=<optimized out>,
args@entry=0x5ffffffb7e8) at bytecode.c:629
#73 0x000000000056b2ae in funcall_lambda (fun=..., nargs=140737488335352, nargs@entry=2, arg_vector=0x5ffffffb7e8, arg_vector@entry=0x7fffffffb7e8) at eval.c:2967
#74 0x0000000000568bbd in Ffuncall (nargs=nargs@entry=3, args=0x7fffffffb7e0) at eval.c:2780
#75 0x000000000056a670 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffffffb8a0) at eval.c:2386
#76 0x000000000056a95c in apply1 (fn=..., arg=...) at eval.c:2602
#77 0x0000000000567e46 in internal_condition_case_1 (bfun=bfun@entry=0x5a2610 <read_process_output_call>, arg=..., handlers=..., handlers@entry=...,
hfun=hfun@entry=0x5a2580 <read_process_output_error_handler>) at eval.c:1356
#78 0x00000000005a28b8 in read_and_dispose_of_process_output (coding=<optimized out>, nbytes=239,
chars=0x7fffffffb940 "-dir /home/matthew/workspace/storage/opensource/llvm-project-unofficial-github-mirror.git/ -current-frame -tty /dev/pts/5 dumb -file /home/matthew/workspace/storage/opensource/llvm-project-unofficial-"..., p=0xbb468f0) at process.c:5998
#79 read_process_output (proc=..., proc@entry=..., channel=channel@entry=20) at process.c:5909
#80 0x00000000005aa5d7 in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true,
wait_for_cell=..., wait_for_cell@entry=..., wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5608
#81 0x00000000004226d0 in sit_for (timeout=..., reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5770
---Type <return> to continue, or q <return> to quit---
#82 0x00000000004ff50c in read_char (commandflag=commandflag@entry=1, map=..., map@entry=..., prev_event=..., used_mouse_menu=used_mouse_menu@entry=0x7fffffffd4bb,
end_time=end_time@entry=0x0) at keyboard.c:2717
#83 0x000000000050025c in read_key_sequence (keybuf=keybuf@entry=0x7fffffffd5c0, prompt=..., prompt@entry=..., dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false,
bufsize=30) at keyboard.c:9147
#84 0x0000000000501d1e in command_loop_1 () at keyboard.c:1368
#85 0x0000000000567dae in internal_condition_case (bfun=bfun@entry=0x501ae0 <command_loop_1>, handlers=..., handlers@entry=..., hfun=hfun@entry=0x4f8380 <cmd_error>)
at eval.c:1332
#86 0x00000000004f3554 in command_loop_2 (ignore=..., ignore@entry=...) at keyboard.c:1110
#87 0x0000000000567d1d in internal_catch (tag=..., tag@entry=..., func=func@entry=0x4f3530 <command_loop_2>, arg=..., arg@entry=...) at eval.c:1097
#88 0x00000000004f34eb in command_loop () at keyboard.c:1089
#89 0x00000000004f7f93 in recursive_edit_1 () at keyboard.c:695
#90 0x00000000004f82b3 in Frecursive_edit () at keyboard.c:766
#91 0x0000000000418a72 in main (argc=<optimized out>, argv=0x7fffffffd978) at emacs.c:1713
next prev parent reply other threads:[~2017-10-26 18:56 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 18:52 wait_reading_process_ouput hangs in certain cases (w/ patches) Matthias Dahl
2017-10-25 14:53 ` Eli Zaretskii
2017-10-26 14:07 ` Matthias Dahl
2017-10-26 16:23 ` Eli Zaretskii
2017-10-26 18:56 ` Matthias Dahl [this message]
2017-10-28 8:20 ` Matthias Dahl
2017-10-28 9:28 ` Eli Zaretskii
2017-10-30 9:48 ` Matthias Dahl
2017-11-03 8:52 ` Matthias Dahl
2017-11-03 9:58 ` Eli Zaretskii
2017-11-04 12:11 ` Eli Zaretskii
2017-11-06 14:15 ` Matthias Dahl
2017-11-06 16:34 ` Eli Zaretskii
2017-11-06 18:24 ` Paul Eggert
2017-11-06 20:17 ` Eli Zaretskii
2017-11-07 14:18 ` Matthias Dahl
2017-11-07 16:40 ` Eli Zaretskii
2017-11-10 14:45 ` Matthias Dahl
2017-11-10 15:25 ` Eli Zaretskii
2017-11-12 21:17 ` Paul Eggert
2017-11-13 3:27 ` Eli Zaretskii
2017-11-13 5:27 ` Paul Eggert
2017-11-13 16:00 ` Eli Zaretskii
2017-11-13 19:42 ` Paul Eggert
2017-11-13 20:12 ` Eli Zaretskii
2017-11-13 14:13 ` Matthias Dahl
2017-11-13 16:10 ` Eli Zaretskii
2017-11-14 15:05 ` Matthias Dahl
2017-11-13 19:44 ` Paul Eggert
2017-11-14 14:58 ` Matthias Dahl
2017-11-14 15:24 ` Paul Eggert
2017-11-14 16:03 ` Eli Zaretskii
2017-11-14 16:23 ` Eli Zaretskii
2017-11-14 21:54 ` Paul Eggert
2017-11-15 14:03 ` Matthias Dahl
2017-11-16 15:37 ` Eli Zaretskii
2017-11-16 16:46 ` Paul Eggert
2017-11-18 14:24 ` Matthias Dahl
2017-11-18 14:51 ` Eli Zaretskii
2017-11-18 17:14 ` Stefan Monnier
2017-11-19 7:07 ` Paul Eggert
2017-11-19 15:42 ` Eli Zaretskii
2017-11-19 17:06 ` Paul Eggert
2017-11-20 15:29 ` Matthias Dahl
2017-11-21 14:44 ` Matthias Dahl
2017-11-21 21:31 ` Clément Pit-Claudel
2017-11-22 14:14 ` Matthias Dahl
2017-11-22 8:55 ` Paul Eggert
2017-11-22 14:33 ` Matthias Dahl
2017-11-24 2:31 ` Stefan Monnier
2017-12-28 17:52 ` Eli Zaretskii
2017-12-04 9:40 ` Matthias Dahl
2018-02-13 14:25 ` Matthias Dahl
2018-02-13 16:56 ` Paul Eggert
2018-02-16 16:01 ` Eli Zaretskii
2018-02-16 16:09 ` Lars Ingebrigtsen
2018-02-16 16:54 ` Lars Ingebrigtsen
2018-02-22 11:45 ` andres.ramirez
2018-02-26 14:39 ` Matthias Dahl
2018-02-26 15:11 ` andrés ramírez
2018-02-26 15:17 ` Lars Ingebrigtsen
2018-02-26 15:29 ` andrés ramírez
2018-02-26 16:52 ` Daniel Colascione
2018-02-26 17:19 ` andrés ramírez
2018-02-26 17:24 ` Daniel Colascione
2018-02-27 1:53 ` Re: andrés ramírez
2018-02-27 9:15 ` wait_reading_process_ouput hangs in certain cases (w/ patches) Matthias Dahl
2018-02-27 12:01 ` Lars Ingebrigtsen
2018-02-27 9:11 ` Matthias Dahl
2018-02-27 11:54 ` andrés ramírez
2018-02-27 15:02 ` Matthias Dahl
2018-02-27 15:13 ` Lars Ingebrigtsen
2018-02-27 15:17 ` Matthias Dahl
2018-02-27 15:19 ` Lars Ingebrigtsen
2018-02-27 15:14 ` Matthias Dahl
2018-02-27 15:17 ` Lars Ingebrigtsen
2018-03-01 10:42 ` Lars Ingebrigtsen
2018-03-01 14:36 ` Matthias Dahl
2018-03-01 15:10 ` andrés ramírez
2018-03-01 16:30 ` T.V Raman
2018-03-01 16:46 ` andrés ramírez
2018-03-01 18:23 ` T.V Raman
2018-03-01 19:13 ` Eli Zaretskii
2018-03-02 20:21 ` andrés ramírez
2018-03-03 7:55 ` Eli Zaretskii
2018-03-05 14:43 ` Matthias Dahl
2018-03-05 14:44 ` Lars Ingebrigtsen
2018-03-05 14:54 ` Matthias Dahl
2018-03-13 9:54 ` Matthias Dahl
2018-03-13 12:35 ` Robert Pluim
2018-03-13 13:40 ` Robert Pluim
2018-03-13 15:10 ` Matthias Dahl
2018-03-13 15:30 ` Robert Pluim
2018-03-13 15:36 ` Dmitry Gutov
2018-03-13 15:46 ` Robert Pluim
2018-03-13 15:56 ` Dmitry Gutov
2018-03-13 16:57 ` Robert Pluim
2018-03-13 18:03 ` Eli Zaretskii
2018-03-13 20:12 ` Robert Pluim
2018-03-14 14:21 ` Matthias Dahl
2018-03-13 16:32 ` Lars Ingebrigtsen
2018-03-14 9:32 ` Matthias Dahl
2018-03-14 14:55 ` Lars Ingebrigtsen
2018-03-31 15:44 ` Lars Ingebrigtsen
2018-04-01 2:05 ` andrés ramírez
2018-06-08 5:11 ` Leo Liu
2018-06-08 6:57 ` Eli Zaretskii
2018-06-08 9:07 ` Leo Liu
2018-03-13 16:12 ` Eli Zaretskii
2018-03-14 4:16 ` Leo Liu
2018-03-14 9:22 ` Robert Pluim
2018-03-15 0:37 ` Leo Liu
2018-03-14 15:09 ` andrés ramírez
2018-03-14 16:45 ` Eli Zaretskii
2018-03-15 1:03 ` Leo Liu
2018-03-15 7:55 ` Robert Pluim
2018-03-14 22:54 ` Stefan Monnier
2018-03-15 1:06 ` Leo Liu
2018-03-14 9:56 ` Matthias Dahl
2018-03-14 12:24 ` Stefan Monnier
2018-03-14 14:34 ` Matthias Dahl
2018-03-14 22:52 ` Stefan Monnier
2018-03-15 15:17 ` Matthias Dahl
2018-03-14 16:43 ` Eli Zaretskii
2018-03-15 14:59 ` Matthias Dahl
2018-06-26 13:36 ` Matthias Dahl
2018-06-26 14:09 ` andrés ramírez
2018-06-27 13:10 ` Matthias Dahl
2018-06-27 15:18 ` Eli Zaretskii
2018-06-28 8:01 ` Matthias Dahl
2018-06-28 13:04 ` Eli Zaretskii
2018-06-28 13:25 ` Matthias Dahl
2018-06-28 16:33 ` Leo Liu
2018-06-28 18:31 ` T.V Raman
2018-07-02 13:27 ` Matthias Dahl
2018-07-02 14:35 ` T.V Raman
2018-07-03 13:27 ` Matthias Dahl
2018-07-03 13:52 ` T. V. Raman
2018-07-03 15:03 ` Stefan Monnier
2018-07-02 13:24 ` Matthias Dahl
2018-07-14 2:27 ` Leo Liu
2018-07-03 13:34 ` Matthias Dahl
2018-07-03 18:57 ` Eli Zaretskii
2018-07-04 7:35 ` Matthias Dahl
2018-07-04 15:11 ` Eli Zaretskii
2018-07-21 9:52 ` Eli Zaretskii
2018-08-07 8:38 ` Matthias Dahl
2018-08-07 17:10 ` Paul Eggert
2018-09-10 8:21 ` Eli Zaretskii
2017-11-07 17:23 ` Stefan Monnier
2017-11-10 14:53 ` Matthias Dahl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f60200b1-c303-bbc5-9001-2dfc57ad995a@binary-island.eu \
--to=ml_emacs-lists@binary-island.eu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).