Re: bug#16832: Emacs goes crazy when deleting lines

[Eli Zaretskii <eliz@gnu.org>]

> From: Fabrice Niessen <fni-news@pirilampo.org>
> Cc: 16832@debbugs.gnu.org, emacs-orgmode <emacs-orgmode@gnu.org>
> Date: Fri, 14 Mar 2014 17:00:54 +0100
> 
> I realized that Emacs did not into an infloop, but simply gave me back
> control after a very long time (more than 2 mins). Good news #1.
> 
> I thought at using the profiler of Emacs 24, and it gives meaningful
> results. Good news #2.
> 
> Here they are:
> 
> --8<---------------cut here---------------start------------->8---
> - flyspell-post-command-hook                                     3271  98%
>  - apply                                                         3271  98%
>   - ad-Advice-flyspell-post-command-hook                         3271  98%
>    - #<compiled 0xe22f27>                                        3271  98%
>     - byte-code                                                  3271  98%
>      - flyspell-word                                             3271  98%
>       - org-mode-flyspell-verify                                 3246  97%
>        - if                                                      3246  97%
>         - let*                                                   3246  97%
>          - prog1                                                 3053  91%
>           - catch                                                3053  91%
>            - while                                               3053  91%
>             - if                                                 3053  91%
>              - progn                                             3053  91%
>               - setq                                             3053  91%
>                - org-element--get-next-object-candidates         3053  91%
>                 - delq                                           3053  91%
>                  - if                                            3053  91%
>                   - mapcar                                       3053  91%
>                    - #<lambda 0x1741100e>                        3053  91%
>                     - funcall                                    3053  91%
>                      - org-element-inline-babel-call-successor   2873  86%
>                       - save-excursion                           2873  86%
>                          if                                      2873  86%

Thanks.  So this looks like a problem with Org Mode.  In particular,
org-element-inline-babel-call-successor takes a lot of time in this
case.  That function traverses the buffer from top to bottom:

      (while (search-forward "call_" nil t)
	(save-excursion
	  (goto-char (match-beginning 0))
	  (when (looking-at org-babel-inline-lob-one-liner-regexp)
	    (throw 'exit (cons 'inline-babel-call (point)))))))))

Perhaps this takes too long in such a huge buffer with such long
lines.

> Though, I don't understand yet why Flyspell seems to be a problem in Org
> mode buffers

Clearly, that's because Org functions, in particular
org-mode-flyspell-verify, are called from flyspell-post-command-hook:

  - flyspell-post-command-hook                                     3271  98%
   - apply                                                         3271  98%
    - ad-Advice-flyspell-post-command-hook                         3271  98%
     - #<compiled 0xe22f27>                                        3271  98%
      - byte-code                                                  3271  98%
       - flyspell-word                                             3271  98%
	- org-mode-flyspell-verify                                 3246  97%

If org-mode-flyspell-verify is expensive, it is not a good idea to use
it as flyspell-generic-check-word-predicate in huge Org buffers, since
Flyspell will invoke it after each command.

I hope Org developers will respond.  Or maybe you should simply submit
this bug report to Org bug tracker/list.