bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

[Leo Liu]

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

bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

[Leo Liu]

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

bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

[Stefan Monnier]

> 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

bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

[Leo Liu]

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

bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

[Dmitry Gutov]

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.

bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

[Stefan Monnier]

> 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

bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler

[Lars Ingebrigtsen]

Leo Liu <sdl.web@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