[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] bug#16832: Emacs goes crazy when deleting lines
|
From: |
Fabrice Niessen |
|
Subject: |
Re: [O] bug#16832: Emacs goes crazy when deleting lines |
|
Date: |
Fri, 14 Mar 2014 17:00:54 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) |
Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <address@hidden>
>> Cc: address@hidden
>> Date: Wed, 26 Feb 2014 20:42:20 +0100
>>
>> Eli Zaretskii wrote:
>> >> From: "Fabrice Niessen" <address@hidden>
>> >> Cc: address@hidden
>> >> 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)