* bug#26682: 26.0.50; Error at startup with minibuffer-only frame @ 2017-04-27 17:08 Stefan Monnier 2017-04-28 8:56 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Stefan Monnier @ 2017-04-27 17:08 UTC (permalink / raw) To: 26682 Some recent change in `master` has introduced a regression when using my configuration. I can reproduce it with the recipe below: src/emacs -Q --eval '(setq default-frame-alist (quote ((minibuffer . only))))' This launches Emacs but signals an error "Attempt to delete the only frame". Stefan In GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2017-04-27 built on lechazo Repository revision: 79c5ea9911a9aba7db0ba0e367e06507cee2fc02 Windowing system distributor 'The X.Org Foundation', version 11.0.11901000 System Description: Debian GNU/Linux 9.0 (stretch) Recent messages: Entering debugger... Continuing. Error: (error "Unable to activate package ‘ess’. Required package ‘julia-mode-0.3’ is unavailable") Loading /home/monnier/src/elisp/ProofGeneral/generic/proof-site.el (source)...done Loading /home/monnier/etc/emacs/X11.el (source)...done Loading /home/monnier/etc/emacs/custom.el (source)...done Source file ‘/home/monnier/src/emacs/elpa/packages/load-dir/load-dir.el’ newer than byte-compiled file Starting new Ispell process /usr/bin/aspell with american dictionary... For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure -C --enable-checking --with-modules --enable-check-lisp-object-type 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign' PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig' Configured features: XAW3D XPM JPEG TIFF GIF PNG SOUND GPM DBUS GSETTINGS NOTIFY GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 MODULES Important settings: value of $LANG: fr_CH.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: outline-minor-mode: t flyspell-mode: t checkdoc-minor-mode: t electric-pair-mode: t global-reveal-mode: t reveal-mode: t auto-insert-mode: t savehist-mode: t minibuffer-electric-default-mode: t url-handler-mode: t cl-old-struct-compat-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t global-prettify-symbols-mode: t prettify-symbols-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 line-number-mode: t transient-mark-mode: t Load-path shadows: /home/monnier/src/emacs/elpa/packages/svg/svg hides /home/monnier/src/emacs/trunk/lisp/svg /home/monnier/src/emacs/elpa/packages/landmark/landmark hides /home/monnier/src/emacs/trunk/lisp/obsolete/landmark Features: (shadow sort mail-extr emacsbug message subr-x puny dired dired-loaddefs format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils noutline outline easy-mmode flyspell ispell checkdoc thingatpt load-dir elec-pair reveal autoinsert proof-site proof-autoloads cl pg-vars savehist minibuf-eldef disp-table help-mode debug advice info realgud-recursive-autoloads finder-inf url-auth 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 pcase cl-lib bbdb-loaddefs time-date mule-util 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 x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 8 144878 7559) (symbols 24 23944 1) (miscs 20 71 182) (strings 16 37557 5283) (string-bytes 1 1279263) (vectors 8 19171) (vector-slots 4 545328 4402) (floats 8 68 266) (intervals 28 307 0) (buffers 520 12)) ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-27 17:08 bug#26682: 26.0.50; Error at startup with minibuffer-only frame Stefan Monnier @ 2017-04-28 8:56 ` Eli Zaretskii 2017-04-28 17:44 ` martin rudalics 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2017-04-28 8:56 UTC (permalink / raw) To: Stefan Monnier, martin rudalics; +Cc: 26682 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Date: Thu, 27 Apr 2017 13:08:10 -0400 > > > Some recent change in `master` has introduced a regression when using my > configuration. I can reproduce it with the recipe below: > > src/emacs -Q --eval '(setq default-frame-alist (quote ((minibuffer . only))))' > > This launches Emacs but signals an error "Attempt to delete the only > frame". This seems to come from the following part at the beginning of delete_frame: else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force))) { if (NILP (force)) error ("Attempt to delete the sole visible or iconified frame"); else error ("Attempt to delete the only frame"); } The original code there was: if (NILP (force) && !other_visible_frames (f)) error ("Attempt to delete the sole visible or iconified frame"); Martin, why did you decide to disallow frame deletion when the FORCE argument is t? This makes delete-frame violate its documented contract, whereby if FORCE == Qt, the fact that other frames are not visible doesn't count. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-28 8:56 ` Eli Zaretskii @ 2017-04-28 17:44 ` martin rudalics 2017-04-28 18:29 ` Stefan Monnier 2017-04-29 10:30 ` martin rudalics 0 siblings, 2 replies; 10+ messages in thread From: martin rudalics @ 2017-04-28 17:44 UTC (permalink / raw) To: Eli Zaretskii, Stefan Monnier; +Cc: 26682 [-- Attachment #1: Type: text/plain, Size: 6005 bytes --] > This seems to come from the following part at the beginning of > delete_frame: > > else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force))) > { > if (NILP (force)) > error ("Attempt to delete the sole visible or iconified frame"); > else > error ("Attempt to delete the only frame"); > } > > The original code there was: > > if (NILP (force) && !other_visible_frames (f)) > error ("Attempt to delete the sole visible or iconified frame"); > > Martin, why did you decide to disallow frame deletion when the FORCE > argument is t? This makes delete-frame violate its documented > contract, whereby if FORCE == Qt, the fact that other frames are not > visible doesn't count. I probably was confused. One problem I wanted to fix is the following scenario with Emacs 25.2: With emacs -Q evaluate the following four forms in row: (defvar old-frame (selected-frame)) (defvar new-frame (make-frame)) (add-hook 'delete-frame-functions (lambda (f) (delete-frame new-frame))) (delete-frame old-frame) This gets me here: Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c911231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll (gdb) bt #0 0x7c911231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll #1 0x012d28dd in emacs_abort () at w32fns.c:9830 #2 0x01323e14 in w32_reset_fringes () at fringe.c:1777 #3 0x012f1489 in x_delete_display (dpyinfo=0x2b1bc60) at w32term.c:6941 #4 0x012f1247 in x_delete_terminal (terminal=0x1a560b0) at w32term.c:6847 #5 0x01130bbe in Fdelete_terminal (terminal=..., force=...) at terminal.c:390 #6 0x01019d9c in delete_frame (frame=..., force=...) at frame.c:1731 #7 0x0101a55f in Fdelete_frame (frame=..., force=...) at frame.c:1842 #8 0x0121f0c2 in eval_sub (form=...) at eval.c:2174 #9 0x0121e235 in Feval (form=..., lexical=...) at eval.c:1993 #10 0x0122109f in Ffuncall (nargs=3, args=0x82e0e8) at eval.c:2701 #11 0x0127dbf5 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82e690) at bytecode.c:880 #12 0x01221e60 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82e688) at eval.c:2860 #13 0x0122146e in Ffuncall (nargs=2, args=0x82e680) at eval.c:2747 #14 0x0127dbf5 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82ed78) at bytecode.c:880 #15 0x01221e60 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82ed70) at eval.c:2860 #16 0x0122146e in Ffuncall (nargs=2, args=0x82ed68) at eval.c:2747 #17 0x01213432 in Ffuncall_interactively (nargs=2, args=0x82ed68) at callint.c:252 #18 0x01220f0f in Ffuncall (nargs=3, args=0x82ed60) at eval.c:2678 #19 0x0121665e in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:843 #20 0x012210f6 in Ffuncall (nargs=4, args=0x82f1c8) at eval.c:2705 #21 0x0127dbf5 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82f780) at bytecode.c:880 #22 0x01221e60 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82f778) at eval.c:2860 #23 0x0122146e in Ffuncall (nargs=2, args=0x82f770) at eval.c:2747 #24 0x012207bf in call1 (fn=..., arg1=...) at eval.c:2557 #25 0x01151cff in command_loop_1 () at keyboard.c:1479 #26 0x0121bd32 in internal_condition_case (bfun=0x1151233 <command_loop_1>, handlers=..., hfun=0x11504cb <cmd_error>) at eval.c:1314 #27 0x01150ccd in command_loop_2 (ignore=...) at keyboard.c:1107 #28 0x0121aed6 in internal_catch (tag=..., func=0x1150c91 <command_loop_2>, arg=...) at eval.c:1079 #29 0x01150c53 in command_loop () at keyboard.c:1086 #30 0x0114fee3 in recursive_edit_1 () at keyboard.c:692 #31 0x011501a4 in Frecursive_edit () at keyboard.c:763 #32 0x0114d8ba in main (argc=2, argv=0xa32658) at emacs.c:1626 Lisp Backtrace: "delete-frame" (0x82ded0) "eval" (0x82e0f0) "elisp--eval-last-sexp" (0x82e688) "eval-last-sexp" (0x82ed70) "funcall-interactively" (0x82ed68) "call-interactively" (0x82f1d0) "command-execute" (0x82f778) Admittedly calling ‘delete-frame’ from ‘delete-frame-functions’ is not nice. But with child frames and the ‘delete-before’ parameter it would be easy to get a similar crash with a less provocative setup. So I started to check for the existence of other frames twice and be more rigorous. Too rigorous, as Stefan's scenario demonstrates. I attach a presumptive patch which should handle Stefan's setup and also a few ‘make-frame-invisible’ calls which were not handled correctly. Please try it. It needs some further testing before I can commit it. As a matter of fact, I was not able to repeat Stefan's scenario on GNU/Linux - the initial frame was always deleted orderly. But the behavior is easily reproducible on Windows. On Windows, however, even with my patch, one out of ten times starting Emacs with Stefan's command line hangs it with the initial frame visible and I have to quit with C-g. More precisely, it hangs in ‘frame-notice-user-settings’ in the while loop below ;; MS-Windows needs this to avoid inflooping below. (if (eq system-type 'windows-nt) (sit-for 0 t)) ;; If the frame isn't visible yet, wait till it is. ;; If the user has to position the window, ;; Emacs doesn't know its real position until ;; the frame is seen to be visible. (while (not (cdr (assq 'visibility (frame-parameters frame-initial-frame)))) (sleep-for 1)) and it does so always when I run Emacs under GDB. I don't yet know why it hangs: The request to make the frame visible is posted orderly but somehow SET_FRAME_VISIBLE gets never executed. Can you reproduce it? Note also that the patch restores the Emasc 25.2 behavior where deleting the last minibuffer frame with a mouse click raises the "surrogate ..." error. My earlier changes did ‘save-buffers-kill-emacs’ in that case. martin [-- Attachment #2: frame.c.el.diff --] [-- Type: text/plain, Size: 4834 bytes --] diff --git a/lisp/frame.el b/lisp/frame.el index cec2624..8dad63f 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -123,8 +123,6 @@ handle-delete-frame ;; not a child frame. (when (and (not (eq frame-1 frame)) (frame-visible-p frame-1) - (window-live-p (minibuffer-window frame-1)) - (eq (window-frame (minibuffer-window frame-1)) frame-1) (not (frame-parent frame-1)) (not (frame-parameter frame-1 'delete-before))) (throw 'other-frame t)))) diff --git a/src/frame.c b/src/frame.c index 681a245..b108e45 100644 --- a/src/frame.c +++ b/src/frame.c @@ -1560,15 +1560,16 @@ of them (the selected terminal frame) is actually displayed. * Return true if there exists at least one visible or iconified frame * but F. Return false otherwise. * - * Always return false when all remaining frames are either tooltip or - * child frames or frames with a non-nil `delete-before' parameter. If - * INVISIBLE is false, also return false when the minibuffer window of - * all remaining frames is on F. - + * INVISIBLE true means we are called from make_frame_invisible where + * such a frame must be visible or iconified. INVISIBLE nil means we + * are called from delete_frame. In that case FORCE true means that the + * visibility status of such a frame can be ignored. + * * If F is the terminal frame and we are using X, return true if at - * least one X frame exists. */ + * least one X frame exists. + */ static bool -other_frames (struct frame *f, bool invisible) +other_frames (struct frame *f, bool invisible, bool force) { Lisp_Object frames, frame, frame1; struct frame *f1; @@ -1591,23 +1592,20 @@ of them (the selected terminal frame) is actually displayed. x_sync (f1); #endif if (NILP (Fframe_parameter (frame1, Qtooltip)) - /* Tooltips and child frames don't count. */ + /* Tooltips and child frames count neither for + invisibility nor for deletions. */ && !FRAME_PARENT_FRAME (f1) /* Frames with a non-nil `delete-before' parameter don't - count - either they depend on us or they depend on a - frame that we will have to find right here. */ - && NILP (get_frame_param (f1, Qdelete_before)) - /* Frames whose minibuffer window is on F don't count - unless INVISIBLE is set - in that case F is either made - invisible and may be autoraised from such a frame or - the FORCE argument of delete_frame was non-nil. */ - && (invisible || NILP (minibuffer_window) - || !EQ (FRAME_MINIBUF_WINDOW (f1), minibuffer_window)) - /* At least one visible/iconified frame must remain. */ + count for deletions. */ + && (invisible || NILP (get_frame_param (f1, Qdelete_before))) + /* For invisibility and normal deletions, at least one + visible or iconified frame must remain (Bug#26682). */ && (FRAME_VISIBLE_P (f1) || FRAME_ICONIFIED_P (f1) - /* Allow deleting the terminal frame when at least one - X frame exists. */ - || (FRAME_WINDOW_P (f1) && !FRAME_WINDOW_P (f)))) + || (!invisible + && (force + /* Allow deleting the terminal frame when at + least one X frame exists. */ + || (FRAME_WINDOW_P (f1) && !FRAME_WINDOW_P (f)))))) return true; } } @@ -1680,7 +1678,7 @@ of them (the selected terminal frame) is actually displayed. if (!FRAME_LIVE_P (f)) return Qnil; - else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force))) + else if (!EQ (force, Qnoelisp) && !other_frames (f, false, true)) { if (NILP (force)) error ("Attempt to delete the sole visible or iconified frame"); @@ -1752,7 +1750,7 @@ of them (the selected terminal frame) is actually displayed. one. */ if (!FRAME_LIVE_P (f)) return Qnil; - else if (!EQ (force, Qnoelisp) && !other_frames (f, !NILP (force))) + else if (!EQ (force, Qnoelisp) && !other_frames (f, false, true)) { if (NILP (force)) error ("Attempt to delete the sole visible or iconified frame"); @@ -2275,7 +2273,7 @@ of them (the selected terminal frame) is actually displayed. { struct frame *f = decode_live_frame (frame); - if (NILP (force) && !other_frames (f, true)) + if (NILP (force) && !other_frames (f, true, false)) error ("Attempt to make invisible the sole visible or iconified frame"); /* Don't allow minibuf_window to remain on an invisible frame. */ @@ -2878,6 +2876,9 @@ Each element of ALIST has the form (PARM . VALUE), where PARM is a symbol. struct frame *f = decode_live_frame (frame); Lisp_Object prop, val; + if (EQ (alist, Qt)) + return Qnil; + /* I think this should be done with a hook. */ #ifdef HAVE_WINDOW_SYSTEM if (FRAME_WINDOW_P (f)) ^ permalink raw reply related [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-28 17:44 ` martin rudalics @ 2017-04-28 18:29 ` Stefan Monnier 2017-04-30 8:32 ` martin rudalics 2017-04-29 10:30 ` martin rudalics 1 sibling, 1 reply; 10+ messages in thread From: Stefan Monnier @ 2017-04-28 18:29 UTC (permalink / raw) To: martin rudalics; +Cc: 26682 > I attach a presumptive patch which should handle Stefan's setup and also > a few ‘make-frame-invisible’ calls which were not handled correctly. > Please try it. It needs some further testing before I can commit it. It seems to fix the problem. I haven't yet seen any obvious problem with it. IOW so far so good, Stefan ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-28 18:29 ` Stefan Monnier @ 2017-04-30 8:32 ` martin rudalics 2017-04-30 16:14 ` Stefan Monnier 0 siblings, 1 reply; 10+ messages in thread From: martin rudalics @ 2017-04-30 8:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: 26682 > It seems to fix the problem. I haven't yet seen any obvious problem > with it. IOW so far so good, I installed a slightly different version now. If you don't see any problems, please close this bug. Thanks, martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-30 8:32 ` martin rudalics @ 2017-04-30 16:14 ` Stefan Monnier 0 siblings, 0 replies; 10+ messages in thread From: Stefan Monnier @ 2017-04-30 16:14 UTC (permalink / raw) To: martin rudalics; +Cc: 26682-done >> It seems to fix the problem. I haven't yet seen any obvious problem >> with it. IOW so far so good, > I installed a slightly different version now. If you don't see any > problems, please close this bug. Thanks, seems to do the trick here, closing, Stefan ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-28 17:44 ` martin rudalics 2017-04-28 18:29 ` Stefan Monnier @ 2017-04-29 10:30 ` martin rudalics 2017-04-29 10:36 ` Eli Zaretskii 1 sibling, 1 reply; 10+ messages in thread From: martin rudalics @ 2017-04-29 10:30 UTC (permalink / raw) To: Eli Zaretskii, Stefan Monnier; +Cc: 26682 > On Windows, however, even > with my patch, one out of ten times starting Emacs with Stefan's command > line hangs it with the initial frame visible and I have to quit with > C-g. > > More precisely, it hangs in ‘frame-notice-user-settings’ in the while > loop below > > ;; MS-Windows needs this to avoid inflooping below. > (if (eq system-type 'windows-nt) > (sit-for 0 t)) > ;; If the frame isn't visible yet, wait till it is. > ;; If the user has to position the window, > ;; Emacs doesn't know its real position until > ;; the frame is seen to be visible. > (while (not (cdr (assq 'visibility > (frame-parameters frame-initial-frame)))) > (sleep-for 1)) > > and it does so always when I run Emacs under GDB. I don't yet know why > it hangs: The request to make the frame visible is posted orderly but > somehow SET_FRAME_VISIBLE gets never executed. Can you reproduce it? FYI it's caused by WM_MOVE which OT1H is likely counted by the for (count = input_signal_count + 10; input_signal_count < count && !FRAME_VISIBLE_P (f);) loop in x_make_frame_visible and OTOH lacks a SET_FRAME_VISIBLE (f, 1). martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-29 10:30 ` martin rudalics @ 2017-04-29 10:36 ` Eli Zaretskii 2017-04-30 8:32 ` martin rudalics 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2017-04-29 10:36 UTC (permalink / raw) To: martin rudalics; +Cc: 26682, monnier > Date: Sat, 29 Apr 2017 12:30:39 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: 26682@debbugs.gnu.org > > > On Windows, however, even > > with my patch, one out of ten times starting Emacs with Stefan's command > > line hangs it with the initial frame visible and I have to quit with > > C-g. > > > > More precisely, it hangs in ‘frame-notice-user-settings’ in the while > > loop below > > > > ;; MS-Windows needs this to avoid inflooping below. > > (if (eq system-type 'windows-nt) > > (sit-for 0 t)) > > ;; If the frame isn't visible yet, wait till it is. > > ;; If the user has to position the window, > > ;; Emacs doesn't know its real position until > > ;; the frame is seen to be visible. > > (while (not (cdr (assq 'visibility > > (frame-parameters frame-initial-frame)))) > > (sleep-for 1)) > > > > and it does so always when I run Emacs under GDB. I don't yet know why > > it hangs: The request to make the frame visible is posted orderly but > > somehow SET_FRAME_VISIBLE gets never executed. Can you reproduce it? > > FYI it's caused by WM_MOVE which OT1H is likely counted by the > > for (count = input_signal_count + 10; > input_signal_count < count && !FRAME_VISIBLE_P (f);) > > loop in x_make_frame_visible and OTOH lacks a SET_FRAME_VISIBLE (f, 1). I think Stefan's command line has a race condition, that's why it sometimes hangs. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-29 10:36 ` Eli Zaretskii @ 2017-04-30 8:32 ` martin rudalics 2017-04-30 14:16 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: martin rudalics @ 2017-04-30 8:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 26682, monnier > I think Stefan's command line has a race condition, that's why it > sometimes hangs. I'm still not entirely sure about what happened but not making a move frame event when the frame is invisible seems to cure it. The entire input_signal_count rigmarole was removed from xterm.c some time ago, so maybe we should do the same for w32term.c but I have no real idea why it was needed in the first place so I'll rather refrain from doing that. martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26682: 26.0.50; Error at startup with minibuffer-only frame 2017-04-30 8:32 ` martin rudalics @ 2017-04-30 14:16 ` Eli Zaretskii 0 siblings, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2017-04-30 14:16 UTC (permalink / raw) To: martin rudalics; +Cc: 26682, monnier > Date: Sun, 30 Apr 2017 10:32:03 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: monnier@IRO.UMontreal.CA, 26682@debbugs.gnu.org > > The entire input_signal_count rigmarole was removed from xterm.c > some time ago, so maybe we should do the same for w32term.c but I > have no real idea why it was needed in the first place so I'll > rather refrain from doing that. This was removed from xterm.c due to real problems, so let's wait for similar reasons, if they come, before we remove this from w32term.c. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-04-30 16:14 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-04-27 17:08 bug#26682: 26.0.50; Error at startup with minibuffer-only frame Stefan Monnier 2017-04-28 8:56 ` Eli Zaretskii 2017-04-28 17:44 ` martin rudalics 2017-04-28 18:29 ` Stefan Monnier 2017-04-30 8:32 ` martin rudalics 2017-04-30 16:14 ` Stefan Monnier 2017-04-29 10:30 ` martin rudalics 2017-04-29 10:36 ` Eli Zaretskii 2017-04-30 8:32 ` martin rudalics 2017-04-30 14:16 ` Eli Zaretskii
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).