spacemacs
spacemacs copied to clipboard
syl20bnr
Search failed. This means there is unmatched expression somewhere or we are at the beginning/end of file
Every time I type ( at a buffer, emacs will automatically give me (). Then I press C-f to move the cursor forward inside the parentheses, hit C-d to delete the right paretheses, the buffer will freeze for half a minute and show me the message: Search failed. This means there is unmatched expression somewhere or we are at the beginning/end of file.
Can anybody help me to disable this annoying thing? Thank you.
This is caused by smartparens mode. https://github.com/Fuco1/smartparens
You can disable the package by adding it to dotspacemacs-excluded-packages but I would check the following .spacemacs settings first:
;; If non-nil smartparens-strict-mode will be enabled in programming modes.
;; (default nil)
dotspacemacs-smartparens-strict-mode nil
;; If non-nil pressing the closing parenthesis `)' key in insert mode passes
;; over any automatically added closing parenthesis, bracket, quote, etc…
;; This can be temporary disabled by pressing `C-q' before `)'. (default nil)
dotspacemacs-smart-closing-parenthesis nil
You may find that if one is one it could be causing the problem. Note that if you disable smartparens they may not auto close and you'll want to investigate other options like electric-pair-mode.
@chasinglogic Thanks for response. My default setting is
;; If non-nil smartparens-strict-mode will be enabled in programming modes.
;; (default nil)
dotspacemacs-smartparens-strict-mode nil
;; If non-nil pressing the closing parenthesis `)' key in insert mode passes
;; over any automatically added closing parenthesis, bracket, quote, etc…
;; This can be temporary disabled by pressing `C-q' before `)'. (default nil)
I added your last line on my configure and the following message shows up:
Search failed. This means there is unmatched expression somewhere or we are at the beginning/end of file.
Error running timer `sp-show--pair-function': (beginning-of-buffer)
@leolle As a debugging step can you add smartparens to your dotspacemacs-excluded-packages ?
I wouldn't recommend leaving it like this but it'd be an easy way to tell if that's the actual performance problem your running into. (I too have smartparens show this message from time to time but don't experience the freezes that you are).
Additionally we can tell exactly what's hanging up using one of two methods:
1. Profiling
Emacs has a built in profiler that you can start at any time using M-x profiler-start. You can run just cpu profiling or cpu+mem (usually Emacs hang ups are cpu bound not memory bound). If you start it just before triggering the bug that would give us the best info. After the freeze has finished and Emacs is mostly back to normal run M-x profiler-report and you'll get a buffer with a bunch of output, if you could post that in the comments that would be helpful. Remember that after you're done to run M-x profiler-stop you do take a performance hit for running the profiling.
2. Kill Signals
If the freeze is lasting long enough you can actually send the emacs process a special kill signal that will cause it to crash the current function call and spit out a backtrace. The instructions for doing so are here: https://emacs.stackexchange.com/questions/506/debugging-a-frozen-emacs#answer-649
I've copy and pasted the relevant answer:
$ kill -SIGUSR2 <emacs_pid_goes_here>
This will make Emacs attempt to break out of its current loop into the Lisp debugger.
Or use this one liner without typing emacs pid manually:
$ ps aux | grep -ie emacs | grep -v grep | awk '{print $2}' | xargs kill -SIGUSR2
Alternatively, if killall is available:
$ killall -USR2 emacs
Using one of both of these methods would be helpful.
@chasinglogic Hi, below is the report content: Memory:
- timer-event-handler 1,070,720,899 88%
- byte-code 1,070,659,523 88%
- apply 1,070,644,413 88%
- sp-show--pair-function 1,027,103,387 85%
- #<compiled 0x1a01df9> 1,024,003,361 84%
- sp-get-thing 1,024,001,265 84%
- sp-get-sexp 1,022,562,965 84%
- sp-get-expression 1,022,558,741 84%
- sp-get-stringlike-or-textmode-expression 1,020,747,753 84%
- sp-get-string 1,020,710,345 84%
- sp-skip-into-string 1,020,701,961 84%
- sp-point-in-string 1,004,799,321 83%
- byte-code 901,777,017 74%
- syntax-ppss 692,791,083 57%
- funcall 185,552,455 15%
#<compiled 0x1d06595> 158,730,954 13%
make-byte-code 9,204 0%
vector 3,019 0%
+ sp-point-in-comment 6,288 0%
+ sp-point-in-string 2,096 0%
+ sp-get-stringlike-expression 35,296 0%
+ sp-get-paired-expression 1,068,204 0%
+ sp--get-allowed-regexp 399,884 0%
+ sp--get-stringlike-regexp 304,472 0%
sp--search-backward-regexp 22,788 0%
sp--search-forward-regexp 2,048 0%
+ sp-skip-backward-to-symbol 643,320 0%
+ sp--get-allowed-pair-list 467,088 0%
+ sp--get-closing-regexp 89,976 0%
+ sp-skip-forward-to-symbol 88,320 0%
+ sp--get-opening-regexp 85,916 0%
+ sp--looking-back 35,212 0%
+ sp-point-in-empty-string 11,504 0%
sp--looking-at 3,356 0%
sp-show--pair-create-overlays 1,040 0%
- sp--get-allowed-regexp 997,820 0%
- sp--get-allowed-pair-list 624,112 0%
+ sp--do-action-p 618,912 0%
+ sp--strict-regexp-opt 359,148 0%
apply 5,200 0%
mapcar 4,160 0%
+ sp--get-stringlike-regexp 801,728 0%
+ sp--get-allowed-pair-list 636,448 0%
+ sp--get-opening-regexp 319,196 0%
+ sp--get-closing-regexp 235,280 0%
+ sp--looking-back 68,150 0%
+ semantic-idle-scheduler-function 33,120,622 2%
+ company-idle-begin 5,368,070 0%
+ flycheck-handle-idle-change 3,621,626 0%
+ #<compiled 0x1bca32d> 1,416,148 0%
jit-lock-context-fontify 4,160 0%
+ hl-paren-highlight 4,144 0%
auto-revert-buffers 1,040 0%
+ timer-activate-when-idle 35,360 0%
+ timer-inc-time 12,496 0%
+ timer-activate 7,280 0%
timer-until 1,040 0%
+ command-execute 83,190,938 6%
+ redisplay_internal (C function) 47,734,276 3%
+ delete-selection-pre-hook 2,333,332 0%
+ xselect-convert-to-string 393,392 0%
+ winner-save-old-configurations 335,008 0%
+ linum-update-current 316,070 0%
+ comint-output-filter 248,259 0%
+ company-post-command 121,604 0%
+ sp--save-pre-command-state 90,528 0%
+ flycheck-handle-signal 43,940 0%
+ url-http-generic-filter 41,454 0%
+ yas--post-command-handler 32,384 0%
+ global-hl-line-highlight 8,480 0%
+ which-key--hide-popup 5,200 0%
+ global-font-lock-mode-check-buffers 2,080 0%
+ global-evil-search-highlight-persist-check-buffers 2,080 0%
+ global-vi-tilde-fringe-mode-check-buffers 2,080 0%
xselect-convert-to-targets 2,080 0%
+ hl-paren-initiate-highlight 1,056 0%
+ sp--pair-overlay-post-command-handler 960 0%
+ flycheck-display-error-at-point-soon 720 0%
... 0 0%
CPU:
- timer-event-handler 24493 83%
- byte-code 24493 83%
- apply 24493 83%
- sp-show--pair-function 24075 82%
- #<compiled 0x1a01df9> 23769 81%
- sp-get-thing 23769 81%
- sp-get-sexp 23598 80%
- sp-get-expression 23598 80%
- sp-get-stringlike-or-textmode-expression 23460 80%
- sp-get-string 23460 80%
- sp-skip-into-string 22737 77%
- sp-point-in-string 22587 77%
- byte-code 22214 75%
- syntax-ppss 21500 73%
+ funcall 18769 64%
+ sp-get-paired-expression 73 0%
+ sp--get-stringlike-regexp 28 0%
+ sp--get-allowed-regexp 24 0%
+ sp--search-backward-regexp 13 0%
+ sp-skip-backward-to-symbol 75 0%
+ sp--get-allowed-pair-list 61 0%
+ sp-skip-forward-to-symbol 12 0%
sp--looking-back 12 0%
+ sp--get-opening-regexp 7 0%
- sp--get-allowed-regexp 122 0%
+ sp--get-allowed-pair-list 95 0%
+ sp--strict-regexp-opt 24 0%
mapcar 3 0%
+ sp--get-stringlike-regexp 54 0%
+ sp--get-allowed-pair-list 51 0%
+ sp--looking-back 21 0%
+ sp--get-opening-regexp 19 0%
+ sp--get-closing-regexp 7 0%
+ company-idle-begin 212 0%
+ semantic-idle-scheduler-function 118 0%
+ flycheck-handle-idle-change 14 0%
+ hl-paren-highlight 4 0%
+ ... 1913 6%
+ command-execute 1751 5%
+ redisplay_internal (C function) 872 2%
+ delete-selection-pre-hook 130 0%
+ linum-update-current 92 0%
+ which-key--hide-popup 15 0%
+ company-post-command 14 0%
+ evil--jump-hook 13 0%
+ winner-save-old-configurations 11 0%
+ sp--save-pre-command-state 7 0%
yas--post-command-handler 6 0%
+ flycheck-display-error-at-point-soon 4 0%
If I still want to use smartparent(yes, it does help me a lot), what should I do?
So at this point we have great debugging information but it all points to smartparens being the issue not spacemacs. I would recommend taking this info upstream to smartparens. Additionally I would want to know:
- Version of Emacs
- Version of Spacemacs
- Version of Smartparens (maybe you need to update the package)
- Does this happen in all major modes? If not which ones does it effect?
GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2016-07-01 on weiwu-VirtualBox
Spacemacs v.0.105.21
smartparens is an installed package.
Status: Installed in `~/.emacs.d/elpa/smartparens-20160619.322/' (unsigned).
Archive: n/a
Version: 20160619.322
Requires: dash-2.12.1, cl-lib-0.3 Summary: Automatic insertion, wrapping and paredit-like navigation with user defined pairs. Other versions: 20170917.104 (melpa-cn).
[back]
My daily usage of emacs is org mode, python mode and Inferior Python mode, this issue only happens at working on python.
I am getting a similar message when the cursor is on '>' character in '=>' in react-layer.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Can't provide the exact steps to reproduce(yet) but this message/warning freezes my spacemacs pretty regularly.
Happens only in Clojure mode in my case
This happened to me when I was in rspec mode trying to run tests for the current file. I was able to get rid of this message and run my tests, after I enabled and disabled rspec mode in some another buffer.
Very annoying for me too. I notice that it might stop Emacs if the buffer content is quite large. like in ESS inferior R mode, where I run an R interactive console, and it can be easy to have lots of contents in this buffer. Then if I type ), the emacs has no responses at all ...
I often, when editing in org-mode seem to run in to a pause when I enter the ) character. When I toggle debug-on-quit, I can see that it is stuck looking for. the matching open parenthesis in spacemacs/smart-closing-parenthesis.
I've tried turning off smartparens, but that doesn't seem to have any effect on this function which seems to always search for a matching open parens.
I wouldn't mind if this was in elisp or something, but when typing in things in org-mode, when I'm taking notes, it is really annoying when it happens, totally ruining the flow of the typing that I'm doing.
If it at least respected the smartparens on or off it that would be OK and I could disable it for the buffer, but it doesn't appear to.
I'm using the latest develop branch and also emacs 28, but have experienced it for a long time, just put up with it.
Please consider adding some sort of test at the start of the function to check if smartparens is enabled or not, or at least some spacemacs specific variable is set or not.
I realise now after looking at this that there is an initialization toggle, but that seems to be the wrong level to have it at?
This still happens to me in Fortran mode. It seems to be resolved temporarily after I run 'M-x revert-buffer' but it immediately comes back after I insert a snippet. Does anybody have any idea how to fix this? I'd really like to see this back to working as it is quite convenient.
Found a workaround based on this link: https://github.com/syl20bnr/spacemacs/issues/541#issue-56511290
Quote it here:
The issue is described here: Fuco1/smartparens#431
To workaround this, we can disable smartparens before snippet is inserted and enable after the snippet is inserted:
(add-hook 'yas-before-expand-snippet-hook (lambda () (smartparens-mode -1))) (add-hook 'yas-after-exit-snippet-hook (lambda () (smartparens-mode 1)))
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!