Hi List, I have an org-mode file that is 3230004 bytes in size. With commit "92f30ae" it can be opened without any problem. However, with commit "5ea0228" the same file could not be opened properly. What I did was: I opened Dired buffer, select the file, press enter, nothing happened and Emacs locks up, hit C-g to get out, and I noticed that the file had actually been opened, so I just visited the buffer, this time the contents of the file appeared, but my org-tables are not fontified at all. Just now I tried again, this time I toggled "debug on error" on, closed the file, and tried to open the file, again, Emacs locks up, hit C-g and my emacs revived, again, the file had been opened, just didn't show up. So I visited the buffer, this time my org-tables are fontified properly. What's the problem do you think this could be? Thanks, York
York Zhao <gtdplatform@gmail.com> writes:
> Hi List,
>
> I have an org-mode file that is 3230004 bytes in size. With commit "92f30ae" it
> can be opened without any problem. However, with commit "5ea0228" the same file
> could not be opened properly.
>
> What I did was: I opened Dired buffer, select the file, press enter, nothing
> happened and Emacs locks up, hit C-g to get out, and I noticed that the file had
> actually been opened, so I just visited the buffer, this time the contents of
> the file appeared, but my org-tables are not fontified at all.
>
> Just now I tried again, this time I toggled "debug on error" on, closed the
> file, and tried to open the file, again, Emacs locks up, hit C-g and my emacs
> revived, again, the file had been opened, just didn't show up. So I visited the
> buffer, this time my org-tables are fontified properly.
>
> What's the problem do you think this could be?
>
>
Sounds like an infinite loop, but there isn't enough information to
determine where. Can you set debug-on-quit, try again and post the
backtrace?
Thanks,
--
Nick
Nick Dokos <ndokos@gmail.com> writes:
> York Zhao <gtdplatform@gmail.com> writes:
>
>> Hi List,
>>
>> I have an org-mode file that is 3230004 bytes in size. With commit "92f30ae" it
>> can be opened without any problem. However, with commit "5ea0228" the same file
>> could not be opened properly.
>>
>> What I did was: I opened Dired buffer, select the file, press enter, nothing
>> happened and Emacs locks up, hit C-g to get out, and I noticed that the file had
>> actually been opened, so I just visited the buffer, this time the contents of
>> the file appeared, but my org-tables are not fontified at all.
>>
>> Just now I tried again, this time I toggled "debug on error" on, closed the
>> file, and tried to open the file, again, Emacs locks up, hit C-g and my emacs
>> revived, again, the file had been opened, just didn't show up. So I visited the
>> buffer, this time my org-tables are fontified properly.
>>
>> What's the problem do you think this could be?
>>
>>
> Sounds like an infinite loop, but there isn't enough information to
> determine where. Can you set debug-on-quit, try again and post the
> backtrace?
>
I tried and failed to reproduce the problem.
In a private communication (I hope he reposts it to the list), the OP
said that he *had* turned on debug-on-quit (he misspoke when he said
debug-on-error) but there was no backtrace when he pressed C-g (that in
itself indicates a problem, either with emacs or with the OP's setup.)
He mentioned that he was using a derived mode, so I tried to reproduce
the problem with the following minimal org file:
--8<---------------cut here---------------start------------->8---
(add-to-list 'load-path "~/src/emacs/org/org-mode/lisp")
(add-to-list 'load-path "~/src/emacs/org/org-mode/contib/lisp")
(require 'org-loaddefs)
(define-derived-mode ndk-mode org-mode "ndk")
(add-to-list 'auto-mode-alist '("\\.ndk$" . ndk-mode))
--8<---------------cut here---------------end--------------->8---
I copied an org file (albeit a small one: 15K - I don't have anything
as big as the OP's 3Mb file) to foo.ndk and started emacs with
emacs -Q -l /path/to/minimal/min.org.el foo.ndk
Everything works as expected and I don't get a hang/inf-loop or any
other problem.
It may be that hack-local-variables takes a long time to process a large
file, although I don't think so: iirc, it limits itself to a tail of the
file of a given size, or the last "page" of the file (demarcated by ^L),
whichever is smaller.
Does CPU utilization go to 100% (on the core that emacs is running on)
when emacs is unresponsive? Does emacs -Q with a minimal org file as
above solve the problem (i.e. is the problem with the OP's .emacs)?
Questions, questions...
Nick
Nick Dokos <ndokos@gmail.com> writes: > It may be that hack-local-variables takes a long time to process a large > file, although I don't think so: iirc, it limits itself to a tail of the > file of a given size, or the last "page" of the file (demarcated by ^L), > whichever is smaller. Hi Nick, I haven't noticed any slowdown or hangs since hack-local-variables was introduced. I have noticed that I need to answer the query about loading file local variables twice: Please type y, n, or !, or C-v to scroll: y [2 times] The first y has no apparent effect (except to make the second y effective). hth, Tom -- Thomas S. Dye http://www.tsdye.com
Oop, I didn't know that I replied to Nicolas instead of to the list because I
hitted "reply" instead of "reply all". So I'm reposting my previous post to the
list. Here we go:
In my previous post I actually meant to say that I set `debug-on-quit', have no
idea why I did `debug-on-error'. But anyways, I'm now pretty sure it was commit
"5ea0228" that causes problem because the moment I deleted the last two lines in
(define-derived-mode org-mode outline-mode "Org") everything worked fine.
Demonstrated below:
(define-derived-mode org-mode outline-mode "Org"
...
;; Delete these two lines and everything worked.
(report-errors "File local-variables error: %s"
(hack-local-variables))
)
Also, I figured out that it was my major mode that derived from `org-mode'
didn't work, and the buffer showed in org-mode, instead of my derived mode. But
my mode is as simple as:
(define-derived-mode yhj-mode org-mode "yhj"
)
With some special key bindings specific to my file that is opened in `yhj-mode'.
By the way, I had toggled `debug-on-quit', but made no difference when I hit
C-g.
Thanks,
York
On Mon, Nov 25, 2013 at 2:26 PM, Thomas S. Dye <tsd@tsdye.com> wrote:
> Nick Dokos <ndokos@gmail.com> writes:
>
>> It may be that hack-local-variables takes a long time to process a large
>> file, although I don't think so: iirc, it limits itself to a tail of the
>> file of a given size, or the last "page" of the file (demarcated by ^L),
>> whichever is smaller.
>
> Hi Nick,
>
> I haven't noticed any slowdown or hangs since hack-local-variables was
> introduced.
>
> I have noticed that I need to answer the query about loading file local
> variables twice:
>
> Please type y, n, or !, or C-v to scroll: y [2 times]
>
> The first y has no apparent effect (except to make the second y
> effective).
>
> hth,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>
OK, finally I was able to reproduce the problem with a minimal setup.
First goes .emacs file:
--8<---------------cut here---------------start------------->8---
(add-to-list 'load-path "path/to/org-mode")
(add-to-list 'load-path "path/to/org-mode/lisp") ; this line is the key
(add-to-list 'load-path "path/to/yhj-mode")
(require 'yhj-mode)
--8<---------------cut here---------------end--------------->8---
Second goes yhj-mode.el:
--8<---------------cut here---------------start------------->8---
(require 'org)
(define-derived-mode yhj-mode org-mode "yhj")
(provide 'yhj-mode)
--8<---------------cut here---------------end--------------->8---
Finally, file test.yz:
--8<---------------cut here---------------start------------->8---
# -*- mode:yhj -*-
--8<---------------cut here---------------end--------------->8---
Open file "test.yz" and note the comment line not fortified, open "*message*"
buffer and note the following error:
File local-variables error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
There are three keys to reproduce, first, you have to make two files, .emacs and
"yhj-mode.el". Second, this line must be present:
(add-to-list 'load-path "path/to/org-mode/lisp") ; this line is the key
Third, file "yhj-mode.el" has to be byte-compiled.
York
On Mon, Nov 25, 2013 at 5:39 PM, York Zhao <gtdplatform@gmail.com> wrote:
> Oop, I didn't know that I replied to Nicolas instead of to the list because I
> hitted "reply" instead of "reply all". So I'm reposting my previous post to the
> list. Here we go:
>
> In my previous post I actually meant to say that I set `debug-on-quit', have no
> idea why I did `debug-on-error'. But anyways, I'm now pretty sure it was commit
> "5ea0228" that causes problem because the moment I deleted the last two lines in
> (define-derived-mode org-mode outline-mode "Org") everything worked fine.
> Demonstrated below:
>
> (define-derived-mode org-mode outline-mode "Org"
> ...
> ;; Delete these two lines and everything worked.
> (report-errors "File local-variables error: %s"
> (hack-local-variables))
> )
>
> Also, I figured out that it was my major mode that derived from `org-mode'
> didn't work, and the buffer showed in org-mode, instead of my derived mode. But
> my mode is as simple as:
>
> (define-derived-mode yhj-mode org-mode "yhj"
> )
>
> With some special key bindings specific to my file that is opened in `yhj-mode'.
>
> By the way, I had toggled `debug-on-quit', but made no difference when I hit
> C-g.
>
>
> Thanks,
>
> York
>
> On Mon, Nov 25, 2013 at 2:26 PM, Thomas S. Dye <tsd@tsdye.com> wrote:
>> Nick Dokos <ndokos@gmail.com> writes:
>>
>>> It may be that hack-local-variables takes a long time to process a large
>>> file, although I don't think so: iirc, it limits itself to a tail of the
>>> file of a given size, or the last "page" of the file (demarcated by ^L),
>>> whichever is smaller.
>>
>> Hi Nick,
>>
>> I haven't noticed any slowdown or hangs since hack-local-variables was
>> introduced.
>>
>> I have noticed that I need to answer the query about loading file local
>> variables twice:
>>
>> Please type y, n, or !, or C-v to scroll: y [2 times]
>>
>> The first y has no apparent effect (except to make the second y
>> effective).
>>
>> hth,
>> Tom
>>
>> --
>> Thomas S. Dye
>> http://www.tsdye.com
>>
York Zhao <gtdplatform@gmail.com> writes:
> First goes .emacs file:
>
> (add-to-list 'load-path "path/to/org-mode")
> (add-to-list 'load-path "path/to/org-mode/lisp") ; this line is the key
> (add-to-list 'load-path "path/to/yhj-mode")
> (require 'yhj-mode)
>
> Second goes yhj-mode.el:
>
> (require 'org)
> (define-derived-mode yhj-mode org-mode "yhj")
> (provide 'yhj-mode)
>
> Finally, file test.yz:
>
> # -*- mode:yhj -*-
>
> Open file "test.yz" and note the comment line not fortified, open "*message*"
> buffer and note the following error:
>
> File local-variables error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
>
> There are three keys to reproduce, first, you have to make two files, .emacs and
> "yhj-mode.el". Second, this line must be present:
>
> (add-to-list 'load-path "path/to/org-mode/lisp") ; this line is the key
>
> Third, file "yhj-mode.el" has to be byte-compiled.
>
Thank you for the reproducer. I get the same result (and I don't need to
byte compile yhj-mode.el - the mention of the necessity of
byte-compilation led me to suspect the compiler, but since it happens
with uncompiled code, that theory went out the window.)
The problem is the following sequence of calls:
find-file -> normal-mode -> set-auto-mode (nil) -> set-auto-mode-0 (nil)
yhj-mode -> org-mode -> hack-local-variables -> hack-local-variables-apply(mode yhj) ->
yhj-mode -> org-mode -> hack-local-variables -> ...
Setting the mode in a local variable section leads to this scenario,
something I did not test for my original "fix".
The best solution I can think of so far: revert commit 5ea0228,
and change org-mode-restart to call normal-mode, instead of org-mode.
normal-mode splits the setting of the mode from the setting of local
variables, so it would avoid the recursion.
I think (but I have not verified yet) that this would fix both the
problem that gave rise to commit 5ea0228 in the first place and this
bottomless recursion, without causing any other problems. I'll try it
out tomorrow if I find the time and submit a patch.
--
Nick
[-- Attachment #1: Type: text/plain, Size: 740 bytes --] Nick Dokos <ndokos@gmail.com> writes: > The best solution I can think of so far: revert commit 5ea0228, > and change org-mode-restart to call normal-mode, instead of org-mode. > normal-mode splits the setting of the mode from the setting of local > variables, so it would avoid the recursion. > > I think (but I have not verified yet) that this would fix both the > problem that gave rise to commit 5ea0228 in the first place and this > bottomless recursion, without causing any other problems. I'll try it > out tomorrow if I find the time and submit a patch. Patch attached. It passed the two tests, but I have not done anything more. Can both interested parties (York Zhao and Tom Dye) please test it and let me know of any problems? [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Patch to set file local variables (second try) --] [-- Type: text/x-diff, Size: 1044 bytes --] diff --git a/lisp/org.el b/lisp/org.el index 7a4d244..677d298 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5512,10 +5512,7 @@ The following commands are available: (unless org-inhibit-startup-visibility-stuff (org-set-startup-visibility)))) ;; Try to set org-hide correctly - (set-face-foreground 'org-hide (org-find-invisible-foreground)) - ;; Make sure that file local variables are set. - (report-errors "File local-variables error: %s" - (hack-local-variables))) + (set-face-foreground 'org-hide (org-find-invisible-foreground))) ;; Update `customize-package-emacs-version-alist' (add-to-list 'customize-package-emacs-version-alist @@ -20469,7 +20466,8 @@ This command does many different things, depending on context: "Restart Org-mode, to scan again for special lines. Also updates the keyword regular expressions." (interactive) - (org-mode) + ;; this will set the mode *and* set file local variables. + (normal-mode) (message "Org-mode restarted")) (defun org-kill-note-or-show-branches () [-- Attachment #3: Type: text/plain, Size: 18 bytes --] Thanks, -- Nick
York Zhao writes: > (add-to-list 'load-path "path/to/org-mode") This line is not needed. > (add-to-list 'load-path "path/to/org-mode/lisp") ; this line is the > key Key for what? Did you create autoload files for this installation? > Third, file "yhj-mode.el" has to be byte-compiled. You'll have to byte-compile it while the load-path is already set to include your Org installation, otherwise it will pick up the Org shipped with Emacs. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
> York Zhao writes: >> (add-to-list 'load-path "path/to/org-mode") > > This line is not needed. My org-mode is "installed" in separate directory outside of Emacs system and therefor this line is needed in my setup, otherwise the org-mode shipped with Emacs would be used. >> (add-to-list 'load-path "path/to/org-mode/lisp") ; this line is the >> key > > Key for what? Did you create autoload files for this installation? Key for reproducing the problem. I wouldn't get the problem without this line. >> Third, file "yhj-mode.el" has to be byte-compiled. > > You'll have to byte-compile it while the load-path is already set to > include your Org installation, otherwise it will pick up the Org shipped > with Emacs. "yhj-mode.el" is the file used to reproduce the problem, in my system I have to byte-compile this file, otherwise I wouldn't get the problem. But apparently Nicolas doesn't need to byte-compile this file and still reproduced the issue. Have no idea why. York
> Can both interested parties (York Zhao and Tom Dye) please test it and let me
> know of any problems?
Thank you for the fix, your patch worked for me.
York
Nick Dokos <ndokos@gmail.com> writes: > Nick Dokos <ndokos@gmail.com> writes: > >> The best solution I can think of so far: revert commit 5ea0228, >> and change org-mode-restart to call normal-mode, instead of org-mode. >> normal-mode splits the setting of the mode from the setting of local >> variables, so it would avoid the recursion. >> >> I think (but I have not verified yet) that this would fix both the >> problem that gave rise to commit 5ea0228 in the first place and this >> bottomless recursion, without causing any other problems. I'll try it >> out tomorrow if I find the time and submit a patch. > > Patch attached. It passed the two tests, but I have not done anything > more. Can both interested parties (York Zhao and Tom Dye) please test it > and let me know of any problems? Hi Nick, The patch appears to work for me. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
York Zhao writes: >> York Zhao writes: >>> (add-to-list 'load-path "path/to/org-mode") >> >> This line is not needed. > > My org-mode is "installed" in separate directory outside of Emacs system and > therefor this line is needed in my setup, otherwise the org-mode shipped with > Emacs would be used. The only path that needs to be in load-path is the lisp directory for org-mode, which is the second line (that you say is "key"). Unless you have created your completely original way of "installing" Org, then only the second line is needed. If you do have created your own completely original way of "installing" Org, then please don't expect anybody else to be able to help. >>> (add-to-list 'load-path "path/to/org-mode/lisp") ; this line is the >>> key >> >> Key for what? Did you create autoload files for this installation? > > Key for reproducing the problem. I wouldn't get the problem without this line. Yes, because you wouldn't load any of the new code. Except the "installation" doesn't really look like we can only assume it does. > "yhj-mode.el" is the file used to reproduce the problem, in my system I have to > byte-compile this file, otherwise I wouldn't get the problem. But apparently > Nicolas doesn't need to byte-compile this file and still reproduced the issue. > Have no idea why. Maybe because your "installation" is borked, but we can't know because you never provided enough information to tell. There's a reason for org-submit-bug-report to exist; among other things it includes information about the Emacs and Org version and clueas as to how the installation is set up. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
I pushed the fix to master. Thanks to York and Tom for all the help. I ran ``make test before pushing''. There were two failures, I believe unrelated to this patch: ,---- | Ran 481 tests, 479 results as expected, 2 unexpected (2013-11-27 09:20:58-0500) | 4 expected failures | | 2 unexpected results: | FAILED test-ob/catches-all-references | FAILED test-org-element/link-parser `---- -- Nick
Nick Dokos writes: > I pushed the fix to master. Thanks to York and Tom for all the help. I'm not sure this fix is complete. It seems that when someone would manually enter org-mode (say, in a scratch buffer) Emacs could return to an entirely different mode upon executing org-reset. > | 2 unexpected results: > | FAILED test-ob/catches-all-references This one is the bug I reported earlier today. > | FAILED test-org-element/link-parser This on the other hand bisects to your commit. Plus, the above explanation is the reason for the test fail. I've pushed a fix (f2483ec) that hopefully has no other side-effects not covered by tests. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Achim Gratz <Stromeko@nexgo.de> writes:
> Nick Dokos writes:
>> I pushed the fix to master. Thanks to York and Tom for all the help.
>
> I'm not sure this fix is complete. It seems that when someone would
> manually enter org-mode (say, in a scratch buffer) Emacs could return to
> an entirely different mode upon executing org-reset.
>
>> | 2 unexpected results:
>> | FAILED test-ob/catches-all-references
>
> This one is the bug I reported earlier today.
>
>> | FAILED test-org-element/link-parser
>
> This on the other hand bisects to your commit. Plus, the above
> explanation is the reason for the test fail. I've pushed a fix
> (f2483ec) that hopefully has no other side-effects not covered by tests.
>
OK, thanks for that. I was rushing this morning and did a pattern match
on the test name and decided it couldn't be me: famous last words. And
to add insult to injury, I didn't check on failures without the patch.
Oy,vey...
However, with your patch there is the opposite side of the coin: if you
have a buffer in a mode derived from org (as in York's case), then doing
C-c C-c on the options line will reset the mode to org, not to the
derived one, right?
Nick
Nick Dokos writes: > However, with your patch there is the opposite side of the coin: if you > have a buffer in a mode derived from org (as in York's case), then doing > C-c C-c on the options line will reset the mode to org, not to the > derived one, right? It would have done exactly that before your patch, so at least that doesn't change anything. If that is indeed a problem, then one would either have to remember the mode-name, then call normal-mode and then re-instate the mode that has been remembered (and hope for the best) or check that the mode we ended up in is derived from org-mode. I think the latter is general enough to cover the use-cases discussed so far, so I've implemented it until someone finds a better solution. But all these troubles seem to indicate that maybe it isn't a very bright idea to simply re-initialize org-mode completely just to get the local setup refreshed. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
> The only path that needs to be in load-path is the lisp directory for > org-mode, which is the second line (that you say is "key"). You are right on this which I didn't realize before you pointed out, thanks. Anyways, in my configuration I always have both lines, and I'm going to delete the first line. And also, when I was trying to reproduce the issue in a minimum setup, I deleted the second line then the problem didn't show up which I now realized was simply because I ended up running the `org-mode' shipped with Emacs 24.3, my bad, sorry for the confusion. > Unless you have created your completely original way of "installing" Org, then > only the second line is needed. As explained above, yes, my `org-mode' is in some other path outside of Emacs, e.g., "foo/org-mode", which I had already explained, I'm going to delete the first line. But it doesn't hurt to have the first line anyways right? > If you do have created your own completely original way of "installing" Org, > then please don't expect anybody else to be able to help. It should have been clear by now that this was a "real" problem totally unrelated to "my own completely original way of installing Org" and had been addressed properly. I'm not sure if you had tried my reproducer. > Yes, because you wouldn't load any of the new code. Already explained on this in previous paragraphs. > Maybe because your "installation" is borked, No, my installation had never broken, and as we've all seen, the problem has nothing to do with my "broken installation". > but we can't know because you never provided enough information to tell. I'm pretty sure I had provided pretty effective reproducer with which Nicolas had successfully reproduced the issue. By the way, it took me two hours to isolate it from my own .emacs (over 400KB). > There's a reason for org-submit-bug-report to exist; among other things it > includes information about the Emacs and Org version and clueas as to how the > installation is set up. I didn't know that, thanks for telling me. York
York Zhao writes: > As explained above, yes, my `org-mode' is in some other path outside of Emacs, > e.g., "foo/org-mode", which I had already explained, I'm going to delete the > first line. But it doesn't hurt to have the first line anyways right? It could have (depending on what other files you might have had there, not from the Git repo). It certainly muddied the waters w.r.t. your bug report. For the rest of your post: no need to get defensive. My point was (and is) that each bug report should clearly state which version of Emacs and Org is used, and where and how these are installed; the most concise way of providing this information is to use org-submit-bug-report. The guesswork to glean this from other information in the thread too often leads to wrong conclusions. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
> It could have (depending on what other files you might have had there, > not from the Git repo). May happen in theory, but never in real life, at least never happen on me. > It certainly muddied the waters w.r.t. your bug report. I had provided a reproducer proved to be straightforward and effective, period. > For the rest of your post: no need to get defensive. I certainly had perceived offensive atmosphere from your post, be friendly please. Thanks, York