[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
We can probably close this bug. I haven't been able to reproduce it with the org-mode bundled with the pretest version. Sorry for the noise. Regards, -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
We can probably close this bug. I haven't been able to reproduce it with the org-mode bundled with the pretest version. Thanks, done. Sorry for the noise. Better luck next time, Stefan
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Daimrod daim...@gmail.com writes: I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... (Nicolas has been doing some rewrite for filling functions in the master branch, maybe it's worth checking whether this bug affects the master branch too, not just the Emacs-24 version of Org.) -- Bastien
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... (Nicolas has been doing some rewrite for filling functions in the master branch, maybe it's worth checking whether this bug affects the master branch too, not just the Emacs-24 version of Org.) I am using the master branch, I didn't check if it also happens in the Emacs-24 version of Org. Sorry, I should have mentioned that in my initial report. :( -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Daimrod daim...@gmail.com writes: Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... (Nicolas has been doing some rewrite for filling functions in the master branch, maybe it's worth checking whether this bug affects the master branch too, not just the Emacs-24 version of Org.) I am using the master branch, I didn't check if it also happens in the Emacs-24 version of Org. Okay, then it would be good to know if it happens in the Org version included in the Emacs pretest, as this is the one that needs heavy testing right now :) -- Bastien
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Bastien b...@altern.org writes: Daimrod daim...@gmail.com writes: Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... (Nicolas has been doing some rewrite for filling functions in the master branch, maybe it's worth checking whether this bug affects the master branch too, not just the Emacs-24 version of Org.) I am using the master branch, I didn't check if it also happens in the Emacs-24 version of Org. Okay, then it would be good to know if it happens in the Org version included in the Emacs pretest, as this is the one that needs heavy testing right now :) So far I haven't manage to reproduce it with the Org bundled with the Emacs pretest. I'll continue to use it for a while and see what happens. Best, -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
gdb) xbacktrace avl-tree-delete (0x54b0) byte-code (0x55a0) byte-code (0x5760) org-element--cache-process-request (0x5990) byte-code (0x5aa0) org-element--cache-sync (0x5ce0) org-element-at-point (0x5e00) byte-code (0x60d0) org-adaptive-fill-function (0x6300) fill-match-adaptive-prefix (0x6480) fill-context-prefix (0x6620) adaptive-wrap-fill-context-prefix (0x67d0) adaptive-wrap-prefix-function (0x6a18) run-hook-with-args (0x6a10) 0x4d89f80 PVEC_COMPILED funcall (0x6b30) jit-lock-fontify-now (0x6e38) jit-lock-function (0x6fc8) vertical-motion (0xdca8) end-of-visual-line (0xde08) call-interactively (0xdfc0) org-end-of-line (0xe198) call-interactively (0xe350) command-execute (0xe478) I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... As mentioned earlier, the immediate problem is that org-adaptive-fill-function does not terminate (or at least takes too long to terminate). Now, one reason why this might happen here is that adaptive-wrap-prefix-mode calls org-adaptive-fill-function everywhere, so it might be called in places where it usually (i.e. when adaptive-wrap-prefix-mode isn't in use) isn't triggered. Stefan
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Stefan Monnier monn...@iro.umontreal.ca writes: gdb) xbacktrace avl-tree-delete (0x54b0) byte-code (0x55a0) byte-code (0x5760) org-element--cache-process-request (0x5990) byte-code (0x5aa0) org-element--cache-sync (0x5ce0) org-element-at-point (0x5e00) byte-code (0x60d0) org-adaptive-fill-function (0x6300) fill-match-adaptive-prefix (0x6480) fill-context-prefix (0x6620) adaptive-wrap-fill-context-prefix (0x67d0) adaptive-wrap-prefix-function (0x6a18) run-hook-with-args (0x6a10) 0x4d89f80 PVEC_COMPILED funcall (0x6b30) jit-lock-fontify-now (0x6e38) jit-lock-function (0x6fc8) vertical-motion (0xdca8) end-of-visual-line (0xde08) call-interactively (0xdfc0) org-end-of-line (0xe198) call-interactively (0xe350) command-execute (0xe478) I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... As mentioned earlier, the immediate problem is that org-adaptive-fill-function does not terminate (or at least takes too long to terminate). Ok. Now, one reason why this might happen here is that adaptive-wrap-prefix-mode calls org-adaptive-fill-function everywhere, so it might be called in places where it usually (i.e. when adaptive-wrap-prefix-mode isn't in use) isn't triggered. Is there a way to disable the effect of `inhibit-quit' in `jit-lock' so C-g interrupt again in order to get an elisp-backtrace with `debug-on-quit'. Otherwise, what's the best way to debug this? Looking closer at `org-adaptive-fill-function'? -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Is there a way to disable the effect of `inhibit-quit' in `jit-lock' so C-g interrupt again in order to get an elisp-backtrace with `debug-on-quit'. Otherwise, what's the best way to debug this? Looking closer at `org-adaptive-fill-function'? 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 (advice-add 'jit-lock--debug-fontify :around (lambda (fun rest args) (with-local-quit (apply fun args Of course sometimes this doesn't work because jit-lock-debug-mode changes the way things are executed and the bug may not manifest itself any more, but it's worth a try. Another source of info is to M-x trace-function RET org-adaptive-fill-function RET M-x trace-function RET org-element-at-point RET M-x trace-function RET org-element--cache-sync RET M-x trace-function RET org-element--cache-process-request RET Then reproduce the hang, then break the hang somehow (maybe with the jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g C-g, ...), then look at the *trace..* buffer. Stefan
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
So, that's an org-mode bug, I'll try to see if I can reproduce it Right: org-adaptive-fill-function should finish fairly promptly. (though I wonder why it uses `inhibit-quit' in the first place). It's not org-mode which binds inhibit-quit but the C code that runs jit-lock. The C code binds inhibit-quit basically any time we run asynchronous code (i.e. code run from redisplay, timers, process-filters, ...) since the user usually doesn't really know that such is running, so if she hits C-g she doesn't mean for it to interrupt that code, but instead to do something else (e.g. get out of the minibuffer). The flip side is that all code run from jit/font-lock, process filters and timers should be super extra careful to finish promptly and never ever get into an inf-loop. Stefan
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Stefan Monnier monn...@iro.umontreal.ca writes: So, that's an org-mode bug, I'll try to see if I can reproduce it Right: org-adaptive-fill-function should finish fairly promptly. (though I wonder why it uses `inhibit-quit' in the first place). It's not org-mode which binds inhibit-quit but the C code that runs jit-lock. The C code binds inhibit-quit basically any time we run asynchronous code (i.e. code run from redisplay, timers, process-filters, ...) since the user usually doesn't really know that such is running, so if she hits C-g she doesn't mean for it to interrupt that code, but instead to do something else (e.g. get out of the minibuffer). Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is called by `org-capture'. I have found 7 places were `inhibit-quit' was set to T in org-mode. The flip side is that all code run from jit/font-lock, process filters and timers should be super extra careful to finish promptly and never ever get into an inf-loop. I can see why. :) -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Daimrod daim...@gmail.com writes: Stefan Monnier monn...@iro.umontreal.ca writes: So, that's an org-mode bug, I'll try to see if I can reproduce it Right: org-adaptive-fill-function should finish fairly promptly. (though I wonder why it uses `inhibit-quit' in the first place). It's not org-mode which binds inhibit-quit but the C code that runs jit-lock. The C code binds inhibit-quit basically any time we run asynchronous code (i.e. code run from redisplay, timers, process-filters, ...) since the user usually doesn't really know that such is running, so if she hits C-g she doesn't mean for it to interrupt that code, but instead to do something else (e.g. get out of the minibuffer). Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is called by `org-capture'. You were right, it's not a problem with `org-capture', I had a another freeze without using it. Here is the xbacktraces: gdb) xbacktrace avl-tree-delete (0x54b0) byte-code (0x55a0) byte-code (0x5760) org-element--cache-process-request (0x5990) byte-code (0x5aa0) org-element--cache-sync (0x5ce0) org-element-at-point (0x5e00) byte-code (0x60d0) org-adaptive-fill-function (0x6300) fill-match-adaptive-prefix (0x6480) fill-context-prefix (0x6620) adaptive-wrap-fill-context-prefix (0x67d0) adaptive-wrap-prefix-function (0x6a18) run-hook-with-args (0x6a10) 0x4d89f80 PVEC_COMPILED funcall (0x6b30) jit-lock-fontify-now (0x6e38) jit-lock-function (0x6fc8) vertical-motion (0xdca8) end-of-visual-line (0xde08) call-interactively (0xdfc0) org-end-of-line (0xe198) call-interactively (0xe350) command-execute (0xe478) I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... -- Daimrod/Greg
