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

2013-11-28 Thread 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



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

2013-11-27 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-27 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-27 Thread Nick Dokos
Achim Gratz strom...@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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-27 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-27 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-27 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-26 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-26 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-26 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-26 Thread Thomas S. Dye
Nick Dokos ndo...@gmail.com writes:

 Nick Dokos ndo...@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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-26 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-25 Thread Nick Dokos
Nick Dokos ndo...@gmail.com writes:

 York Zhao gtdplatf...@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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-25 Thread Thomas S. Dye
Nick Dokos ndo...@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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-25 Thread 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 t...@tsdye.com wrote:
 Nick Dokos ndo...@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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-25 Thread 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 gtdplatf...@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 t...@tsdye.com wrote:
 Nick Dokos ndo...@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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-25 Thread Nick Dokos
York Zhao gtdplatf...@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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-25 Thread Nick Dokos
Nick Dokos ndo...@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?

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

Thanks,
-- 
Nick


[O] commit 5ea0228 has problem opening big org-mode file

2013-11-24 Thread 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: [O] commit 5ea0228 has problem opening big org-mode file

2013-11-24 Thread Nick Dokos
York Zhao gtdplatf...@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