bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23842: 24.4; Runaway background process


From: Ian Perryman
Subject: bug#23842: 24.4; Runaway background process
Date: Mon, 27 Jun 2016 09:51:47 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]