* 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: 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: 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: 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: 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-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 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-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: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-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-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).