* bug#23842: 24.4; Runaway background process @ 2016-06-24 19:08 Ian Perryman 2016-06-24 20:02 ` bug#23842: Dribble files Ian Perryman ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Ian Perryman @ 2016-06-24 19:08 UTC (permalink / raw) To: 23842 In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-07 on trouble, modified by Debian Windowing system distributor `The XFree86 Project, Inc', version 11.0.40300000 System Description: Debian GNU/Linux 8.2 (jessie) Configured using: `configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Verilog Minor modes in effect: tooltip-mode: t electric-indent-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 blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <help-echo> C-x C-f <backspace> <backspace> <backspace> <backspace> <backspace> <backspace> v e r <tab> m o <tab> <return> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> <Verilog> <Version and FAQ> <help-echo> <help-echo> C-g C-g C-x 1 C-n C-e M-? <help-echo> <down-mouse-1> <mouse-1> C-c C-c <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> <options> <debug-on-quit> M-? <down-mouse-1> <mouse-1> C-g C-g C-g C-a M-x r e p o r t - b u <tab> <return> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Quit [2 times] Type SPC to continue editing. command-execute: The mark is not set now, so there is no region Debug on Quit enabled globally Type SPC to continue editing. Quit [3 times] Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils cus-start cus-load help-mode verilog-mode easymenu compile comint ansi-color ring diff time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer 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 make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) Memory information: ((conses 16 92747 8401) (symbols 48 20320 0) (miscs 40 51 199) (strings 32 16107 4632) (string-bytes 1 458706) (vectors 16 10684) (vector-slots 8 401945 6854) (floats 8 76 476) (intervals 56 254 0) (buffers 960 14) (heap 1024 46181 1524)) This version of Emacs came with You are using verilog-mode 2013-11-05-78e66ba-vpo The problem is reproducible as follows: Open a new buffer called "moo.sv" Paste this text into it without the tags: <start of file> module moo.sv; ini <end of file> Move point to the end of the second line. Ensure that verilog-mode is enabled. If it is not use "M-x verilog-mode" Press M-? This will open a buffer with possible completions ... there will only be one... "initial" Use mouse-1 to select it. This will cause the emacs session to start using 100% of the CPU (you should have a top session running separately to notice. However this process is a background process and normal editing can continue until the process uses up all available memory. I kill it quickly using "C-g". The expected behavior is that the "ini" is expanded to "inital" and editing continues with point after the word "initial". What happens is that the emacs process starts consuming 100% CPU, and eventually consume all the available memory in the background. The cursor is left at the end of line 2 after the word "ini". Here is a dribble file including the C-g. If you delete everything after the C-g, you will see the bad behavior. \x06moo.sv<return>module moo;ini<return><up> 0x800003f<help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><down-mouse-1><mouse-1>\a<help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo>\x13\x03 Another strange behavior is I tried to get a stack trace using C-g by enabling "Enter Debugger on Quit/C-g". When I press C-g, It does not end up going into the debugger, but the background process what ever it is, gets killed and CPU usage returns to normal, but no backtrace buffer is opened. Here is a trace of that (Again including the C-g): <help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><menu-bar><options><debug-on-error><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><menu-bar><options><debug-on-quit>\x06moo.sv<return>module moo;ini<return><up> 0x800003f<help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><down-mouse-1><mouse-1>\a\a\a\a\x13\x03 I have reported the issue to the folks who support the verilog-mode, and they have requested I open the bug with you. The bug is reported here http://www.veripool.org/issues/1070-Verilog-mode-Auto-completion-results-in-runaway-emacs-process-in-emacs-24-4-on-Debian-using-2016-04-23-5f6855e-vpo The emacs-mode I used in that report is newer than the one indicated here, but they exhibit the same issue. The version in this report is what comes bundled with this version of emacs, so I assumed it would be easier for you to reproduce. Thanks for your help. Ian Perryman ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: Dribble files 2016-06-24 19:08 bug#23842: 24.4; Runaway background process Ian Perryman @ 2016-06-24 20:02 ` Ian Perryman 2016-06-25 7:00 ` Eli Zaretskii 2016-06-25 6:50 ` bug#23842: 24.4; Runaway background process Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 21+ messages in thread From: Ian Perryman @ 2016-06-24 20:02 UTC (permalink / raw) To: 23842 [-- Attachment #1.1: Type: text/plain, Size: 171 bytes --] The original post with the inline dribble files did not seem to work well for the control characters. I am going to try attaching the files rather than inline them. Ian [-- Attachment #1.2: Type: text/html, Size: 240 bytes --] [-- Attachment #2: simple_dribble --] [-- Type: application/octet-stream, Size: 235 bytes --] [-- Attachment #3: no_debug_on_quit --] [-- Type: application/octet-stream, Size: 780 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: Dribble files 2016-06-24 20:02 ` bug#23842: Dribble files Ian Perryman @ 2016-06-25 7:00 ` Eli Zaretskii 2016-06-26 0:55 ` Ian Perryman 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2016-06-25 7:00 UTC (permalink / raw) To: Ian Perryman; +Cc: 23842 > From: Ian Perryman <iperryman@xtreme-eda.com> > Date: Fri, 24 Jun 2016 16:02:00 -0400 > > The original post with the inline dribble files did not seem to work well for the control characters. > > I am going to try attaching the files rather than inline them. When this happens, do you see some tooltip displayed at mouse pointer? If so, what happens if you move the mouse pointer from that position to some other? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: Dribble files 2016-06-25 7:00 ` Eli Zaretskii @ 2016-06-26 0:55 ` Ian Perryman 0 siblings, 0 replies; 21+ messages in thread From: Ian Perryman @ 2016-06-26 0:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23842@debbugs.gnu.org [-- Attachment #1: Type: text/plain, Size: 1389 bytes --] In Emacs 24.4.1 I do not notice any tool tip information. The *Completions* buffer appears after the M-?. The message buffer has "Type SPC to continue editing." message which I believe comes from the verilog-mode.el code. When the mouse is over the word "initial", in *Completions* buffer, the word is highlighted. I do not notice any other tool tips or other messages. The CPU does not runaway until some event occurs (any mouse click or key stroke) It appears that whatever input is pressed, the CPU runs away, and the keystroke itself is lost. The *Completions* buffer disappears, and editing can continue. Left unchecked, the runaway process consumes all memory and eventually emacs crashes, but it is not "immediate". Other editing seems to work fine. Ian On Sat, Jun 25, 2016 at 3:00 AM, Eli Zaretskii <eliz@gnu.org <javascript:_e(%7B%7D,'cvml','eliz@gnu.org');>> wrote: > > From: Ian Perryman <iperryman@xtreme-eda.com > <javascript:_e(%7B%7D,'cvml','iperryman@xtreme-eda.com');>> > > Date: Fri, 24 Jun 2016 16:02:00 -0400 > > > > The original post with the inline dribble files did not seem to work > well for the control characters. > > > > I am going to try attaching the files rather than inline them. > > When this happens, do you see some tooltip displayed at mouse pointer? > If so, what happens if you move the mouse pointer from that position > to some other? > [-- Attachment #2: Type: text/html, Size: 1887 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-24 19:08 bug#23842: 24.4; Runaway background process Ian Perryman 2016-06-24 20:02 ` bug#23842: Dribble files Ian Perryman @ 2016-06-25 6:50 ` Eli Zaretskii 2016-06-25 20:49 ` Noam Postavsky 2016-06-26 8:51 ` Paul Eggert 2016-12-21 23:37 ` Wilson Snyder 3 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2016-06-25 6:50 UTC (permalink / raw) To: Ian Perryman; +Cc: 23842 > From: Ian Perryman <iperryman@xtreme-eda.com> > Date: Fri, 24 Jun 2016 15:08:50 -0400 > > Open a new buffer called "moo.sv" > > Paste this text into it without the tags: > <start of file> > module moo.sv; > ini > <end of file> > > Move point to the end of the second line. > > Ensure that verilog-mode is enabled. If it is not use "M-x > verilog-mode" > > Press M-? > > This will open a buffer with possible completions ... there will only be > one... "initial" > > Use mouse-1 to select it. With the current Emacs 25 pretest, this signals an error: Wrong type argument: window-live-p, #<window 7> > This will cause the emacs session to start using 100% of the CPU (you > should have a top session running separately to notice. However this > process is a background process and normal editing can continue until > the process uses up all available memory. I kill it quickly using > "C-g". Can someone reproduce this with the latest pretest of Emacs 25? > Here is a dribble file including the C-g. If you delete everything > after the C-g, you will see the bad behavior. > > > \x06moo.sv<return>module moo;ini<return><up> 0x800003f<help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><down-mouse-1><mouse-1>\a<help-echo><help-echo><help-echo><help-echo><help-echo><help-echo><help-echo>\x13\x03 Looks like some help-echo event is constantly generated, but I don't understand what portion of which buffer causes this, and as I say above I see a different problem. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-25 6:50 ` bug#23842: 24.4; Runaway background process Eli Zaretskii @ 2016-06-25 20:49 ` Noam Postavsky 2016-06-26 2:37 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Noam Postavsky @ 2016-06-25 20:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Ian Perryman, 23842 On Sat, Jun 25, 2016 at 2:50 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Ian Perryman <iperryman@xtreme-eda.com> > With the current Emacs 25 pretest, this signals an error: > > Wrong type argument: window-live-p, #<window 7> > >> This will cause the emacs session to start using 100% of the CPU (you >> should have a top session running separately to notice. However this >> process is a background process and normal editing can continue until >> the process uses up all available memory. I kill it quickly using >> "C-g". > > Can someone reproduce this with the latest pretest of Emacs 25? I see the 100% CPU use in Emacs 24.5, but the window-live-p error in Emacs 25.0.95 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-25 20:49 ` Noam Postavsky @ 2016-06-26 2:37 ` Eli Zaretskii 0 siblings, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2016-06-26 2:37 UTC (permalink / raw) To: Noam Postavsky; +Cc: iperryman, 23842 > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Sat, 25 Jun 2016 16:49:55 -0400 > Cc: Ian Perryman <iperryman@xtreme-eda.com>, 23842@debbugs.gnu.org > > On Sat, Jun 25, 2016 at 2:50 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Ian Perryman <iperryman@xtreme-eda.com> > > With the current Emacs 25 pretest, this signals an error: > > > > Wrong type argument: window-live-p, #<window 7> > > > >> This will cause the emacs session to start using 100% of the CPU (you > >> should have a top session running separately to notice. However this > >> process is a background process and normal editing can continue until > >> the process uses up all available memory. I kill it quickly using > >> "C-g". > > > > Can someone reproduce this with the latest pretest of Emacs 25? > > I see the 100% CPU use in Emacs 24.5, but the window-live-p error in > Emacs 25.0.95 Then I guess the problem was already fixed. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-24 19:08 bug#23842: 24.4; Runaway background process Ian Perryman 2016-06-24 20:02 ` bug#23842: Dribble files Ian Perryman 2016-06-25 6:50 ` bug#23842: 24.4; Runaway background process Eli Zaretskii @ 2016-06-26 8:51 ` Paul Eggert 2016-06-26 17:04 ` Glenn Morris 2016-12-21 23:37 ` Wilson Snyder 3 siblings, 1 reply; 21+ messages in thread From: Paul Eggert @ 2016-06-26 8:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: iperryman, 23842-done, Noam Postavsky Yes, I vaguely recall that that bug was fixed a while ago in emacs-25. Closing the bug report; we can reopen it later if I'm wrong. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-26 8:51 ` Paul Eggert @ 2016-06-26 17:04 ` Glenn Morris 2016-06-26 19:02 ` Ian Perryman 2016-06-26 19:48 ` Paul Eggert 0 siblings, 2 replies; 21+ messages in thread From: Glenn Morris @ 2016-06-26 17:04 UTC (permalink / raw) To: 23842; +Cc: eggert, iperryman I don't understand why this was closed, when everyone agrees that the command fails in the current sources. It happens to fail in a different way to the original report, but so what? There's still obviously a bug. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-26 17:04 ` Glenn Morris @ 2016-06-26 19:02 ` Ian Perryman 2016-06-26 19:50 ` Paul Eggert 2016-06-26 19:48 ` Paul Eggert 1 sibling, 1 reply; 21+ messages in thread From: Ian Perryman @ 2016-06-26 19:02 UTC (permalink / raw) To: Glenn Morris; +Cc: eggert, 23842 [-- Attachment #1: Type: text/plain, Size: 578 bytes --] Not sure but it sounds like all development is on emacs 25 which is not available yet AFAIK. If the bug was fixed, is there a patch for emacs 24 that I can use? When was the bug introduced? Should I downgrade to an earlier version of emacs that does not have the bug? Thanks, Ian On Sun, Jun 26, 2016 at 1:04 PM, Glenn Morris <rgm@gnu.org> wrote: > > I don't understand why this was closed, when everyone agrees that the > command fails in the current sources. It happens to fail in a different > way to the original report, but so what? There's still obviously a bug. > [-- Attachment #2: Type: text/html, Size: 921 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-26 19:02 ` Ian Perryman @ 2016-06-26 19:50 ` Paul Eggert 2016-06-27 12:46 ` Ian Perryman 0 siblings, 1 reply; 21+ messages in thread From: Paul Eggert @ 2016-06-26 19:50 UTC (permalink / raw) To: Ian Perryman, Glenn Morris; +Cc: 23842 On 06/26/2016 09:02 PM, Ian Perryman wrote: > If the bug was fixed, is there a patch for emacs 24 that I can use? > When was the bug introduced? Should I downgrade to an earlier version > of emacs that does not have the bug? Apparently I was wrong and the bug has not really been fixed; sorry about that. I don't know the answers to your second question. Downgrading should work, yes. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-26 19:50 ` Paul Eggert @ 2016-06-27 12:46 ` Ian Perryman 2016-06-27 13:24 ` Ken Brown 0 siblings, 1 reply; 21+ messages in thread From: Ian Perryman @ 2016-06-27 12:46 UTC (permalink / raw) To: Paul Eggert; +Cc: 23842 [-- Attachment #1: Type: text/plain, Size: 987 bytes --] I tried down grading to emacs 24.1.1 in windows to see if the problem still exists. The good news is that the process does not runaway to 100% CPU like with emacs 24.4, but it still does not do the completion. I get the "wrong type argument: window-live-p, #<window 5>" The window # would change as I tried it multiple times. This appears to the be the same issue that is now reported in emacs 25. The same error is given in emacs 23.1.1 Not sure when this worked. Any help is appreciated. Ian On Sun, Jun 26, 2016 at 3:50 PM, Paul Eggert <eggert@cs.ucla.edu> wrote: > On 06/26/2016 09:02 PM, Ian Perryman wrote: > >> If the bug was fixed, is there a patch for emacs 24 that I can use? When >> was the bug introduced? Should I downgrade to an earlier version of emacs >> that does not have the bug? >> > > Apparently I was wrong and the bug has not really been fixed; sorry about > that. I don't know the answers to your second question. Downgrading should > work, yes. > [-- Attachment #2: Type: text/html, Size: 1654 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-27 12:46 ` Ian Perryman @ 2016-06-27 13:24 ` Ken Brown 2016-06-27 13:51 ` Ian Perryman 2016-06-27 15:49 ` Eli Zaretskii 0 siblings, 2 replies; 21+ messages in thread From: Ken Brown @ 2016-06-27 13:24 UTC (permalink / raw) To: Ian Perryman, Paul Eggert; +Cc: 23842 On 6/27/2016 8:46 AM, Ian Perryman wrote: > I tried down grading to emacs 24.1.1 in windows to see if the problem > still exists. > > The good news is that the process does not runaway to 100% CPU like with > emacs 24.4, but it still does not do the completion. I get the "wrong > type argument: window-live-p, #<window 5>" > > The window # would change as I tried it multiple times. > > This appears to the be the same issue that is now reported in emacs 25. > > The same error is given in emacs 23.1.1 > > Not sure when this worked. I know virtually nothing about how completion works, but a glance at verilog-mode.el shows the following code, in both verilog-show-completions and verilog-complete-word: ;; Show possible completions in a temporary buffer. (with-output-to-temp-buffer "*Completions*" (display-completion-list allcomp)) ;; Wait for a key press. Then delete *Completion* window (momentary-string-display "" (point)) (delete-window (get-buffer-window (get-buffer "*Completions*"))))) It's hard to see how this could possibly work. As soon as you click in the *Completion* window, the window is deleted. Here's a lisp backtrace: Debugger entered--Lisp error: (wrong-type-argument window-live-p #<window 6>) get-char-property(129 follow-link #<window 6>) mouse-posn-property((#<window 6> 129 (35 . 76) 415716125 nil 129 (3 . 4) nil (8 . 4) (9 . 18)) follow-link) mouse-on-link-p((#<window 6> 129 (35 . 76) 415716125 nil 129 (3 . 4) nil (8 . 4) (9 . 18))) mouse--down-1-maybe-follows-link(nil) The error is generated when Fget_char_property (in textprop.c) calls get_char_property_and_overlay, which calls CHECK_LIVE_WINDOW on a window that has already been deleted. Ken ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-27 13:24 ` Ken Brown @ 2016-06-27 13:51 ` Ian Perryman 2016-08-14 2:36 ` npostavs 2016-06-27 15:49 ` Eli Zaretskii 1 sibling, 1 reply; 21+ messages in thread From: Ian Perryman @ 2016-06-27 13:51 UTC (permalink / raw) To: Ken Brown; +Cc: Paul Eggert, 23842 [-- Attachment #1: Type: text/plain, Size: 2687 bytes --] I am not the author of the verilog mode. I have alerted the maintainer to the issue at http://www.veripool.org/issues/1070-Verilog-mode-Auto-completion-results-in-runaway-emacs-process-in-emacs-24-4-on-Debian-using-2016-04-23-5f6855e-vpo Not sure what the intended behaviour is. My guess is that the list of possible completions was to be presented in the temporary buffer, and then user could select the completion they wanted with a mouse click and it should be inserted back in the original buffer. Did the definition of with-output-to-temp-buffer change over the years? I am not certain when this code was developed, but it was quite a while back. I am surprised that no one else has complained about it. Perhaps the paradigm for completion is not being followed by this mode? Any suggestions? Ian On Mon, Jun 27, 2016 at 9:24 AM, Ken Brown <kbrown@cornell.edu> wrote: > On 6/27/2016 8:46 AM, Ian Perryman wrote: > >> I tried down grading to emacs 24.1.1 in windows to see if the problem >> still exists. >> >> The good news is that the process does not runaway to 100% CPU like with >> emacs 24.4, but it still does not do the completion. I get the "wrong >> type argument: window-live-p, #<window 5>" >> >> The window # would change as I tried it multiple times. >> >> This appears to the be the same issue that is now reported in emacs 25. >> >> The same error is given in emacs 23.1.1 >> >> Not sure when this worked. >> > > I know virtually nothing about how completion works, but a glance at > verilog-mode.el shows the following code, in both verilog-show-completions > and verilog-complete-word: > > ;; Show possible completions in a temporary buffer. > (with-output-to-temp-buffer "*Completions*" > (display-completion-list allcomp)) > ;; Wait for a key press. Then delete *Completion* window > (momentary-string-display "" (point)) > (delete-window (get-buffer-window (get-buffer "*Completions*"))))) > > It's hard to see how this could possibly work. As soon as you click in > the *Completion* window, the window is deleted. Here's a lisp backtrace: > > Debugger entered--Lisp error: (wrong-type-argument window-live-p #<window > 6>) > get-char-property(129 follow-link #<window 6>) > mouse-posn-property((#<window 6> 129 (35 . 76) 415716125 nil 129 (3 . 4) > nil (8 . 4) (9 . 18)) follow-link) > mouse-on-link-p((#<window 6> 129 (35 . 76) 415716125 nil 129 (3 . 4) nil > (8 . 4) (9 . 18))) > mouse--down-1-maybe-follows-link(nil) > > The error is generated when Fget_char_property (in textprop.c) calls > get_char_property_and_overlay, which calls CHECK_LIVE_WINDOW on a window > that has already been deleted. > > Ken > [-- Attachment #2: Type: text/html, Size: 3653 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-27 13:51 ` Ian Perryman @ 2016-08-14 2:36 ` npostavs 2016-12-20 3:58 ` npostavs 0 siblings, 1 reply; 21+ messages in thread From: npostavs @ 2016-08-14 2:36 UTC (permalink / raw) To: Ian Perryman; +Cc: Paul Eggert, 23842 [-- Attachment #1: Type: text/plain, Size: 1417 bytes --] tags 23842 patch quit Ian Perryman <iperryman@xtreme-eda.com> writes: > I am not the author of the verilog mode. I have alerted the maintainer > to the issue at > http://www.veripool.org/issues/1070-Verilog-mode-Auto-completion-results-in-runaway-emacs-process-in-emacs-24-4-on-Debian-using-2016-04-23-5f6855e-vpo > > Not sure what the intended behaviour is. My guess is that the list of > possible completions was to be presented in the temporary buffer, and > then user could select the completion they wanted with a mouse click > and it should be inserted back in the original buffer. > > Did the definition of with-output-to-temp-buffer change over the > years? I am not certain when this code was developed, but it was quite > a while back. I am surprised that no one else has complained about it. Probably most Emacs users don't use the mouse much. > > Perhaps the paradigm for completion is not being followed by this mode? > > Any suggestions? I can't really figure out how that completion window code is supposed to work, but it seems to be duplicating completion-at-point functionality. Patch below just replaces most of it with completion-at-point and it seems to work fine. But I see at the top of the file ;; This code supports Emacs 21.1 and later ;; And XEmacs 21.1 and later ;; Please do not make changes that break Emacs 21. Thanks! So it may need some adjustments for Emacs 21... [-- Attachment #2: patch --] [-- Type: text/plain, Size: 7766 bytes --] From ed885f166108945b8e99d09feaac53ee470a3f2c Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Sat, 13 Aug 2016 22:13:56 -0400 Subject: [PATCH v1] Use completion-at-point in verilog-mode There were some functions in verilog-mode that implemented in-buffer completion, but this needlessly duplicates completion-at-point functionality, and the popup window management had problems (see Bug #23842). * lisp/progmodes/verilog-mode.el (verilog-toggle-completions): Mark obsolete, it does the same job as `completion-cycle-threshold'. (verilog-completion-at-point): New function. (verilog-show-completions): Remove, replace calls with `completion-help-at-point'. (verilog-complete-word): Remove, replace calls with `completion-at-point'. --- lisp/progmodes/verilog-mode.el | 109 +++++++++-------------------------------- 1 file changed, 23 insertions(+), 86 deletions(-) diff --git a/lisp/progmodes/verilog-mode.el b/lisp/progmodes/verilog-mode.el index fd2e96a..e5b9ee8 100644 --- a/lisp/progmodes/verilog-mode.el +++ b/lisp/progmodes/verilog-mode.el @@ -1374,8 +1374,8 @@ verilog-mode-map (define-key map "\M-\C-b" 'electric-verilog-backward-sexp) (define-key map "\M-\C-f" 'electric-verilog-forward-sexp) (define-key map "\M-\r" `electric-verilog-terminate-and-indent) - (define-key map "\M-\t" 'verilog-complete-word) - (define-key map "\M-?" 'verilog-show-completions) + (define-key map "\M-\t" 'completion-at-point) + (define-key map "\M-?" 'completion-help-at-point) ;; Note \C-c and letter are reserved for users (define-key map "\C-c`" 'verilog-lint-off) (define-key map "\C-c*" 'verilog-delete-auto-star-implicit) @@ -1498,7 +1498,7 @@ verilog-mode-map :help "Take a signal vector on the current line and expand it to multiple lines"] ["Insert begin-end block" verilog-insert-block :help "Insert begin ... end"] - ["Complete word" verilog-complete-word + ["Complete word" completion-at-point :help "Complete word at point"] "----" ["Recompute AUTOs" verilog-auto @@ -3762,7 +3762,7 @@ verilog-mode Some other functions are: - \\[verilog-complete-word] Complete word with appropriate possibilities. + \\[completion-at-point] Complete word with appropriate possibilities. \\[verilog-mark-defun] Mark function. \\[verilog-beg-of-defun] Move to beginning of current function. \\[verilog-end-of-defun] Move to end of current function. @@ -3876,6 +3876,9 @@ verilog-mode verilog-forward-sexp-function) hs-special-modes-alist)))) + (add-hook 'completion-at-point-functions + #'verilog-completion-at-point nil 'local) + ;; Stuff for autos (add-hook 'write-contents-hooks 'verilog-auto-save-check nil 'local) ;; verilog-mode-hook call added by define-derived-mode @@ -7143,10 +7146,9 @@ verilog-pred (defvar verilog-buffer-to-use nil) (defvar verilog-flag nil) (defvar verilog-toggle-completions nil - "True means \\<verilog-mode-map>\\[verilog-complete-word] should try all possible completions one by one. -Repeated use of \\[verilog-complete-word] will show you all of them. -Normally, when there is more than one possible completion, -it displays a list of all possible completions.") + "Obsolete, use `completion-cycle-threshold' instead.") +(make-obsolete-variable + 'verilog-toggle-completions 'completion-cycle-threshold "25.2") (defvar verilog-type-keywords @@ -7429,85 +7431,20 @@ verilog-last-word-numb (defvar verilog-last-word-shown nil) (defvar verilog-last-completions nil) -(defun verilog-complete-word () - "Complete word at current point. -\(See also `verilog-toggle-completions', `verilog-type-keywords', -and `verilog-separator-keywords'.)" - ;; FIXME: Provide completion-at-point-function. - (interactive) - (let* ((b (save-excursion (skip-chars-backward "a-zA-Z0-9_") (point))) - (e (save-excursion (skip-chars-forward "a-zA-Z0-9_") (point))) - (verilog-str (buffer-substring b e)) - ;; The following variable is used in verilog-completion - (verilog-buffer-to-use (current-buffer)) - (allcomp (if (and verilog-toggle-completions - (string= verilog-last-word-shown verilog-str)) - verilog-last-completions - (all-completions verilog-str 'verilog-completion))) - (match (if verilog-toggle-completions - "" (try-completion - verilog-str (mapcar (lambda (elm) - (cons elm 0)) allcomp))))) - ;; Delete old string - (delete-region b e) - - ;; Toggle-completions inserts whole labels - (if verilog-toggle-completions - (progn - ;; Update entry number in list - (setq verilog-last-completions allcomp - verilog-last-word-numb - (if (>= verilog-last-word-numb (1- (length allcomp))) - 0 - (1+ verilog-last-word-numb))) - (setq verilog-last-word-shown (elt allcomp verilog-last-word-numb)) - ;; Display next match or same string if no match was found - (if (not (null allcomp)) - (insert "" verilog-last-word-shown) - (insert "" verilog-str) - (message "(No match)"))) - ;; The other form of completion does not necessarily do that. - - ;; Insert match if found, or the original string if no match - (if (or (null match) (equal match 't)) - (progn (insert "" verilog-str) - (message "(No match)")) - (insert "" match)) - ;; Give message about current status of completion - (cond ((equal match 't) - (if (not (null (cdr allcomp))) - (message "(Complete but not unique)") - (message "(Sole completion)"))) - ;; Display buffer if the current completion didn't help - ;; on completing the label. - ((and (not (null (cdr allcomp))) (= (length verilog-str) - (length match))) - (with-output-to-temp-buffer "*Completions*" - (display-completion-list allcomp)) - ;; Wait for a key press. Then delete *Completion* window - (momentary-string-display "" (point)) - (delete-window (get-buffer-window (get-buffer "*Completions*"))) - ))))) - -(defun verilog-show-completions () - "Show all possible completions at current point." - (interactive) +(defun verilog-completion-at-point () + "Used as an element of `completion-at-point-functions'. +\(See also `verilog-type-keywords' and +`verilog-separator-keywords'.)" (let* ((b (save-excursion (skip-chars-backward "a-zA-Z0-9_") (point))) - (e (save-excursion (skip-chars-forward "a-zA-Z0-9_") (point))) - (verilog-str (buffer-substring b e)) - ;; The following variable is used in verilog-completion - (verilog-buffer-to-use (current-buffer)) - (allcomp (if (and verilog-toggle-completions - (string= verilog-last-word-shown verilog-str)) - verilog-last-completions - (all-completions verilog-str 'verilog-completion)))) - ;; Show possible completions in a temporary buffer. - (with-output-to-temp-buffer "*Completions*" - (display-completion-list allcomp)) - ;; Wait for a key press. Then delete *Completion* window - (momentary-string-display "" (point)) - (delete-window (get-buffer-window (get-buffer "*Completions*"))))) - + (e (save-excursion (skip-chars-forward "a-zA-Z0-9_") (point))) + (verilog-str (buffer-substring b e)) + ;; The following variable is used in verilog-completion + (verilog-buffer-to-use (current-buffer)) + (allcomp (if (and verilog-toggle-completions + (string= verilog-last-word-shown verilog-str)) + verilog-last-completions + (all-completions verilog-str 'verilog-completion)))) + (list b e allcomp))) (defun verilog-get-default-symbol () "Return symbol around current point as a string." -- 2.9.2 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-08-14 2:36 ` npostavs @ 2016-12-20 3:58 ` npostavs 0 siblings, 0 replies; 21+ messages in thread From: npostavs @ 2016-12-20 3:58 UTC (permalink / raw) To: Ian Perryman; +Cc: Paul Eggert, 23842, Wilson Snyder [-- Attachment #1: Type: text/plain, Size: 380 bytes --] Wilson Snyder <wsnyder@wsnyder.org> wrote: > It's perhaps reasonable to break a small number of things in > say Emacs 21, but this patch also breaks Emacs 23.1, which > is still relatively widely deployed for those on Redhat > distros, such as at my employer. I have only Emacs versions back to 23.4 built. I think the patch below should work, but I haven't tested it on 23.1. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: patch --] [-- Type: text/x-diff, Size: 7469 bytes --] From c7257a3e1d32c1c66b99c4794a4ae2b75524377c Mon Sep 17 00:00:00 2001 From: Noam Postavsky <npostavs@gmail.com> Date: Sat, 13 Aug 2016 22:13:56 -0400 Subject: [PATCH v2] Use completion-at-point in verilog-mode There were some functions in verilog-mode that implemented in-buffer completion, but this needlessly duplicates completion-at-point functionality, and the popup window management had problems (see Bug #23842). We need to keep them for backwards compatibility with older emacs versions, but use completion-at-point if available. * lisp/progmodes/verilog-mode.el (verilog-toggle-completions): Mark as obsolete if completion-cycle-threshold is available. (verilog-mode-map, verilog-menu): Bind completion-at-point and completion-help-at-point in preference to verilog-complete-word and verilog-show-completions, respectively. (verilog-mode): Add verilog-completion-at-point to completion-at-point-functions. (verilog-completion-at-point): New function. (verilog-show-completions, verilog-complete-word): Use it to avoid code duplication. --- lisp/progmodes/verilog-mode.el | 71 ++++++++++++++++++++++++------------------ 1 file changed, 41 insertions(+), 30 deletions(-) diff --git a/lisp/progmodes/verilog-mode.el b/lisp/progmodes/verilog-mode.el index 5368b61..7c7242f 100644 --- a/lisp/progmodes/verilog-mode.el +++ b/lisp/progmodes/verilog-mode.el @@ -1416,8 +1416,10 @@ verilog-mode-map (define-key map "\M-\C-b" 'electric-verilog-backward-sexp) (define-key map "\M-\C-f" 'electric-verilog-forward-sexp) (define-key map "\M-\r" `electric-verilog-terminate-and-indent) - (define-key map "\M-\t" 'verilog-complete-word) - (define-key map "\M-?" 'verilog-show-completions) + (define-key map "\M-\t" (if (fboundp 'completion-at-point) + 'completion-at-point 'verilog-complete-word)) + (define-key map "\M-?" (if (fboundp 'completion-help-at-point) + 'completion-help-at-point 'verilog-show-completions)) ;; Note \C-c and letter are reserved for users (define-key map "\C-c`" 'verilog-lint-off) (define-key map "\C-c*" 'verilog-delete-auto-star-implicit) @@ -1448,7 +1450,7 @@ verilog-mode-map (easy-menu-define verilog-menu verilog-mode-map "Menu for Verilog mode" (verilog-easy-menu-filter - '("Verilog" + `("Verilog" ("Choose Compilation Action" ["None" (progn @@ -1540,7 +1542,8 @@ verilog-mode-map :help "Take a signal vector on the current line and expand it to multiple lines"] ["Insert begin-end block" verilog-insert-block :help "Insert begin ... end"] - ["Complete word" verilog-complete-word + ["Complete word" ,(if (fboundp 'completion-at-point) + 'completion-at-point 'verilog-complete-word) :help "Complete word at point"] "----" ["Recompute AUTOs" verilog-auto @@ -3806,7 +3809,7 @@ verilog-mode Some other functions are: - \\[verilog-complete-word] Complete word with appropriate possibilities. + \\[completion-at-point] Complete word with appropriate possibilities. \\[verilog-mark-defun] Mark function. \\[verilog-beg-of-defun] Move to beginning of current function. \\[verilog-end-of-defun] Move to end of current function. @@ -3920,6 +3923,9 @@ verilog-mode verilog-forward-sexp-function) hs-special-modes-alist)))) + (add-hook 'completion-at-point-functions + #'verilog-completion-at-point nil 'local) + ;; Stuff for autos (add-hook 'write-contents-hooks 'verilog-auto-save-check nil 'local) ;; verilog-mode-hook call added by define-derived-mode @@ -7198,6 +7204,9 @@ verilog-toggle-completions Repeated use of \\[verilog-complete-word] will show you all of them. Normally, when there is more than one possible completion, it displays a list of all possible completions.") +(when (boundp 'completion-cycle-threshold) + (make-obsolete-variable + 'verilog-toggle-completions 'completion-cycle-threshold "26.1")) (defvar verilog-type-keywords @@ -7480,21 +7489,33 @@ verilog-last-word-numb (defvar verilog-last-word-shown nil) (defvar verilog-last-completions nil) +(defun verilog-completion-at-point () + "Used as an element of `completion-at-point-functions'. +\(See also `verilog-type-keywords' and +`verilog-separator-keywords'.)" + (let* ((b (save-excursion (skip-chars-backward "a-zA-Z0-9_") (point))) + (e (save-excursion (skip-chars-forward "a-zA-Z0-9_") (point))) + (verilog-str (buffer-substring b e)) + ;; The following variable is used in verilog-completion + (verilog-buffer-to-use (current-buffer)) + (allcomp (if (and verilog-toggle-completions + (string= verilog-last-word-shown verilog-str)) + verilog-last-completions + (all-completions verilog-str 'verilog-completion)))) + (list b e allcomp))) + (defun verilog-complete-word () "Complete word at current point. \(See also `verilog-toggle-completions', `verilog-type-keywords', and `verilog-separator-keywords'.)" - ;; FIXME: Provide completion-at-point-function. + ;; NOTE: This is just a fallback for Emacs versions lacking + ;; `completion-at-point-function'. (interactive) - (let* ((b (save-excursion (skip-chars-backward "a-zA-Z0-9_") (point))) - (e (save-excursion (skip-chars-forward "a-zA-Z0-9_") (point))) + (let* ((comp-info (verilog-completion-at-point)) + (b (nth 0 comp-info)) + (e (nth 1 comp-info)) (verilog-str (buffer-substring b e)) - ;; The following variable is used in verilog-completion - (verilog-buffer-to-use (current-buffer)) - (allcomp (if (and verilog-toggle-completions - (string= verilog-last-word-shown verilog-str)) - verilog-last-completions - (all-completions verilog-str 'verilog-completion))) + (allcomp (nth 2 comp-info)) (match (if verilog-toggle-completions "" (try-completion verilog-str (mapcar (lambda (elm) @@ -7543,22 +7564,12 @@ verilog-complete-word (defun verilog-show-completions () "Show all possible completions at current point." (interactive) - (let* ((b (save-excursion (skip-chars-backward "a-zA-Z0-9_") (point))) - (e (save-excursion (skip-chars-forward "a-zA-Z0-9_") (point))) - (verilog-str (buffer-substring b e)) - ;; The following variable is used in verilog-completion - (verilog-buffer-to-use (current-buffer)) - (allcomp (if (and verilog-toggle-completions - (string= verilog-last-word-shown verilog-str)) - verilog-last-completions - (all-completions verilog-str 'verilog-completion)))) - ;; Show possible completions in a temporary buffer. - (with-output-to-temp-buffer "*Completions*" - (display-completion-list allcomp)) - ;; Wait for a key press. Then delete *Completion* window - (momentary-string-display "" (point)) - (delete-window (get-buffer-window (get-buffer "*Completions*"))))) - + ;; Show possible completions in a temporary buffer. + (with-output-to-temp-buffer "*Completions*" + (display-completion-list (nth 2 (verilog-completion-at-point)))) + ;; Wait for a key press. Then delete *Completion* window + (momentary-string-display "" (point)) + (delete-window (get-buffer-window (get-buffer "*Completions*")))) (defun verilog-get-default-symbol () "Return symbol around current point as a string." -- 2.9.3 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-27 13:24 ` Ken Brown 2016-06-27 13:51 ` Ian Perryman @ 2016-06-27 15:49 ` Eli Zaretskii 2016-06-27 16:54 ` Ken Brown 1 sibling, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2016-06-27 15:49 UTC (permalink / raw) To: Ken Brown; +Cc: eggert, iperryman, 23842 > From: Ken Brown <kbrown@cornell.edu> > Date: Mon, 27 Jun 2016 09:24:06 -0400 > Cc: 23842@debbugs.gnu.org > > ;; Show possible completions in a temporary buffer. > (with-output-to-temp-buffer "*Completions*" > (display-completion-list allcomp)) > ;; Wait for a key press. Then delete *Completion* window > (momentary-string-display "" (point)) > (delete-window (get-buffer-window (get-buffer "*Completions*"))))) > > It's hard to see how this could possibly work. As soon as you click in > the *Completion* window, the window is deleted. It could perhaps work if we didn't check the window for being a live one. Anyway, the code is definitely broken and should be fixed. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-27 15:49 ` Eli Zaretskii @ 2016-06-27 16:54 ` Ken Brown 0 siblings, 0 replies; 21+ messages in thread From: Ken Brown @ 2016-06-27 16:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, iperryman, 23842 On 6/27/2016 11:49 AM, Eli Zaretskii wrote: >> From: Ken Brown <kbrown@cornell.edu> >> Date: Mon, 27 Jun 2016 09:24:06 -0400 >> Cc: 23842@debbugs.gnu.org >> >> ;; Show possible completions in a temporary buffer. >> (with-output-to-temp-buffer "*Completions*" >> (display-completion-list allcomp)) >> ;; Wait for a key press. Then delete *Completion* window >> (momentary-string-display "" (point)) >> (delete-window (get-buffer-window (get-buffer "*Completions*"))))) >> >> It's hard to see how this could possibly work. As soon as you click in >> the *Completion* window, the window is deleted. > > It could perhaps work if we didn't check the window for being a live > one. > > Anyway, the code is definitely broken and should be fixed. Yes. And there are even problems with it unrelated to the check for the window being live. For example, suppose you want to switch to the *Completions* window to select the desired completion without using the mouse. As soon as you type C-x (meant to be followed by o), the *Completions* window is gone. Ken ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-26 17:04 ` Glenn Morris 2016-06-26 19:02 ` Ian Perryman @ 2016-06-26 19:48 ` Paul Eggert 1 sibling, 0 replies; 21+ messages in thread From: Paul Eggert @ 2016-06-26 19:48 UTC (permalink / raw) To: Glenn Morris, 23842; +Cc: iperryman On 06/26/2016 07:04 PM, Glenn Morris wrote: > I don't understand why this was closed, when everyone agrees that the > command fails in the current sources. Sorry, that wasn't clear to me in my cursory reading of the last few messages. I reopened the bug report. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-06-24 19:08 bug#23842: 24.4; Runaway background process Ian Perryman ` (2 preceding siblings ...) 2016-06-26 8:51 ` Paul Eggert @ 2016-12-21 23:37 ` Wilson Snyder 2016-12-22 2:44 ` npostavs 3 siblings, 1 reply; 21+ messages in thread From: Wilson Snyder @ 2016-12-21 23:37 UTC (permalink / raw) To: npostavs; +Cc: eggert, iperryman, 23842 This works on all the older versions I have. Thanks for updating it. Would you like to commit it (if so no need to reply as I'll see the commit), or shall I? -Wilson npostavs@users.sourceforge.net writes: >Wilson Snyder <wsnyder@wsnyder.org> wrote: >> It's perhaps reasonable to break a small number of things in >> say Emacs 21, but this patch also breaks Emacs 23.1, which >> is still relatively widely deployed for those on Redhat >> distros, such as at my employer. > >I have only Emacs versions back to 23.4 built. I think the patch below >should work, but I haven't tested it on 23.1. > > From c7257a3e1d32c1c66b99c4794a4ae2b75524377c Mon Sep 17 00:00:00 2001 >From: Noam Postavsky <npostavs@gmail.com> >Date: Sat, 13 Aug 2016 22:13:56 -0400 >Subject: [PATCH v2] Use completion-at-point in verilog-mode > >There were some functions in verilog-mode that implemented in-buffer >completion, but this needlessly duplicates completion-at-point >functionality, and the popup window management had problems >(see Bug #23842). We need to keep them for backwards compatibility with >older emacs versions, but use completion-at-point if available. > >* lisp/progmodes/verilog-mode.el (verilog-toggle-completions): Mark as >obsolete if completion-cycle-threshold is available. >(verilog-mode-map, verilog-menu): Bind completion-at-point and >completion-help-at-point in preference to verilog-complete-word and >verilog-show-completions, respectively. >(verilog-mode): Add verilog-completion-at-point to >completion-at-point-functions. >(verilog-completion-at-point): New function. >(verilog-show-completions, verilog-complete-word): Use it to avoid code >duplication. >--- ... ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23842: 24.4; Runaway background process 2016-12-21 23:37 ` Wilson Snyder @ 2016-12-22 2:44 ` npostavs 0 siblings, 0 replies; 21+ messages in thread From: npostavs @ 2016-12-22 2:44 UTC (permalink / raw) To: Wilson Snyder; +Cc: eggert, 23842, iperryman tags 23842 fixed close 23842 26.1 quit wsnyder@wsnyder.org (Wilson Snyder) writes: > This works on all the older versions I have. Thanks for updating it. > > Would you like to commit it (if so no need to reply as I'll > see the commit), or shall I? Pushed as de0671096706. (I reply here, so the bug thread has the info too) ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2016-12-22 2:44 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-24 19:08 bug#23842: 24.4; Runaway background process Ian Perryman 2016-06-24 20:02 ` bug#23842: Dribble files Ian Perryman 2016-06-25 7:00 ` Eli Zaretskii 2016-06-26 0:55 ` Ian Perryman 2016-06-25 6:50 ` bug#23842: 24.4; Runaway background process Eli Zaretskii 2016-06-25 20:49 ` Noam Postavsky 2016-06-26 2:37 ` Eli Zaretskii 2016-06-26 8:51 ` Paul Eggert 2016-06-26 17:04 ` Glenn Morris 2016-06-26 19:02 ` Ian Perryman 2016-06-26 19:50 ` Paul Eggert 2016-06-27 12:46 ` Ian Perryman 2016-06-27 13:24 ` Ken Brown 2016-06-27 13:51 ` Ian Perryman 2016-08-14 2:36 ` npostavs 2016-12-20 3:58 ` npostavs 2016-06-27 15:49 ` Eli Zaretskii 2016-06-27 16:54 ` Ken Brown 2016-06-26 19:48 ` Paul Eggert 2016-12-21 23:37 ` Wilson Snyder 2016-12-22 2:44 ` npostavs
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).