From: Jules Tamagnan <jtamagnan@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23609@debbugs.gnu.org, dgutov@yandex.ru
Subject: bug#23609: 25.0.92; Python eldoc freeze
Date: Fri, 27 May 2016 15:43:18 -0400 [thread overview]
Message-ID: <861t4nxp61.fsf@gmail.com> (raw)
In-Reply-To: <83fut3z4bq.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 May 2016 22:30:33 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jules Tamagnan <jtamagnan@gmail.com>
>> Cc: 23609@debbugs.gnu.org, dgutov@yandex.ru
>> Date: Fri, 27 May 2016 15:13:42 -0400
>>
>> > . The problem happens only when the interpreter is busy doing
>> > something, is that right? If so, perhaps we shouldn't turn
>> > eldoc-mode off, but instead simply return?
>>
>> The problem with simply returning instead of canceling the behavior for
>> the buffer is that a second (or so) later eldoc will once again try to
>> fetch the documentation and will be frozen until the timeout. This means
>> that you will be repeatidly be getting frozen as you type. It won't be
>> a complete freeze that crashes emacs but it won't be pleasant.
>
> Once again, perhaps I misunderstand the nature of the problem, but
> doesn't it happen only when the Python interpreter is busy doing
> something when the eldoc function is invoked? If so, then the next
> time eldoc is invoked, the Python interpreter might not be busy, and
> the feature will work without hanging, right? Or am I missing
> something?
No that's exactly correct. I'm just thinking of it from the point of
view that perhaps somebody is plotting a graph from the interpreter
which causes the interpreter to be busy. Then while having that graph
open they would still like to be able to edit their code (I have been in
this situation dozens of times). Or if the code they are running takes a
a minute or two there is a good chance that they would want to edit some
of the code while it is running. In those scenarios I feel like it makes
sense to stop eldoc from doing the automatic checking permanently for
that buffer because otherwise my work would be constantly interrupted.
If we plan on the process only being busy for a few seconds at a time then I
understand where you are coming from.
I have also found for python at least that there are very good tools out
there that work better than eldoc and which use a separate process so
they never hang up.
>> > . If we do turn eldoc-mode off, then I think a message to that
>> > effect is in order, to let the user know.
>>
>> We're not turning it off but yes a warning would definitely be nice.
>
> Well, we turn off the automatic display of the documentation in the
> echo area, right?
Yep but eldoc mode is still on
Thanks.
next prev parent reply other threads:[~2016-05-27 19:43 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-24 15:34 bug#23609: 25.0.92; Python eldoc freeze Jules Tamagnan
2016-05-25 6:11 ` Andreas Röhler
2016-05-25 15:18 ` Jules Tamagnan
2016-05-25 15:33 ` Andreas Röhler
2016-05-26 15:52 ` Jules Tamagnan
2016-05-26 16:31 ` Eli Zaretskii
2016-05-26 16:37 ` Dmitry Gutov
2016-05-26 16:48 ` Eli Zaretskii
2016-05-26 17:13 ` Jules Tamagnan
2016-05-27 9:23 ` Eli Zaretskii
2016-05-27 14:41 ` Eli Zaretskii
2016-05-27 14:52 ` Jules Tamagnan
2016-05-27 19:06 ` Eli Zaretskii
2016-05-27 15:42 ` Glenn Morris
2016-05-27 18:41 ` Eli Zaretskii
2016-05-27 16:12 ` Jules Tamagnan
2016-05-27 16:18 ` Dmitry Gutov
2016-05-27 17:12 ` Jules Tamagnan
2016-05-27 18:26 ` Dmitry Gutov
2016-05-27 18:39 ` Jules Tamagnan
2016-05-27 18:50 ` Dmitry Gutov
2016-05-27 18:57 ` Jules Tamagnan
2016-05-27 19:05 ` Eli Zaretskii
2016-05-27 19:13 ` Jules Tamagnan
2016-05-27 19:30 ` Eli Zaretskii
2016-05-27 19:43 ` Jules Tamagnan [this message]
2016-05-27 19:49 ` Eli Zaretskii
2016-05-27 20:19 ` Jules Tamagnan
2016-05-28 7:53 ` Eli Zaretskii
2016-05-31 17:35 ` Jules Tamagnan
2016-06-06 14:08 ` Jules Tamagnan
2016-06-06 15:15 ` Eli Zaretskii
2016-06-10 9:10 ` Eli Zaretskii
2016-05-27 6:09 ` Andreas Röhler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=861t4nxp61.fsf@gmail.com \
--to=jtamagnan@gmail.com \
--cc=23609@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.