bug#23842: 24.4; Runaway background process

[Ian Perryman <iperryman@xtreme-eda.com>]

[-- 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 --]