Eli Zaretskii wrote: >> From: "Fabrice Niessen" <fni-n...@pirilampo.org> >> Cc: 16...@debbugs.gnu.org >> Date: Wed, 26 Feb 2014 20:42:20 +0100 >> >> Eli Zaretskii wrote: >> >> From: "Fabrice Niessen" <fni-n...@pirilampo.org> >> >> Cc: 16...@debbugs.gnu.org >> >> Date: Wed, 26 Feb 2014 12:06:24 +0100 >> >> >> >> > Then try F12 (if you are on XP), or try attaching a debugger and >> >> > getting a C and Lisp backtrace. >> >> >> >> Hope this helps: >> > >> > Thanks. Without a Lisp-level backtrace, there's not enough useful >> > info here. >> >> Is there something I can do to get it in such a debugger session? > > Probably, but I don't know what to suggest. I don't understand the > error messages that you get from GDB, this usually happens when one > tries to attach a debugger to a program that is already being > debugged, which seems to be not the case here. Weird. > >> > Perhaps finding the minimal set of customizations that reproduces the >> > issue would lead faster to the solution. >> >> So you mean that the backtrace, with saveplace calls, does not lead to >> him as the culprit? > > These are not saveplace calls, this is Emacs searching for a string > that includes "saveplace.elc" and "save-place-alist" as substrings.
I made a big progress on this one. 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% + org-element-latex-or-entity-successor 81 2% + org-element-link-successor 35 1% + org-element-line-break-successor 19 0% + org-element-inline-src-block-successor 9 0% + org-element-footnote-reference-successor 5 0% + org-element-macro-successor 5 0% + org-element-statistics-cookie-successor 5 0% + org-element-timestamp-successor 5 0% + org-element-export-snippet-successor 4 0% + org-element-radio-target-successor 4 0% + org-element-target-successor 4 0% + org-element-sub/superscript-successor 3 0% + org-element-text-markup-successor 1 0% + org-element-at-point 193 5% + flyspell-word-search-forward 15 0% + redisplay_internal (C function) 28 0% + ... 27 0% --8<---------------cut here---------------end--------------->8--- Though, I don't understand yet why Flyspell seems to be a problem in Org mode buffers, and not in Text mode buffers: as you can see in the video on http://screencast.com/t/UiihFfPk, 1. Text mode + all my config (enabling Flyspell by default) is OK, (from 0:07 to 0:14, then undoing the changes) 2. Org mode + all my config (enabling Flyspell by default) is NOT OK. (from 0:40, blocking at 0:49, giving control back at 3:15) Best regards, Fabrice PS- Org-mode version 8.2.5h (release_8.2.5h-733-gd55438)