Fuco1
commented
1 month ago Thanks for the report. There are some weird edge cases concerning org mode and source code blocks. 1.2 billion seems a bit excessive in the span of 5 seconds so I think your idea sounds about right, there must be something looping (maybe recursion would blow the stack first, but could also be in principle, you can check the value of max-lisp-eval-depth for the max recursive depth your Emacs supports).
Expected behavior
I installed smartparens, with the expectation that it would assist in routing parenthesis matching and sexp navigation without any noticeable perforannce hit.
Actual behavior
Very severe sluggishness in certain situations. For instance, inside an org-mode buffer, in an emacs-lisp src block, inside a string (such as "This is a string"). Note that editing the lisp code with org-edit-special doesn't have the problem.
The Emacs profiler reported over 1.2 billion calls to the org-self-insert-command, which in turn was calling sp--post-self-insert-hook-handler. (This is in the space of about 5 seconds writing just a few characters.)
The value of post-self-insert-hook is (sp--post-self-insert-hook-handler t).
This suggests that there is perhaps some kind of recursive loop taking place with smartparens somehow triggering the post-self-insert-hook.
Steps to reproduce the problem
Write a string inside an emacs-lisp src block in an org-mode buffer.
Backtraces if necessary (
M-x toggle-debug-on-error)Environment & version information
In recent enough
smartparensyou can callM-x sp-describe-systemto generate this report. Please fill manually what we could not detect automatically. Edit the output as you see fit to protect your privacy.smartparensversion: 20240415.2253M-x emacs-version): "GNU Emacs 29.3 (build 1, aarch64-apple-darwin23.4.0, NS appkit-2487.50 Version 14.4.1 (Build 23E224)) of 2024-04-19"