bling / fzf.el

A front-end for fzf
GNU General Public License v3.0
369 stars 50 forks source link

Exiting faster #104

Closed bechampion closed 1 year ago

bechampion commented 1 year ago

Hey guys love the extension but i get this when i don't select a file and it is quite slow to complete: image

Is there any way to making faster and escape with single key stroke?

pierre-rouleau commented 1 year ago

Did you try stopping the operation with C-g?
(That is: typing Control-G) It will stop right away. Is it not what you're doing?

If you execute fzf directly from a shell and do not select a file, you can type Control-C to stop it (C-c in Emacs notation). If you do, the fzf exit code is 130.

When running the command under Emacs, a sub-process ran in a sub-shell that returns a non-zero exit code is interpreted by Emacs as an "error in process sentinel". That's why you see this printed in Emacs status line. I can't think of a way to prevent it short of writing a C program (or something) that launches fzf, discards its exit code and exists with 0 all the time. But who would want to do that?

tttuuu888 commented 1 year ago

This is happening to me as well. The "error: 130" message is fine, but there is a delay of about 2 seconds after displaying the message when finishing fzf by C-g Perhaps not everyone is experiencing the delay after the error message. I am using GNU Emacs 28.2 by the way. Thanks.

tttuuu888 commented 1 year ago

The error message is not FZF error: 130 but error in process sentinel: FZF error: 130 in this case. The difference can be tested as below.

First, (user-error "FZF error: 130") will only print message. But below would reproduce same error message and delay above. (Maybe not everyone will face the delay though)

(advice-add 'term-handle-exit :after (lambda (&rest _) (user-error "FZF error: 130")))
(make-term "ls" "ls")

So I think using user-error in advice for term-handle-exit is somehow causing this unintended extra error and delay. Thanks.

tttuuu888 commented 1 year ago

Here is where the 2 seconds of delay happens on Emacs C code. https://github.com/emacs-mirror/emacs/blob/emacs-28.2/src/process.c#L7412

And it says that the delay in displaying error messages from process sentinels is intended to strike a balance between allowing the process sentinel to handle errors and providing timely feedback to the user.

Good thing is that this fixed 2 seconds delay is adjustable by modifying new variable process-error-pause-time on latest Emacs version. https://github.com/emacs-mirror/emacs/blob/master/src/process.c#L8706

Maybe we can remove this delay by setting 0 to this new variable on latest Emacs while executing fzf function. However, in Emacs versions below 28.2, this delay of 2 seconds is a fixed value, so it seems difficult to fix. Easy way to avoid this delay might be not occurring error in process sentinel, which might be simply restoring user-error to message. So, what do you think about this, @pierre-rouleau ?

pierre-rouleau commented 1 year ago

Interesting @tttuuu888 and thanks! I must admit I never noticed the extra delay after the error. But now that you said it it's quite noticeable and yes, changing back to message is the way to go since most of the time it's the user who wanted to exit and that caused the error. I'll post an update. @bechampion sorry for not catching up on what you were referring to faster.

pierre-rouleau commented 1 year ago

@bling this is a simple change. It's ready to be integrated.