Nicolas Goaziou wrote:
> York Zhao writes:
>
>> I'm sorry but I really shouldn't send this document to anyone other than a
>> lawyer :-)
>
> [...]
>
>> Just want to confirm that you want me to run this command in that buffer
>> and see
>> if the problem can be reproduced?
>
> Calling the provided
> FWIW, I'm still getting regular lockups with the cache. I'll dig into it
> further when I have time.
I'm still being locked up from time to time, maybe less than before I guess.
What I said was that I never got the deadly problem of "Lisp nesting exceeds
`max-lisp-eval-depth", and the fix had be
York Zhao writes:
>> On Mon, Jun 30, 2014 at 8:43 PM, York Zhao
> wrote:
>
>> I got the problem today, with org-mode version "815c218" in Emacs
> 24.3.1. The
>> error message is: if: Lisp nesting exceeds `max-lisp-eval-depth'.
> Attached is
>> the backtrace saved in a file. Hope this will help.
> On Mon, Jun 30, 2014 at 8:43 PM, York Zhao wrote:
> I got the problem today, with org-mode version "815c218" in Emacs 24.3.1.
The
> error message is: if: Lisp nesting exceeds `max-lisp-eval-depth'.
Attached is
> the backtrace saved in a file. Hope this will help.
Just an update. I haven't been
>> + zfill-org-paragraph-boundary 7,240
0%
> What is that, if I may ask?
That's in my `zfill-mode' based on `refill-mode', and the function is part
of
the machinery to handle the automatic refilling of org paragraph.
> + ac-handle-post-command
York Zhao writes:
> Again, this happened in the big buffer that has 77,xxx lines, freshly
> opened. I
> restarted Emacs and finished `org-drill' session on 8 files before opening
> this
> big file.
>
> I then `M-x profile-start', typed a few letters and `M-x profile-report',
> here's
> the memory
Hello,
York Zhao writes:
> I'm sorry but I really shouldn't send this document to anyone other than a
> lawyer :-)
[...]
> Just want to confirm that you want me to run this command in that buffer
> and see
> if the problem can be reproduced?
Calling the provided command on your sensitive buff
> > The exact same slowness problem happened just now. "M-x
org-element-cache-reset"
> > didn't have any effect. Nor did setting `org-element-use-cache' to nil.
Again,
> > killed the buffer and reopened didn't help.
> It looks like the problem isn't related to the cache then. Anyway, you
> could tr
> Could you send me the document you were working on, in private, and
describe
> what you were doing before it froze?
I'm sorry but I really shouldn't send this document to anyone other than a
lawyer :-)
> or at least an equivalent file structure wise, calling the following
function
> in that doc
Hello,
York Zhao writes:
> The extreme slowness happened again just know. When this happened,
> `org-end-of-line' command took forever until "C-g". M-x
> org-element-cache-reset
> worked this time, i.e., after running `org-element-cache-reset' command
> `org-end-of-line' became fast again.
>
> I
The extreme slowness happened again just know. When this happened,
`org-end-of-line' command took forever until "C-g". M-x
org-element-cache-reset
worked this time, i.e., after running `org-element-cache-reset' command
`org-end-of-line' became fast again.
I was using commit "ca6ecf9", and the buff
> > The exact same slowness problem happened just now. "M-x
org-element-cache-reset"
> > didn't have any effect. Nor did setting `org-element-use-cache' to nil.
Again,
> > killed the buffer and reopened didn't help.
> It looks like the problem isn't related to the cache then. Anyway, you
> could tr
> Thank you for the report. I wasn't able to reproduce it with latest commit
> (df9ccbd). Could you try again and see if it fixes your problem?
I haven't experienced this problem since July 3, hopefully it has been
fixed.
Thank you very much for your work.
York
Hello,
York Zhao writes:
> The exact same slowness problem happened just now. "M-x
> org-element-cache-reset"
> didn't have any effect. Nor did setting `org-element-use-cache' to nil. Again,
> killed the buffer and reopened didn't help.
It looks like the problem isn't related to the cache then
Hello,
York Zhao writes:
> I'm now using commit "fdc673d". The problem I experienced 2 days ago happened
> again. The direct operations I did was that I programmatically deleted a few
> table line in one table and inserted them in another table which is in the
> subtree immediately following the
> I'm now using commit "fdc673d". The problem I experienced 2 days ago happened
> again. The direct operations I did was that I programmatically deleted a few
> table line in one table and inserted them in another table which is in the
> subtree immediately following the current table. But I ended
> I'm now using commit "126e2bc", this morning I did experience some funny
> things which I had never experienced before. Unfortunately I let them go. I
> will keep an eye on the new problems.
I'm now using commit "fdc673d". The problem I experienced 2 days ago happened
again. The direct operation
> OK. If you experience it again, please do
>
> M-x org-element-cache-reset
>
> in the slow buffer and see if it is responsive again.
>
> Another interesting test would be to try reproducing the problem with
> `org-element-use-cache' set to nil.
The exact same slowness problem happened just now.
Hello,
York Zhao writes:
> Just suffered from extreme slowness. My Emacs had been running for about 1
> hour
> and I was having two org-mode buffers, one file has 3800 lines, 168 KB bytes.
> And the other has 76,600 lines, 4,267,327 KB bytes. Both files had been opened
> for awhile. Didn't have
Just suffered from extreme slowness. My Emacs had been running for about 1 hour
and I was having two org-mode buffers, one file has 3800 lines, 168 KB bytes.
And the other has 76,600 lines, 4,267,327 KB bytes. Both files had been opened
for awhile. Didn't have problem in the beginning, but then typ
> Please update, if you can. I pushed a couple of fixes a few hours ago. It may
> solve the problem.
I noticed the new commits after my previous report. I'm now using commit
"126e2bc", this morning I did experience some funny things which I had never
experienced before. Unfortunately I let them go
Hello,
York Zhao writes:
> I got the problem today, with org-mode version "815c218" in Emacs 24.3.1. The
> error message is: if: Lisp nesting exceeds `max-lisp-eval-depth'. Attached is
> the backtrace saved in a file.
Please update, if you can. I pushed a couple of fixes a few hours ago.
It may
On 2014-06-30 03:43, York Zhao writes:
> I know that doesn't help much except for confirming the problem other people
> was
> suffering. Sorry for the rant. I was too busy and too frustrated.
>
> By the way, what does ECM stands for?
Exemple Complet Minimal (French for minimal complete example)
I know that doesn't help much except for confirming the problem other people was
suffering. Sorry for the rant. I was too busy and too frustrated.
By the way, what does ECM stands for?
> This is an entirely different issue, since maint branch doesn't have a cache.
I must clarify that what I mean
> Yeah, I'm using git emacs, labeled 24.4.50.1
Did you compile Emacs from git? I have never seen the tag 24.4.50.1, are you
sure you didn't have a typo here?
On Sat, Jun 28, 2014 at 10:23 PM, Eric Abrahamsen
wrote:
> York Zhao writes:
>
>> My experience of using `org-mode' (git commit "2824502"
Hello,
York Zhao writes:
> My experience of using `org-mode' (git commit "2824502" and previous versions)
> with Emacs 24.3.91 (git commit "0f0917d") had been a nightmare. I got bitten
> by
> this bug frequently, I was mad.
I'm sorry about this.
However, just saying that "it had been a nightm
York Zhao writes:
> My experience of using `org-mode' (git commit "2824502" and previous versions)
> with Emacs 24.3.91 (git commit "0f0917d") had been a nightmare. I got bitten
> by
> this bug frequently, I was mad. Some of my `org-drill' entires might have been
> damaged to some extent. This w
My experience of using `org-mode' (git commit "2824502" and previous versions)
with Emacs 24.3.91 (git commit "0f0917d") had been a nightmare. I got bitten by
this bug frequently, I was mad. Some of my `org-drill' entires might have been
damaged to some extent. This was a problem with Emacs 24.3.1
Eric Abrahamsen writes:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Eric Abrahamsen writes:
>>
>>> None of those three, I'm afraid! It was hanging on a variety of editing
>>> operations that, as far as I can tell, had little in common. There's a
>>> possibility that they were list-item-related,
Hello,
Alan Schmitt writes:
> I've also just been bitten by this bug, as I was doing my weekly
> review. I'll try to see if I can write an ECM, but for the record this
> is what I was doing: I was in an agenda view sorted by the value of
> a LAST_REVIEW property, and I was repeatedly calling thi
I've also just been bitten by this bug, as I was doing my weekly
review. I'll try to see if I can write an ECM, but for the record this
is what I was doing: I was in an agenda view sorted by the value of
a LAST_REVIEW property, and I was repeatedly calling this function on
the entries of the view:
Hello,
Sebastien Vauban
writes:
> I also still experience semi-regular Emacs infloops, particularly when
> editing clocking entries manually (with the arrow keys), in the LOGBOOK
> drawer. It's quite often in such a situation, though not 100%
> reproducible.
I tried but couldn't reproduce it.
Hello,
Matt Lundin writes:
> With "killall -USR2 emacs", the following backtrace popped up, which
> highlights flyspell as the culrpit. Note: I have flyspell turned on in
> all text buffers, but I have (for several months) only experienced
> lockups when using org-mode. I spend more time in TeX
Matt Lundin writes:
> With "killall -USR2 emacs", the following backtrace popped up, which
> highlights flyspell as the culrpit.
~~~
And, of course, I had flyspell turned off when writing this email. :)
Matt
Daimrod writes:
> Matt Lundin writes:
>>
>> With the latest git, I've experienced three lock-ups/freezes this
>> evening when a) archiving a subtree to a file, b) changing a todo state
>> with repeating timestamp, and 3) calling C-c C-c in an org-capture
>> buffer. (I don't think this is due to
Daimrod writes:
> Matt Lundin writes:
>
>>
>> The freezes are very difficult to replicate reliably. When they happen,
>> emacs is unresponsive and can only be killed from the outside. Any tips
>> on how to debug this would be greatly appreciated.
>
> See my previous post:
> http://thread.gmane.o
Bastien writes:
> Hi Eric,
>
> Eric Abrahamsen writes:
>
>> I think the advice here was also to run Org uncompiled, as that produces
>> a more useful backtrace, is that right?
>
> Yes, that's right -- generally, backtraces from compiled Org are
> mungled, while backtraces from an uncompiled Org
Hi Eric,
Eric Abrahamsen writes:
> I think the advice here was also to run Org uncompiled, as that produces
> a more useful backtrace, is that right?
Yes, that's right -- generally, backtraces from compiled Org are
mungled, while backtraces from an uncompiled Org are readable.
> A couple of ti
Daimrod writes:
> Matt Lundin writes:
>
>> Eric Abrahamsen writes:
>>
>>> Nicolas Goaziou writes:
>>>
Hello,
Eric Abrahamsen writes:
> None of those three, I'm afraid! It was hanging on a variety of editing
> operations that, as far as I can tell, had little in com
Matt Lundin writes:
> Eric Abrahamsen writes:
>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> Eric Abrahamsen writes:
>>>
None of those three, I'm afraid! It was hanging on a variety of editing
operations that, as far as I can tell, had little in common. There's a
possibility
Matt Lundin wrote:
> Eric Abrahamsen writes:
>> Nicolas Goaziou writes:
>>> Eric Abrahamsen writes:
>>>
None of those three, I'm afraid! It was hanging on a variety of editing
operations that, as far as I can tell, had little in common. There's a
possibility that they were list-it
Matt Lundin writes:
> Eric Abrahamsen writes:
>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> Eric Abrahamsen writes:
>>>
None of those three, I'm afraid! It was hanging on a variety of editing
operations that, as far as I can tell, had little in common. There's a
possibility
Eric Abrahamsen writes:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Eric Abrahamsen writes:
>>
>>> None of those three, I'm afraid! It was hanging on a variety of editing
>>> operations that, as far as I can tell, had little in common. There's a
>>> possibility that they were list-item-related,
Nicolas Goaziou writes:
> Hello,
>
> Eric Abrahamsen writes:
>
>> None of those three, I'm afraid! It was hanging on a variety of editing
>> operations that, as far as I can tell, had little in common. There's a
>> possibility that they were list-item-related, but really there wasn't
>> much com
Hello,
Eric Abrahamsen writes:
> None of those three, I'm afraid! It was hanging on a variety of editing
> operations that, as far as I can tell, had little in common. There's a
> possibility that they were list-item-related, but really there wasn't
> much commonality.
FYI, I recently fixed a b
Hello,
Daimrod writes:
> Thanks for investigating.
I made some progress. Alas I didn't find a definitive answer yet.
The problem is related to `quail-input-method', which let-binds
`inhibit-modifications-hooks' to t. This is usually done around
a function that modifies text properties in a buf
Nicolas Goaziou writes:
> Daimrod writes:
>
>> My guess is that the lockup happens in `org-element--cache-key-less-p',
>> called by `org-element--cache-process-request'.
>
> Probably, but it doesn't mean that this particular function is buggy.
> The lockup happens there because the cache gets co
Daimrod writes:
> My guess is that the lockup happens in `org-element--cache-key-less-p',
> called by `org-element--cache-process-request'.
Probably, but it doesn't mean that this particular function is buggy.
The lockup happens there because the cache gets corrupted at some point.
After invest
Nicolas Goaziou writes:
> Hello,
>
> Daimrod writes:
>
>> 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 ()
>> 3. go below the first headline (C-n)
>> 4. press `i' a couple of secon
Hello,
Daimrod writes:
> 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 ()
> 3. go below the first headline (C-n)
> 4. press `i' a couple of seconds ~10 chars
> 5. delete the line (C-a
Daimrod writes:
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Daimrod 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.
>
Eric Abrahamsen writes:
> Daimrod writes:
>
>> Bastien writes:
>>
>>> Hi Eric,
>>>
>>> Eric Abrahamsen writes:
>>>
After Nicolas made the last round of improvements to the caching
mechanism I got far fewer hangs with Org, but they are still happening.
Maybe once a day or so, on
Daimrod writes:
> Bastien writes:
>
>> Hi Eric,
>>
>> Eric Abrahamsen writes:
>>
>>> After Nicolas made the last round of improvements to the caching
>>> mechanism I got far fewer hangs with Org, but they are still happening.
>>> Maybe once a day or so, on average, editing something in an Org b
Nicolas Goaziou writes:
> Hello,
>
> Daimrod 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 bac
Hello,
Daimrod 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.
Also, you may want to disable cache refresh on idle time with, e.g.,
Daimrod writes:
> Eric Abrahamsen writes:
>
>> On 05/19/14 23:21 PM, Daimrod wrote:
>>> Daimrod writes:
>>>
I have also semi-regular lockup with org-mode. I have opened a bug on
debbugs and here is what Stefan told me to try to debug this:
> You can try `debug-on-event'.
Eric Abrahamsen writes:
> On 05/19/14 23:21 PM, Daimrod wrote:
>> Daimrod writes:
>>
>>> I have also semi-regular lockup with org-mode. I have opened a bug on
>>> debbugs and here is what Stefan told me to try to debug this:
>>>
You can try `debug-on-event'.
There's jit-lock-debu
On 05/19/14 23:21 PM, Daimrod wrote:
> Daimrod writes:
>
>> I have also semi-regular lockup with org-mode. I have opened a bug on
>> debbugs and here is what Stefan told me to try to debug this:
>>
>>> You can try `debug-on-event'.
>>>
>>> There's jit-lock-debug-mode but it doesn't disable inhib
Daimrod writes:
> I have also semi-regular lockup with org-mode. I have opened a bug on
> debbugs and here is what Stefan told me to try to debug this:
>
>> You can try `debug-on-event'.
>>
>> There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
>> So you'll need to additionally use
Daimrod writes:
> Eric Abrahamsen writes:
>
>> Daimrod writes:
>>
>>> Bastien writes:
>>>
Hi Eric,
Eric Abrahamsen writes:
> After Nicolas made the last round of improvements to the caching
> mechanism I got far fewer hangs with Org, but they are still happening.
>
Eric Abrahamsen writes:
> Daimrod writes:
>
>> Bastien writes:
>>
>>> Hi Eric,
>>>
>>> Eric Abrahamsen writes:
>>>
After Nicolas made the last round of improvements to the caching
mechanism I got far fewer hangs with Org, but they are still happening.
Maybe once a day or so, on
Daimrod writes:
> Bastien writes:
>
>> Hi Eric,
>>
>> Eric Abrahamsen writes:
>>
>>> After Nicolas made the last round of improvements to the caching
>>> mechanism I got far fewer hangs with Org, but they are still happening.
>>> Maybe once a day or so, on average, editing something in an Org b
Daimrod writes:
> I'll try to see what I can find this week end and report back.
Great -- thanks for the guidance!
--
Bastien
Bastien writes:
> Hi Eric,
>
> Eric Abrahamsen writes:
>
>> After Nicolas made the last round of improvements to the caching
>> mechanism I got far fewer hangs with Org, but they are still happening.
>> Maybe once a day or so, on average, editing something in an Org buffer
>> causes emacs to han
Hi Eric,
Eric Abrahamsen writes:
> After Nicolas made the last round of improvements to the caching
> mechanism I got far fewer hangs with Org, but they are still happening.
> Maybe once a day or so, on average, editing something in an Org buffer
> causes emacs to hang, and my fans to spin up, a
hanges.
Good to know, thanks!
> hope this helps,
> dieter
>
> [1]
> http://www.gnu.org/software/emacs/manual/html_node/elisp/Infinite-Loops.html#Infinite-Loops
>
>
>
>> Original Message
>>From: Eric Abrahamsen
>>To: emacs-orgmode@gnu.org
>>Sen
> Original Message
>From: Eric Abrahamsen
>To: emacs-orgmode@gnu.org
>Sent: Wed, May 14, 2014, 10:36 AM
>Subject: [O] still seeing semi-regular lockups
>
>Hey there,
>
>After Nicolas made the last round of improvements to the caching
>mechanism I got far fewe
Hey there,
After Nicolas made the last round of improvements to the caching
mechanism I got far fewer hangs with Org, but they are still happening.
Maybe once a day or so, on average, editing something in an Org buffer
causes emacs to hang, and my fans to spin up, and there we are until I
kill ema
68 matches
Mail list logo
