GNU bug report logs - #27036
25.1; Blocking call to accept-process-output with quit inhibited!!

Previous Next

Full log

View this message in rfc822 format

From: Francesco Potortì <pot <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 27036 <at> debbugs.gnu.org
Subject: bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)
Date: Tue, 30 May 2017 09:46:03 +0200

>On 5/26/17 4:17 PM, Francesco Potortì wrote:
>> if Octave is running a long command it
>> locks Emacs until the long command execution finishes and the prompt is
>> returned.
>
>Yes, this problem should be common for all modes that use the REPL for 
>fetching information like this. E.g. python-eldoc-function.
>
>Normally, we don't see long-running commands in the user REPL. Or don't 
>expect the user to switch back to the source buffer and continue 
>editing. Octave might be a significant exception in that regard.
>
>Anyway, please try the attached combined patch and see if it fixes your 
>problem.

It does not seem to work, sorry.  I launch a long-running command in the
inferior octave buffer, then in another window I go and edit the octave
source.  After a while everything is frozen.  The long-running command
is stopped midway and a syntax error is signaled which involves the
function point was on in the source.

I did not restart emacs for testing, I just evaluated the patched
octave.el.  Is that alright?

Does it makes sense at all to use the same process for interaction and
for asking help?  Wouldn't it be simpler and more robust if a dedicated
octave process was started for eldoc?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.