Daimrod <daimrod@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Hello,
>>
>> Daimrod <daimrod@gmail.com> writes:
>>
>>> I've attached part of the traces (the whole traces are way too big) and
>>> the backtraces.
>>
>> Thanks for looking into this. However, you are running a compiled Org,
>> which renders backtraces less useful.
>
> Ok, I was wondering why the backtraces was so ugly, I didn't think about
> byte-compilation... Thanks for the tip.
>
>> Also, you may want to disable cache refresh on idle time with, e.g.,
>>
>>   (setq org-element-cache-sync-idle-time 3600)
>>
>> It could make the bug easier to reproduce.
>
> Thanks, I'll try again this w.e.

Okay, so I've found a more or less reliable way to reproduce this bug (on my
machine at least).

1. $ emacs -Q -l debug.el test.org
2. Expand headline (<S-TAB>)
3. go below the first headline (C-n)
4. press `i' a couple of seconds ~10 chars
5. delete the line (C-a C-k)
6. goto 4 until if locks up

As I said, it's not completely reliable but so far the lockup always
happens. Sometimes it happens after the third iteration, sometimes after
the tenth iteration, but it always happen.

I've attached `debug.el' and `test.org'.

`debug.el' setup the "environment" to reproduce the bug, you may need to
change the path to your orgmode source base and you'll need
`adaptive-wrap-prefix-mode' (available on ELPA).

I've been able to reproduce the bug without `adaptive-wrap-prefix-mode'
though other people have reported the same symptoms without using it.


`test.org' is a simple org file with two headlines. It seems that two
headlines are required to trigger the cache mechanism (with
`org-element-cache--sync').


Do you confirm the lockup with this setting?

Best,