commit 5ea0228 has problem opening big org-mode file

commit 5ea0228 has problem opening big org-mode file

[York Zhao]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Nick Dokos]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Nick Dokos]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Thomas S. Dye]

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

Re: commit 5ea0228 has problem opening big org-mode file

[York Zhao]

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
>

Re: commit 5ea0228 has problem opening big org-mode file

[York Zhao]

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
>>

Re: commit 5ea0228 has problem opening big org-mode file

[Nick Dokos]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Nick Dokos]

[-- 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

Re: commit 5ea0228 has problem opening big org-mode file

[York Zhao]

> 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

Re: commit 5ea0228 has problem opening big org-mode file

[Thomas S. Dye]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Nick Dokos]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Achim Gratz]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Nick Dokos]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Achim Gratz]

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

Re: commit 5ea0228 has problem opening big org-mode file

[Achim Gratz]

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

Re: commit 5ea0228 has problem opening big org-mode file

[York Zhao]

> 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

Re: commit 5ea0228 has problem opening big org-mode file

[Achim Gratz]

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

Re: commit 5ea0228 has problem opening big org-mode file

[York Zhao]

> 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

Re: commit 5ea0228 has problem opening big org-mode file

[Achim Gratz]

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

Re: commit 5ea0228 has problem opening big org-mode file

[York Zhao]

> 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