* bug#29347: 27.0.50; C-g doesn't quit minibuffer @ 2017-11-18 3:46 Richard Stallman 2017-11-18 6:17 ` Andreas Schwab ` (3 more replies) 0 siblings, 4 replies; 27+ messages in thread From: Richard Stallman @ 2017-11-18 3:46 UTC (permalink / raw) To: 29347 C-g does not exit the minibuffer. Moreover, when I keep typing C-g, eventually Emacs gets hung. I can get it unhung by sending it SIGTSTP using another terminal. I can't find the command to make gdb send the backtrace to a file. In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.23) of 2017-11-15 built on freetop Repository revision: 52d822f31bc7cb57694c1e209b2d02e5efb8f48c System Description: Trisquel GNU/Linux 7.0, Belenos Recent messages: Saving file /home/rms/outgoing/out-17... Wrote /home/rms/outgoing/out-17 Mark set Saving file /home/rms/outgoing/out-16... Wrote /home/rms/outgoing/out-16 Mark set [3 times] Saving file /home/rms/outgoing/out-17... Wrote /home/rms/outgoing/out-17 Buffer has unsaved changes; reinitialize it and discard them? (y or n) y Disconnect buffer from visited file? (y or n) y Configured using: 'configure 'CFLAGS=-O0 -g' --with-gnutls=no' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11 Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: RMAIL Minor modes in effect: diff-auto-refine-mode: t shell-dirtrack-mode: t gpm-mouse-mode: t tooltip-mode: t global-eldoc-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Load-path shadows: None found. Features: (shadow emacsbug two-column kmacro iso-transl battery quail help-mode epa-mail etags xref project rmailkwd compare-w diff-mode easy-mmode rmailout url-util shr svg xml dom browse-url shell pcomplete thingatpt grep compile comint ansi-color ring rmailsum dabbrev mailalias misearch multi-isearch qp rmailmm message sendmail rmc puny format-spec rfc822 mml mml-sec epa epg gnus-util mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired dired-loaddefs t-mouse term/linux elec-pair view derived time-date paren cus-start cus-load advice finder-inf package easymenu epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 302080 76236) (symbols 48 25226 12) (miscs 40 2202 2989) (strings 32 48806 9257) (string-bytes 1 1231232) (vectors 16 29076) (vector-slots 8 1398157 226116) (floats 8 95 276) (intervals 56 60145 1270) (buffers 992 67) (heap 1024 30747 3090)) [[[ 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. ]]] -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-18 3:46 bug#29347: 27.0.50; C-g doesn't quit minibuffer Richard Stallman @ 2017-11-18 6:17 ` Andreas Schwab 2017-11-18 6:24 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 0 replies; 27+ messages in thread From: Andreas Schwab @ 2017-11-18 6:17 UTC (permalink / raw) To: Richard Stallman; +Cc: 29347 On Nov 17 2017, Richard Stallman <rms@gnu.org> wrote: > I can't find the command to make gdb send the backtrace to a file. (gdb) help set logging Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-18 3:46 bug#29347: 27.0.50; C-g doesn't quit minibuffer Richard Stallman 2017-11-18 6:17 ` Andreas Schwab @ 2017-11-18 6:24 ` Drew Adams 2017-11-18 8:04 ` Eli Zaretskii 2017-11-20 18:09 ` Mike Gerwitz 3 siblings, 0 replies; 27+ messages in thread From: Drew Adams @ 2017-11-18 6:24 UTC (permalink / raw) To: rms, 29347 > C-g does not exit the minibuffer. > > Moreover, when I keep typing C-g, eventually Emacs gets hung. I can > get it unhung by sending it SIGTSTP using another terminal. FWIW, I believe I've seen the same thing with the 26.1 pretest. I've had to kill the Emacs process when it's happened. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-18 3:46 bug#29347: 27.0.50; C-g doesn't quit minibuffer Richard Stallman 2017-11-18 6:17 ` Andreas Schwab 2017-11-18 6:24 ` Drew Adams @ 2017-11-18 8:04 ` Eli Zaretskii 2017-11-19 3:21 ` Richard Stallman 2017-11-20 18:09 ` Mike Gerwitz 3 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-11-18 8:04 UTC (permalink / raw) To: rms; +Cc: 29347 > From: Richard Stallman <rms@gnu.org> > Date: Fri, 17 Nov 2017 22:46:39 -0500 > > C-g does not exit the minibuffer. > > Moreover, when I keep typing C-g, eventually Emacs gets hung. I can > get it unhung by sending it SIGTSTP using another terminal. Is this in a GUI frame or a TTY frame? If the latter, I cannot reproduce that. (I have no access to a GUI Emacs built from the master branch on GNU/Linux.) Is there any recipe starting from "emacs -Q" that I should try? E.g., what did you type to get into the minibuffer in the first place? does it matter? (I tried "M-x" and "C-x C-f".) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-18 8:04 ` Eli Zaretskii @ 2017-11-19 3:21 ` Richard Stallman 2017-11-19 3:42 ` Eli Zaretskii 2017-11-19 18:09 ` Richard Stallman 0 siblings, 2 replies; 27+ messages in thread From: Richard Stallman @ 2017-11-19 3:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 29347 [[[ 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. ]]] > > Moreover, when I keep typing C-g, eventually Emacs gets hung. I can > > get it unhung by sending it SIGTSTP using another terminal. > Is this in a GUI frame or a TTY frame? If the latter, I cannot > reproduce that. (I have no access to a GUI Emacs built from the > master branch on GNU/Linux.) It is from a tty. I just tried to make this fail starting from emacs -Q and couldn't do so. The initial C-g failure, not quitting out of the minibuffer, doesn't happen right after startup. However, once C-g fails to quit, it continues failing reliably. And it fails regardless of the purpose of the minibuffer. I learned not to type C-g to get out of a minibuffer. First I tried giving operands that would be meaningless. Then I thought of using C-]. As a result of this change in my usage, it does not get hung. But the bug is still there. If I can make it fail again, I will send a backtrace. ISTR that at least once Emacs was in a state where C-g did not turn off region highlighting. I suspect that is the same bug, appearing in a different way. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 3:21 ` Richard Stallman @ 2017-11-19 3:42 ` Eli Zaretskii 2017-11-19 8:33 ` Andreas Schwab 2017-11-20 2:55 ` Richard Stallman 2017-11-19 18:09 ` Richard Stallman 1 sibling, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-11-19 3:42 UTC (permalink / raw) To: rms; +Cc: 29347 > From: Richard Stallman <rms@gnu.org> > CC: 29347@debbugs.gnu.org > Date: Sat, 18 Nov 2017 22:21:23 -0500 > > I just tried to make this fail starting from emacs -Q > and couldn't do so. The initial C-g failure, not quitting out > of the minibuffer, doesn't happen right after startup. > > However, once C-g fails to quit, it continues failing reliably. > And it fails regardless of the purpose of the minibuffer. > > I learned not to type C-g to get out of a minibuffer. > First I tried giving operands that would be meaningless. > Then I thought of using C-]. Did you try "C-x o"? If that works, then it's not a bug, it means you've entered recursive exit in the minibuffer in some way. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 3:42 ` Eli Zaretskii @ 2017-11-19 8:33 ` Andreas Schwab 2017-11-19 15:44 ` Eli Zaretskii 2017-11-20 2:55 ` Richard Stallman 1 sibling, 1 reply; 27+ messages in thread From: Andreas Schwab @ 2017-11-19 8:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 29347, rms On Nov 19 2017, Eli Zaretskii <eliz@gnu.org> wrote: > Did you try "C-x o"? If that works, then it's not a bug, it means > you've entered recursive exit in the minibuffer in some way. Recusive edit will be indicated in the mode line, and C-g will exit it in the minibuffer. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 8:33 ` Andreas Schwab @ 2017-11-19 15:44 ` Eli Zaretskii 2017-11-19 17:21 ` Andreas Schwab 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-11-19 15:44 UTC (permalink / raw) To: Andreas Schwab; +Cc: 29347, rms > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: rms@gnu.org, 29347@debbugs.gnu.org > Date: Sun, 19 Nov 2017 09:33:10 +0100 > > On Nov 19 2017, Eli Zaretskii <eliz@gnu.org> wrote: > > > Did you try "C-x o"? If that works, then it's not a bug, it means > > you've entered recursive exit in the minibuffer in some way. > > Recusive edit will be indicated in the mode line, and C-g will exit it > in the minibuffer. I meant enable-recursive-minibuffers, which AFAIK doesn't have any indications. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 15:44 ` Eli Zaretskii @ 2017-11-19 17:21 ` Andreas Schwab 2017-11-19 17:51 ` Eli Zaretskii [not found] ` <<83o9nydun1.fsf@gnu.org> 0 siblings, 2 replies; 27+ messages in thread From: Andreas Schwab @ 2017-11-19 17:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 29347, rms On Nov 19 2017, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Andreas Schwab <schwab@linux-m68k.org> >> Cc: rms@gnu.org, 29347@debbugs.gnu.org >> Date: Sun, 19 Nov 2017 09:33:10 +0100 >> >> On Nov 19 2017, Eli Zaretskii <eliz@gnu.org> wrote: >> >> > Did you try "C-x o"? If that works, then it's not a bug, it means >> > you've entered recursive exit in the minibuffer in some way. >> >> Recusive edit will be indicated in the mode line, and C-g will exit it >> in the minibuffer. > > I meant enable-recursive-minibuffers, which AFAIK doesn't have any > indications. A recursive minibuffer can be exited like an ordinary minibuffer, and exiting it will return to the buffer from where you entered it. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 17:21 ` Andreas Schwab @ 2017-11-19 17:51 ` Eli Zaretskii [not found] ` <<83o9nydun1.fsf@gnu.org> 1 sibling, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-11-19 17:51 UTC (permalink / raw) To: Andreas Schwab; +Cc: 29347, rms > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: rms@gnu.org, 29347@debbugs.gnu.org > Date: Sun, 19 Nov 2017 18:21:16 +0100 > > > I meant enable-recursive-minibuffers, which AFAIK doesn't have any > > indications. > > A recursive minibuffer can be exited like an ordinary minibuffer, and > exiting it will return to the buffer from where you entered it. And that buffer to which you return is also a minibuffer. IOW, if you are N levels deep in a recursive minibuffer, you cannot exit it until you type C-g N times. This could be perceived as "C-g doesn't quit the minibuffer". I'm not saying this is what happened, I'm just trying to think about every possible situation which could have been interpreted that way. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <<83o9nydun1.fsf@gnu.org>]
* bug#29347: 27.0.50; C-g doesn't quit minibuffer [not found] ` <<83o9nydun1.fsf@gnu.org> @ 2017-11-19 19:11 ` Drew Adams 2017-11-20 2:56 ` Richard Stallman 0 siblings, 1 reply; 27+ messages in thread From: Drew Adams @ 2017-11-19 19:11 UTC (permalink / raw) To: Eli Zaretskii, Andreas Schwab; +Cc: 29347, rms > > > I meant enable-recursive-minibuffers, which AFAIK doesn't have any > > > indications. > > > > A recursive minibuffer can be exited like an ordinary minibuffer, and > > exiting it will return to the buffer from where you entered it. > > And that buffer to which you return is also a minibuffer. IOW, if you > are N levels deep in a recursive minibuffer, you cannot exit it until > you type C-g N times. This could be perceived as "C-g doesn't quit > the minibuffer". Clearly C-g _did_ quit the current minibuffer, in that scenario. If you are in the Nth minibuffer then hitting C-g N times quits N minibuffers - you are no longer in any minibuffer. (To quit all minibuffers you can use C-].) I don't think that's what the problem reported refers to. That's the normal behavior, and it always has been. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 19:11 ` Drew Adams @ 2017-11-20 2:56 ` Richard Stallman 0 siblings, 0 replies; 27+ messages in thread From: Richard Stallman @ 2017-11-20 2:56 UTC (permalink / raw) To: Drew Adams; +Cc: schwab, 29347 [[[ 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 don't enable recursive minibuffers, so my problem wasn't about them. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 3:42 ` Eli Zaretskii 2017-11-19 8:33 ` Andreas Schwab @ 2017-11-20 2:55 ` Richard Stallman 1 sibling, 0 replies; 27+ messages in thread From: Richard Stallman @ 2017-11-20 2:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 29347 [[[ 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 learned not to type C-g to get out of a minibuffer. > > First I tried giving operands that would be meaningless. > > Then I thought of using C-]. > Did you try "C-x o"? I don't remember whether I tried that at the time this was failing. It hasn't failed again since the day I noticed it. Maybe some change has fixed the problem. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-19 3:21 ` Richard Stallman 2017-11-19 3:42 ` Eli Zaretskii @ 2017-11-19 18:09 ` Richard Stallman 1 sibling, 0 replies; 27+ messages in thread From: Richard Stallman @ 2017-11-19 18:09 UTC (permalink / raw) To: eliz, 29347; +Cc: rms [[[ 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 have not seen C-g fail again. Strange, because I started Emacs repeatedly and saw the problem. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-18 3:46 bug#29347: 27.0.50; C-g doesn't quit minibuffer Richard Stallman ` (2 preceding siblings ...) 2017-11-18 8:04 ` Eli Zaretskii @ 2017-11-20 18:09 ` Mike Gerwitz 2017-11-20 18:36 ` Eli Zaretskii 2017-11-20 21:51 ` Richard Stallman 3 siblings, 2 replies; 27+ messages in thread From: Mike Gerwitz @ 2017-11-20 18:09 UTC (permalink / raw) To: Richard Stallman; +Cc: 29347 [-- Attachment #1: Type: text/plain, Size: 8620 bytes --] On Fri, Nov 17, 2017 at 22:46:39 -0500, Richard Stallman wrote: > C-g does not exit the minibuffer. > > Moreover, when I keep typing C-g, eventually Emacs gets hung. I can > get it unhung by sending it SIGTSTP using another terminal. Yes, I get this as well on 26.0.90. I've been meaning to report this for just over a week, but I hadn't gotten around to it. I can reproduce it simply with `emacs -Q -nsl -nw' (it must be a TTY; GUI emacs does not suffer from this bug): quickly press `C-f C-f C-g'. The message "Command attempted to use minibuffer while in a minibuffer" will display. If C-g is pressed while it is still visible, emacs completely hangs. In the past it seemed like I could issue SIGSHUP and it would stop whatever it was doing, but usually it kills emacs. If it doesn't, then `C-g' stops working until restart. > I can't find the command to make gdb send the backtrace to a file. (gdb) bt #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007f778224c649 in _L_lock_909 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f778224c470 in __GI___pthread_mutex_lock (mutex=0xbd9960 <global_lock>) at ../nptl/pthread_mutex_lock.c:79 #3 0x00000000005c22c5 in sys_mutex_lock (mutex=mutex@entry=0xbd9960 <global_lock>) at systhread.c:106 #4 0x00000000005c1a95 in acquire_global_lock (self=0xbd9988 <main_thread>) at thread.c:100 #5 really_call_select (arg=0x7ffcfc8f6910) at thread.c:576 #6 0x00000000005c2057 in thread_select (func=<optimized out>, max_fds=max_fds@entry=7, rfds=rfds@entry=0x7ffcfc8f69d0, wfds=wfds@entry=0x7ffcfc8f6a50, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffcfc8f6fe0, sigmask=sigmask@entry=0x0) at thread.c:595 #7 0x00000000005de450 in xg_select (fds_lim=7, rfds=rfds@entry=0x7ffcfc8f70d0, wfds=wfds@entry=0x7ffcfc8f7150, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffcfc8f6fe0, sigmask=sigmask@entry=0x0) at xgselect.c:117 #8 0x00000000005a4fc5 in wait_reading_process_output (time_limit=time_limit@entry=2, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0) at process.c:5375 #9 0x0000000000422c72 in sit_for (timeout=<optimized out>, reading=reading@entry=false, display_option=display_option@entry=2) at dispnew.c:5793 #10 0x00000000004fe73e in command_loop_1 () at keyboard.c:1340 #11 0x0000000000562d14 in internal_condition_case (bfun=bfun@entry=0x4fdb60 <command_loop_1>, handlers=handlers@entry=21072, hfun=hfun@entry=0x4f4590 <cmd_error>) at eval.c:1332 #12 0x00000000004ef92c in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1110 #13 0x0000000000562cc4 in internal_catch (tag=tag@entry=21744, func=func@entry=0x4ef910 <command_loop_2>, arg=arg@entry=0) at eval.c:1097 #14 0x00000000004ef89a in command_loop () at keyboard.c:1081 #15 0x00000000004f41c3 in recursive_edit_1 () at keyboard.c:695 #16 0x000000000051cbba in read_minibuf (map=map@entry=21543315, initial=initial@entry=22883060, prompt=prompt@entry=9012828, expflag=<optimized out>, histvar=<optimized out>, histpos=<optimized out>, defalt=defalt@entry=22879220, allow_props=false, inherit_input_method=false) at minibuf.c:685 #17 0x000000000051d3bf in Fread_from_minibuffer (prompt=9012828, initial_contents=22883060, keymap=21543315, read=0, hist=<optimized out>, default_value=22879220, inherit_input_method=0) at minibuf.c:992 #18 0x0000000000565654 in funcall_subr (subr=0x85a6e8 <Sread_from_minibuffer>, numargs=numargs@entry=7, args=args@entry=0x7ffcfc8f7800) at eval.c:2861 #19 0x00000000005646c6 in Ffuncall (nargs=nargs@entry=8, args=args@entry=0x7ffcfc8f77f8) at eval.c:2766 #20 0x000000000059a6f1 in exec_byte_code (bytestr=<optimized out>, vector=9553853, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=72057594037927944, args=<optimized out>, args@entry=0x91c7c0 <pure+771808>) at bytecode.c:629 #21 0x00000000005643cc in funcall_lambda (fun=140724545747065, nargs=72057594037927944, nargs@entry=8, arg_vector=0x91c7c0 <pure+771808>, arg_vector@entry=0x7ffcfc8f79b8) at eval.c:2967 #22 0x0000000000564643 in Ffuncall (nargs=nargs@entry=9, args=args@entry=0x7ffcfc8f79b0) at eval.c:2780 #23 0x000000000051b9d0 in Fcompleting_read (prompt=9012828, collection=4729664, predicate=23040, require_match=4745440, initial_input=22883060, hist=23472, def=22879220, inherit_input_method=0) at minibuf.c:1696 #24 0x0000000000565525 in funcall_subr (subr=0x85a568 <Scompleting_read>, numargs=numargs@entry=7, args=args@entry=0x7ffcfc8f7b70) at eval.c:2866 #25 0x00000000005646c6 in Ffuncall (nargs=nargs@entry=8, args=args@entry=0x7ffcfc8f7b68) at eval.c:2766 #26 0x000000000059a6f1 in exec_byte_code (bytestr=<optimized out>, vector=9547005, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=72057594037927942, args=<optimized out>, args@entry=0x91ad00 <pure+764960>) at bytecode.c:629 #27 0x00000000005643cc in funcall_lambda (fun=140724545748086, nargs=72057594037927942, nargs@entry=6, arg_vector=0x91ad00 <pure+764960>, arg_vector@entry=0x7ffcfc8f7ed0) at eval.c:2967 #28 0x0000000000564643 in Ffuncall (nargs=nargs@entry=7, args=args@entry=0x7ffcfc8f7ec8) at eval.c:2780 #29 0x000000000059a6f1 in exec_byte_code (bytestr=<optimized out>, vector=9546893, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=72057594037927940, args=<optimized out>, args@entry=0x91ac90 <pure+764848>) at bytecode.c:629 #30 0x00000000005643cc in funcall_lambda (fun=140724545748754, nargs=72057594037927940, nargs@entry=4, arg_vector=0x91ac90 <pure+764848>, arg_vector@entry=0x7ffcfc8f8050) at eval.c:2967 #31 0x0000000000564643 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0x7ffcfc8f8048) at eval.c:2780 #32 0x000000000059a6f1 in exec_byte_code (bytestr=<optimized out>, vector=9131805, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=72057594037927938, args=<optimized out>, args@entry=0x8b5720 <pure+349760>) at bytecode.c:629 #33 0x00000000005643cc in funcall_lambda (fun=140724545749110, nargs=72057594037927938, nargs@entry=2, arg_vector=0x8b5720 <pure+349760>, arg_vector@entry=0x7ffcfc8f81a0) at eval.c:2967 #34 0x0000000000564643 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffcfc8f8198) at eval.c:2780 #35 0x000000000059a6f1 in exec_byte_code (bytestr=<optimized out>, vector=9132077, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:629 #36 0x0000000000563c9b in eval_sub (form=form@entry=9131995) at eval.c:2237 #37 0x0000000000567680 in Feval (form=form@entry=9131995, lexical=<optimized out>) at eval.c:2051 #38 0x0000000000560888 in Fcall_interactively (function=4338912, record_flag=0, keys=12823093) at callint.c:357 #39 0x00000000005646c6 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7ffcfc8f8518) at eval.c:2766 #40 0x000000000059a6f1 in exec_byte_code (bytestr=<optimized out>, vector=9587005, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs@entry=72057594037927937, args=<optimized out>, args@entry=0x924940 <pure+804960>) at bytecode.c:629 #41 0x00000000005643cc in funcall_lambda (fun=140724545750475, nargs=72057594037927937, nargs@entry=1, arg_vector=0x924940 <pure+804960>, arg_vector@entry=0x7ffcfc8f8718) at eval.c:2967 #42 0x0000000000564643 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffcfc8f8710) at eval.c:2780 #43 0x000000000056476a in call1 (fn=fn@entry=16128, arg1=<optimized out>) at eval.c:2617 #44 0x00000000004fdf4d in command_loop_1 () at keyboard.c:1482 #45 0x0000000000562d14 in internal_condition_case (bfun=bfun@entry=0x4fdb60 <command_loop_1>, handlers=handlers@entry=21072, hfun=hfun@entry=0x4f4590 <cmd_error>) at eval.c:1332 #46 0x00000000004ef92c in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1110 #47 0x0000000000562cc4 in internal_catch (tag=tag@entry=50928, func=func@entry=0x4ef910 <command_loop_2>, arg=arg@entry=0) at eval.c:1097 #48 0x00000000004ef8e7 in command_loop () at keyboard.c:1089 #49 0x00000000004f41c3 in recursive_edit_1 () at keyboard.c:695 #50 0x00000000004f44d5 in Frecursive_edit () at keyboard.c:766 #51 0x0000000000419093 in main (argc=3, argv=0x7ffcfc8f8af8) at emacs.c:1713 -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-20 18:09 ` Mike Gerwitz @ 2017-11-20 18:36 ` Eli Zaretskii 2017-11-20 20:26 ` Mike Gerwitz 2017-11-20 21:51 ` Richard Stallman 1 sibling, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-11-20 18:36 UTC (permalink / raw) To: Mike Gerwitz; +Cc: 29347, rms > From: Mike Gerwitz <mtg@gnu.org> > Date: Mon, 20 Nov 2017 13:09:06 -0500 > Cc: 29347@debbugs.gnu.org > > I can reproduce it simply with `emacs -Q -nsl -nw' (it must be a TTY; > GUI emacs does not suffer from this bug): quickly press `C-f C-f C-g'. Do you mean "C-x C-f C-g"? > The message "Command attempted to use minibuffer while in a minibuffer" > will display. If C-g is pressed while it is still visible, emacs > completely hangs. I cannot reproduce this with the current emacs-26 branch. Can you try that branch? Thanks. P.S. I'm not at all sure this is the same problem that Richard reported. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-20 18:36 ` Eli Zaretskii @ 2017-11-20 20:26 ` Mike Gerwitz 2017-11-24 16:17 ` Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Mike Gerwitz @ 2017-11-20 20:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 29347, rms [-- Attachment #1: Type: text/plain, Size: 808 bytes --] On Mon, Nov 20, 2017 at 20:36:38 +0200, Eli Zaretskii wrote: >> I can reproduce it simply with `emacs -Q -nsl -nw' (it must be a TTY; >> GUI emacs does not suffer from this bug): quickly press `C-f C-f C-g'. > > Do you mean "C-x C-f C-g"? I'm sorry, I meant `C-x C-f C-x C-f C-g` (attempt a recursive minibuffer). I was in a rush typing the original message. > I cannot reproduce this with the current emacs-26 branch. Can you try > that branch? I'm at work but I'll give that a try tonight. > P.S. I'm not at all sure this is the same problem that Richard > reported. If it isn't I'll be happy to open a new bug. Lmk. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-20 20:26 ` Mike Gerwitz @ 2017-11-24 16:17 ` Eli Zaretskii 2017-11-24 21:14 ` Eli Zaretskii 2017-11-27 4:48 ` Mike Gerwitz 0 siblings, 2 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-11-24 16:17 UTC (permalink / raw) To: Mike Gerwitz; +Cc: 29370, 29347, rms > From: Mike Gerwitz <mtg@gnu.org> > Cc: rms@gnu.org, 29347@debbugs.gnu.org > Date: Mon, 20 Nov 2017 15:26:36 -0500 > > On Mon, Nov 20, 2017 at 20:36:38 +0200, Eli Zaretskii wrote: > >> I can reproduce it simply with `emacs -Q -nsl -nw' (it must be a TTY; > >> GUI emacs does not suffer from this bug): quickly press `C-f C-f C-g'. > > > > Do you mean "C-x C-f C-g"? > > I'm sorry, I meant `C-x C-f C-x C-f C-g` (attempt a recursive > minibuffer). I was in a rush typing the original message. I think I fixed the problem which caused Emacs to hang in this particular scenario, but I'm not sure Richard is seeing the same problem. The change I installed on the emacs-26 branch is below; Richard, please try applying it, and see if your problems go away. diff --git a/src/thread.c b/src/thread.c index c03cdda..1ded8f5 100644 --- a/src/thread.c +++ b/src/thread.c @@ -97,7 +97,12 @@ post_acquire_global_lock (struct thread_state *self) static void acquire_global_lock (struct thread_state *self) { - sys_mutex_lock (&global_lock); + /* If some Lisp was interrupted by C-g while inside pselect, the + signal handler could have called maybe_reacquire_global_lock, in + which case we are already holding the lock and shouldn't try + taking it again, or else we will hang forever. */ + if (!(self && self->not_holding_lock)) + sys_mutex_lock (&global_lock); post_acquire_global_lock (self); } ^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-24 16:17 ` Eli Zaretskii @ 2017-11-24 21:14 ` Eli Zaretskii 2017-11-24 21:41 ` Eli Zaretskii 2017-11-27 4:48 ` Mike Gerwitz 1 sibling, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-11-24 21:14 UTC (permalink / raw) To: mtg; +Cc: 29370, 29347, rms > Date: Fri, 24 Nov 2017 18:17:58 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 29370@debbugs.gnu.org, 29347@debbugs.gnu.org, rms@gnu.org > > I think I fixed the problem which caused Emacs to hang in this > particular scenario, but I'm not sure Richard is seeing the same > problem. The change I installed on the emacs-26 branch is below; > Richard, please try applying it, and see if your problems go away. Sorry, wrong patch. Please use the one below instead. diff --git a/src/thread.c b/src/thread.c index c03cdda..1ded8f5 100644 --- a/src/thread.c +++ b/src/thread.c @@ -97,7 +97,12 @@ post_acquire_global_lock (struct thread_state *self) static void acquire_global_lock (struct thread_state *self) { - sys_mutex_lock (&global_lock); + /* If some Lisp was interrupted by C-g while inside pselect, the + signal handler could have called maybe_reacquire_global_lock, in + which case we are already holding the lock and shouldn't try + taking it again, or else we will hang forever. */ + if (!(self && !self->not_holding_lock)) + sys_mutex_lock (&global_lock); post_acquire_global_lock (self); } ^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-24 21:14 ` Eli Zaretskii @ 2017-11-24 21:41 ` Eli Zaretskii 2017-11-25 23:16 ` bug#29370: " Richard Stallman 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-11-24 21:41 UTC (permalink / raw) To: mtg; +Cc: 29370, 29347, rms > Date: Fri, 24 Nov 2017 23:14:16 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 29370@debbugs.gnu.org, 29347@debbugs.gnu.org, rms@gnu.org > > > Date: Fri, 24 Nov 2017 18:17:58 +0200 > > From: Eli Zaretskii <eliz@gnu.org> > > Cc: 29370@debbugs.gnu.org, 29347@debbugs.gnu.org, rms@gnu.org > > > > I think I fixed the problem which caused Emacs to hang in this > > particular scenario, but I'm not sure Richard is seeing the same > > problem. The change I installed on the emacs-26 branch is below; > > Richard, please try applying it, and see if your problems go away. > > Sorry, wrong patch. Please use the one below instead. Sorry again, that was not the best idea. Here is a better patch: diff --git a/src/thread.c b/src/thread.c index 9e799ce..dd46681 100644 --- a/src/thread.c +++ b/src/thread.c @@ -578,8 +573,15 @@ really_call_select (void *arg) sa->timeout, sa->sigmask); block_interrupt_signal (&oldset); - acquire_global_lock (self); - self->not_holding_lock = 0; + /* If we were interrupted by C-g while inside sa->func above, the + signal handler could have called maybe_reacquire_global_lock, in + which case we are already holding the lock and shouldn't try + taking it again, or else we will hang forever. */ + if (self->not_holding_lock) + { + acquire_global_lock (self); + self->not_holding_lock = 0; + } restore_signal_mask (&oldset); } ^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#29370: bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-24 21:41 ` Eli Zaretskii @ 2017-11-25 23:16 ` Richard Stallman 0 siblings, 0 replies; 27+ messages in thread From: Richard Stallman @ 2017-11-25 23:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 29370, mtg, 29347 [[[ 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. ]]] > block_interrupt_signal (&oldset); > - acquire_global_lock (self); > - self->not_holding_lock = 0; > + /* If we were interrupted by C-g while inside sa->func above, the > + signal handler could have called maybe_reacquire_global_lock, in > + which case we are already holding the lock and shouldn't try > + taking it again, or else we will hang forever. */ > + if (self->not_holding_lock) > + { > + acquire_global_lock (self); > + self->not_holding_lock = 0; > + } > restore_signal_mask (&oldset); I am running with this patch, and I will report the results. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-24 16:17 ` Eli Zaretskii 2017-11-24 21:14 ` Eli Zaretskii @ 2017-11-27 4:48 ` Mike Gerwitz 2017-11-27 16:16 ` Eli Zaretskii 2017-11-27 23:28 ` bug#29370: " Richard Stallman 1 sibling, 2 replies; 27+ messages in thread From: Mike Gerwitz @ 2017-11-27 4:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 29370, 29347, rms [-- Attachment #1: Type: text/plain, Size: 601 bytes --] On Fri, Nov 24, 2017 at 18:17:58 +0200, Eli Zaretskii wrote: > I think I fixed the problem which caused Emacs to hang in this > particular scenario, but I'm not sure Richard is seeing the same > problem. The change I installed on the emacs-26 branch is below; > Richard, please try applying it, and see if your problems go away. The issue has been fixed on the current emacs-26 branch (6ec5d49). Thanks for the quick fix, Eli! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-27 4:48 ` Mike Gerwitz @ 2017-11-27 16:16 ` Eli Zaretskii 2017-11-27 23:28 ` bug#29370: " Richard Stallman 1 sibling, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-11-27 16:16 UTC (permalink / raw) To: Mike Gerwitz; +Cc: 29370, 29347, rms > From: Mike Gerwitz <mtg@gnu.org> > Cc: rms@gnu.org, 29347@debbugs.gnu.org, 29370@debbugs.gnu.org > Date: Sun, 26 Nov 2017 23:48:51 -0500 > > On Fri, Nov 24, 2017 at 18:17:58 +0200, Eli Zaretskii wrote: > > I think I fixed the problem which caused Emacs to hang in this > > particular scenario, but I'm not sure Richard is seeing the same > > problem. The change I installed on the emacs-26 branch is below; > > Richard, please try applying it, and see if your problems go away. > > The issue has been fixed on the current emacs-26 branch > (6ec5d49). Thanks for the quick fix, Eli! Thanks for testing. This scenario was simple enough to understand what was wrong. I just hope this also solves Richard's problems. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29370: bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-27 4:48 ` Mike Gerwitz 2017-11-27 16:16 ` Eli Zaretskii @ 2017-11-27 23:28 ` Richard Stallman 2017-11-28 3:33 ` Eli Zaretskii 1 sibling, 1 reply; 27+ messages in thread From: Richard Stallman @ 2017-11-27 23:28 UTC (permalink / raw) To: Mike Gerwitz; +Cc: 29370, 29347 [[[ 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 have not noticed that problem since installing the change. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29370: bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-27 23:28 ` bug#29370: " Richard Stallman @ 2017-11-28 3:33 ` Eli Zaretskii 2017-12-01 8:37 ` bug#29347: " Eli Zaretskii 0 siblings, 1 reply; 27+ messages in thread From: Eli Zaretskii @ 2017-11-28 3:33 UTC (permalink / raw) To: rms; +Cc: 29370, mtg, 29347 > From: Richard Stallman <rms@gnu.org> > CC: eliz@gnu.org, 29347@debbugs.gnu.org, 29370@debbugs.gnu.org > Date: Mon, 27 Nov 2017 18:28:57 -0500 > > I have not noticed that problem since installing the change. Good to know, thanks. I will close the bug in a few days, if not new issues like that come up. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: bug#29370: bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-28 3:33 ` Eli Zaretskii @ 2017-12-01 8:37 ` Eli Zaretskii 0 siblings, 0 replies; 27+ messages in thread From: Eli Zaretskii @ 2017-12-01 8:37 UTC (permalink / raw) To: rms; +Cc: 29370-done, mtg, 29347-done > Date: Tue, 28 Nov 2017 05:33:46 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 29370@debbugs.gnu.org, mtg@gnu.org, 29347@debbugs.gnu.org > > > From: Richard Stallman <rms@gnu.org> > > CC: eliz@gnu.org, 29347@debbugs.gnu.org, 29370@debbugs.gnu.org > > Date: Mon, 27 Nov 2017 18:28:57 -0500 > > > > I have not noticed that problem since installing the change. > > Good to know, thanks. I will close the bug in a few days, if not new > issues like that come up. Nothing new, so I'm closing these bugs. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#29347: 27.0.50; C-g doesn't quit minibuffer 2017-11-20 18:09 ` Mike Gerwitz 2017-11-20 18:36 ` Eli Zaretskii @ 2017-11-20 21:51 ` Richard Stallman 1 sibling, 0 replies; 27+ messages in thread From: Richard Stallman @ 2017-11-20 21:51 UTC (permalink / raw) To: Mike Gerwitz; +Cc: 29347 [[[ 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. ]]] Thanks for investigating this. Having a reproducible case means it will get fixed. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <<E1eFu5X-0002CK-7x@fencepost.gnu.org>]
end of thread, other threads:[~2017-12-01 8:37 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-11-18 3:46 bug#29347: 27.0.50; C-g doesn't quit minibuffer Richard Stallman 2017-11-18 6:17 ` Andreas Schwab 2017-11-18 6:24 ` Drew Adams 2017-11-18 8:04 ` Eli Zaretskii 2017-11-19 3:21 ` Richard Stallman 2017-11-19 3:42 ` Eli Zaretskii 2017-11-19 8:33 ` Andreas Schwab 2017-11-19 15:44 ` Eli Zaretskii 2017-11-19 17:21 ` Andreas Schwab 2017-11-19 17:51 ` Eli Zaretskii [not found] ` <<83o9nydun1.fsf@gnu.org> 2017-11-19 19:11 ` Drew Adams 2017-11-20 2:56 ` Richard Stallman 2017-11-20 2:55 ` Richard Stallman 2017-11-19 18:09 ` Richard Stallman 2017-11-20 18:09 ` Mike Gerwitz 2017-11-20 18:36 ` Eli Zaretskii 2017-11-20 20:26 ` Mike Gerwitz 2017-11-24 16:17 ` Eli Zaretskii 2017-11-24 21:14 ` Eli Zaretskii 2017-11-24 21:41 ` Eli Zaretskii 2017-11-25 23:16 ` bug#29370: " Richard Stallman 2017-11-27 4:48 ` Mike Gerwitz 2017-11-27 16:16 ` Eli Zaretskii 2017-11-27 23:28 ` bug#29370: " Richard Stallman 2017-11-28 3:33 ` Eli Zaretskii 2017-12-01 8:37 ` bug#29347: " Eli Zaretskii 2017-11-20 21:51 ` Richard Stallman [not found] <<E1eFu5X-0002CK-7x@fencepost.gnu.org>
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).