search

Fuco1 / smartparens

Minor mode for Emacs that deals with parens pairs and tries to be smart about it.
GNU General Public License v3.0
1.81k stars 194 forks source link

Keypress ignored and "Quit" printed in minibuffer #946

Closed Fuco1 closed 5 months ago

Fuco1 commented 5 years ago

I believe there's a bug in this patch.

  1. In Spacemacs (which uses smartparens), occasionally a keypress will be ignored, and the message "Quit" will show up in the minibuffer (and also the Messages buffer)
  2. Before this change, this problem doesn't exist.
  3. When I blacklist smartparens from Spacemacs, the problem also disappears.

(copied from #943)

sorawee commented 5 years ago

@arvinpan confirms that disabling smartparens makes the bug disappear here: https://github.com/syl20bnr/spacemacs/issues/11736#issuecomment-450636451

Alexander-Miller commented 5 years ago

I also use spacemacs and I've haven't encountered any such problems.

"Quit" will show up in the minibuffer (and also the Messages buffer)

Could well be a false-positive, that shows up every time you call keyboard-quit.

@TimoFreiberg how's things on your end?

lilactown commented 5 years ago

I can confirm that after recently updating to the latest in spacemacs develop branch updating all of my packages, this issue began to appear: many Quit messages showing up in *Messages* buffer and dropping keystrokes when editing e.g. Clojure files.

Excluding smartparens in my .spacemacs seems to have fixed this issue for now.

aaronjensen commented 5 years ago

@fuco1 worth trying some version of Fuco1/smartparens#882 now instead?

@Lokeh or @sorawee could you try keeping smartparens enabled and removing the while-no-input from sp-show--pair-function and see if it helps?

sorawee commented 5 years ago

I rolled back the package to smartparens-20181028.1005 (which is prior #943) and there's no problem with this version. Since #943 simply adds while-no-input, I think that means removing while-no-input helps.

TimoFreiberg commented 5 years ago

Can't reproduce (neither by writing some clojure code nor by performing the steps outlined in https://github.com/syl20bnr/spacemacs/issues/11736#issuecomment-450544978)

Maybe the emacs version/OS makes a difference? My setup:

Arch Linux GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-07-05 Spacemacs on develop

sorawee commented 5 years ago

Good point. I should have included this. My setup:

MacOS GNU Emacs 26.1 Spacemacs on develop

aaronjensen commented 5 years ago

I haven't seen this and I have similar specs:

macOS 10.14.2 GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.10 Version 10.14.1 (Build 18B75)) of 2018-12-04 Spacemacs on develop

I have a pretty fast computer, which could matter (3.1 GHz, turbo up to 4.1)

lilactown commented 5 years ago

macOS 10.14.1 GNU Emacs 26.1 (build 1, x86_64-apple-darwin18.0.0, Carbon Version 158 AppKit 1671) of 2018-10-22 spacemacs on develop

Processor: 2.9 GHz i7 RAM: 16 GB

One thing to note is that if I type slowly, this seems to not be an issue. As I speed up my typing, it seems to occur more often.

E.g. if I go into visual mode in a file v and mash e to move to the end-of-word, eventually it will exit visual mode without meaning to.

aaronjensen commented 5 years ago

Just tried reproducing in that way in a big emacs lisp file. I have a very high key repeat rate and I held e down... it went never stopped (didn't repro) fwiw.

lilactown commented 5 years ago

It actually doesn't happen if you hold down a key, only if you're doing consecutive presses. But it might be something specific to my setup that is causing this as well.

lilactown commented 5 years ago

Like @sorawee, I rolled back my smartparens package to the commit before while-no-input was used and am working just fine now.

aaronjensen commented 5 years ago

Got it, I can't repro by doing consecutive presses either. And yea, it could also be something in my setup that's preventing it 😄

Fuco1 commented 5 years ago

Well I think it makes sense to roll back the patch and investigate more.

duianto commented 5 years ago

Confirmed.

If while-no-input is called in the smartparens.el sp-show--pair-function then the minibuffer prints Quit, while moving the cursor at a certain speed (not to fast and not to slow).

As Lokeh described above: https://github.com/Fuco1/smartparens/issues/946#issuecomment-450693018 , if a selection is activated before moving then it gets canceled.

And I've seen dropped characters while typing in the recent weeks.

It even happens when all code in sp-show--pair-function is commented out, and only (while-no-input) is called.

When (while-no-input) is commented out and the sp-show--pair-function is evaluated, then the issue disappears.

Another strange thing is that if the cursor is moved on smartparens.el's first buffer line (a comment), then the quit messages appear but a selection doesn't get canceled.

The issue doesn't seem to occur from the second line until the first open parenthesis, but as soon as the cursor moves to a line that starts with a parenthesis then the issue starts again.

The issue isn't limited to evil normal state, it also occurs with evil insert state, and the Emacs and Hybrid (normal and insert state) editing styles. (I haven't seen it mentioned as a possible cause, but it might be helpful to eliminate some variables)

The l (evil-forward-char) key is pressed at a constant rate, it seems slower because every time it prints Quit the cursor doesn't move forward.

quit messages

Here the v (evil-visual-char) key is pressed when the selection has been dropped.

selection canceled

This is with while-no-input commented out.

while-no-input commented

System Info :computer:

Fuco1 commented 5 years ago

Thanks for the detailed report!

For now I've reverted the commit on master so the next MELPA build should fix the issue. I'll investigate more.

aaronjensen commented 5 years ago

@duianto could you try reproducing with this patch: https://github.com/Fuco1/smartparens/pull/882/files#diff-8c6cbbe623569f436b910460c820384fL4208

aaronjensen commented 5 years ago

Actually, I believe this is why I cannot reproduce this, it appears to be fixed in Emacs 27: https://github.com/emacs-mirror/emacs/commit/2461266be

The commit message seems to indicate that the body should be testing quit-flag...

Original bug report: https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-06/msg00093.html

duianto commented 5 years ago

@aaronjensen Still happening after applying that patch and evaluating the sp--looking-back function.

aaronjensen commented 5 years ago

@duianto try it w/o the while-no-input

duianto commented 5 years ago

No quits or selection cancellations with the patch and while-no-input commented out.

Alexander-Miller commented 5 years ago

No quits or selection cancellations

Is it still as smooth? Try the large defun in spacemacs-common.el, smartparens needs about a second to highlight the corresponding parens on my end, but with while-no-input I can still navigate away freely.

duianto commented 5 years ago

@Alexander-Miller Do you have have specific reproduction steps? I don't see any slowdown in: c:/Users/username/.emacs.d/core/libs/spacemacs-theme/spacemacs-common.el

(Although I have aaronjensens patch applied and while-no-input commented out)

I can test with the current default settings, no patch and with while-no-input.

Nvm you said highlight corresponding parens.

When I move the cursor over the left most open parens on this line: (defun create-spacemacs-theme (variant theme-name)

Then there's a delay (no patch, while-no-input commented out), about 2 sec (probably depends on the cpu, I have an i3-2100 @ 3.10GHz).

With while-no-input there's no delay.

The delay is back with the patch and while-no-input commented out.

Alexander-Miller commented 5 years ago

Check the create-spacemacs-theme defun. The closing paranthesis is nearly 900 lines below. Without the while-no-input smartparens would freeze emacs while it searched for what to highlight. The new patch should not negate that improvement.

aaronjensen commented 5 years ago

I still feel some delay w/ my patch as well. There are a couple other loops (the while in sp-get-paired-expression, for example) that can benefit from an input-pending-p check as well, but that can get like whack-a-mole.

Perhaps the best option is to grab the while-no-input from emacs 27 and use it.

duianto commented 5 years ago

I downloaded the latest pretest: GNU Emacs 27.0.50 (build 1, i686-w64-mingw32) of 2018-10-05

When Spacemacs starts then I'm still seeing the Quit messages.

But as soon the function: sp-show--pair-function (with while-no-input) is evaluated (manually) then the Quit messages goes away. (aaronjensens patch is not applied).

There's no delay on the create-spacemacs-theme open parenthesis.

duianto commented 5 years ago

Here's someone that had used a backported while-no-input with aggressive-indent-mode for weeks (now months):

Backport while-no-input from Emacs 27.0 to fix #111 #118 https://github.com/Malabarba/aggressive-indent-mode/pull/118

Fuco1 commented 5 months ago

This was fixed in #958