GNU bug report logs -
#19457
24.4; exec_sentinel_error_handler and read_process_output_error_handler
Previous Next
Reported by: Leo Liu <sdl.web <at> gmail.com>
Date: Sun, 28 Dec 2014 10:27:02 UTC
Severity: normal
Found in version 24.4
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19457 in the body.
You can then email your comments to 19457 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19457
; Package
emacs
.
(Sun, 28 Dec 2014 10:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Leo Liu <sdl.web <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 28 Dec 2014 10:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
why are these functions have a hard-coded 2 seconds wait while
inhibit-quit?
This can be problematic in a situation triggered by completion-at-point.
in my setup I have 3 items in completion-styles and it can trigger 6
sentinel/filter errors in a row for every char input. While the errors
are signalled and even if I keep hitting C-g I have to wait many
seconds.
Leo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19457
; Package
emacs
.
(Sun, 28 Dec 2014 11:55:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 19457 <at> debbugs.gnu.org (full text, mbox):
On 2014-12-28 21:25 +1100, Leo Liu wrote:
> This can be problematic in a situation triggered by completion-at-point.
> in my setup I have 3 items in completion-styles and it can trigger 6
> sentinel/filter errors in a row for every char input. While the errors
> are signalled and even if I keep hitting C-g I have to wait many
> seconds.
There is also this issue:
See completion--some; all errors are deferred to the end of the
function. There is no way a completion table can tell completion--some
"I am not ready" don't call me again. For example, when a completion
table involves running an external command and that command is not
installed in the system. In this case the completion table knows better
i.e. no need to retry so as to save precious time.
Leo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19457
; Package
emacs
.
(Thu, 01 Jan 2015 16:30:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 19457 <at> debbugs.gnu.org (full text, mbox):
> See completion--some; all errors are deferred to the end of the
> function. There is no way a completion table can tell completion--some
> "I am not ready" don't call me again. For example, when a completion
> table involves running an external command and that command is not
> installed in the system. In this case the completion table knows better
> i.e. no need to retry so as to save precious time.
[ I understand this may not really solve your problem, but it might
still help you find the right solution: ]
The repetition between the different calls to the completion-table
happening during completion--some is expected to be avoided (if
problematic) via caching.
Back then I tried to come up with some alternative API that would
provide directly the ability to share more work, but couldn't come
up with anything that was really better than just using straight caching
in the backend.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19457
; Package
emacs
.
(Sun, 04 Jan 2015 23:06:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 19457 <at> debbugs.gnu.org (full text, mbox):
On 2015-01-02 03:29 +1100, Stefan Monnier wrote:
> The repetition between the different calls to the completion-table
> happening during completion--some is expected to be avoided (if
> problematic) via caching.
>
> Back then I tried to come up with some alternative API that would
> provide directly the ability to share more work, but couldn't come
> up with anything that was really better than just using straight caching
> in the backend.
Thanks for the information. For this instance I have chosen to silence
errors from sentinel/filter functions with logging of errors and
backtrace instead. The long unquittable wait is just too much. But
caching can reduce the multiple error instances to one.
Leo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19457
; Package
emacs
.
(Sun, 04 Jan 2015 23:44:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 19457 <at> debbugs.gnu.org (full text, mbox):
On 01/01/2015 07:29 PM, Stefan Monnier wrote:
> Back then I tried to come up with some alternative API that would
> provide directly the ability to share more work, but couldn't come
> up with anything that was really better than just using straight caching
> in the backend.
A straightforward caching approach (like `completion-table-with-cache')
won't be good enough, though: the completion styles that come later tend
to query with shorter prefixes.
So all in all, it seems like the caching function has to return
completions for an empty prefix, and then cache that. That might be
pretty costly at times.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19457
; Package
emacs
.
(Mon, 05 Jan 2015 01:59:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 19457 <at> debbugs.gnu.org (full text, mbox):
> So all in all, it seems like the caching function has to return completions
> for an empty prefix, and then cache that. That might be pretty costly
> at times.
Indeed. And for the "error" case, the caching is yet different. In my
experience, there can't really be a "one stop" caching solution.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19457
; Package
emacs
.
(Thu, 02 Dec 2021 11:55:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 19457 <at> debbugs.gnu.org (full text, mbox):
Leo Liu <sdl.web <at> gmail.com> writes:
> why are these functions have a hard-coded 2 seconds wait while
> inhibit-quit?
I've now introduced a new variable, `process-error-pause-time', in Emacs
29 for this. (Setting it to 0 will disable these pauses.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
19457 <at> debbugs.gnu.org and Leo Liu <sdl.web <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 02 Dec 2021 11:55:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 30 Dec 2021 12:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.