* How can I debug a problem triggered from jit-lock's background fontification? @ 2011-02-06 20:54 Alan Mackenzie 2011-02-07 15:40 ` Stefan Monnier 0 siblings, 1 reply; 7+ messages in thread From: Alan Mackenzie @ 2011-02-06 20:54 UTC (permalink / raw) To: emacs-devel Hi, Emacs! I have a bug in CC Mode which is triggered by jit-lock inside its background fontifying. The problem doesn't occur when jit-lock is disabled. I have instrumented the CC Mode function for Edebug, yet something seems to be inhibiting the invocation of Edebug from inside jit. No doubt there's a good reason for this, but it has been getting on my nerves for years. Would somebody please suggest a way I can debug the actions of jit-locking from Edebug, or possibly some other way of making progress. Many thanks in advance! -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: How can I debug a problem triggered from jit-lock's background fontification? 2011-02-06 20:54 How can I debug a problem triggered from jit-lock's background fontification? Alan Mackenzie @ 2011-02-07 15:40 ` Stefan Monnier 2011-02-07 22:19 ` Alan Mackenzie 2011-03-08 7:58 ` Daniel Colascione 0 siblings, 2 replies; 7+ messages in thread From: Stefan Monnier @ 2011-02-07 15:40 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel > I have instrumented the CC Mode function for Edebug, yet something seems > to be inhibiting the invocation of Edebug from inside jit. No doubt > there's a good reason for this, but it has been getting on my nerves for > years. Yes, the problem is that jit-lock is called when redisplay is needed so it's tricky to let Edebug work at this time (it's easy to make it work with redisplay inhibited, but then you'll need to use it blindly ;-). > Would somebody please suggest a way I can debug the actions of > jit-locking from Edebug, or possibly some other way of making progress. I've had to deal with this problem, as you can imagine, and I feel your pain. The way I generally handle this problem is as follows: - first, try to turn off jit-lock and to reproduce the problem. This is often all it takes, but admittedly, it doesn't always cut it. - if that fails, then turn jit-lock back on, do M-x trace-function-background RET font-lock-fontify-region RET, and then try and reproduce the problem (try and be careful to make sure font-lock is only invoked in that one buffer during this time). - if the trace itself doesn't give you enough of a hint (that's usually the case, but sometimes, just seeing where jit-lock placed the boundaries of its chunks is enough to see the problem), then turn off jit-lock again, and call font-lock-fontify-region by hand with the args recorded in the trace. You can then use Edebug to your heart's content during this replay. I haven't had to do that often enough and with enough calls to font-lock-fontify-region to get me to automate this replay, but if you end up writing some code to automate it, I'd be happy to add it to jit-lock. - if the above replay does not reproduce the problem, then you may want to try meditation. Stefan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: How can I debug a problem triggered from jit-lock's background fontification? 2011-02-07 15:40 ` Stefan Monnier @ 2011-02-07 22:19 ` Alan Mackenzie 2011-02-07 22:22 ` Lennart Borgman 2011-03-08 7:58 ` Daniel Colascione 1 sibling, 1 reply; 7+ messages in thread From: Alan Mackenzie @ 2011-02-07 22:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Hi Stefan, thanks for this most helpful reply! Guess what? I didn't know about `trace-function-background' until today. One never stops learning about Emacs. I've actually inserted a call to `ignore' into the critical place, with all the things I want to see as parameters to ignore. Then I trace `ignore'. I _think_ I've got the problem tied down, but that will have to wait till tomorrow. Thanks once again. On Mon, Feb 07, 2011 at 10:40:48AM -0500, Stefan Monnier wrote: > I've had to deal with this problem, as you can imagine, and I feel > your pain. The way I generally handle this problem is as follows: > - first, try to turn off jit-lock and to reproduce the problem. This is > often all it takes, but admittedly, it doesn't always cut it. > - if that fails, then turn jit-lock back on, do M-x trace-function-background > RET font-lock-fontify-region RET, and then try and reproduce the > problem (try and be careful to make sure font-lock is only invoked in > that one buffer during this time). > - if the trace itself doesn't give you enough of a hint (that's usually > the case, but sometimes, just seeing where jit-lock placed the > boundaries of its chunks is enough to see the problem), then turn off > jit-lock again, and call font-lock-fontify-region by hand with the > args recorded in the trace. You can then use Edebug to your heart's > content during this replay. > I haven't had to do that often enough and with enough calls to > font-lock-fontify-region to get me to automate this replay, but if you > end up writing some code to automate it, I'd be happy to add it to > jit-lock. > - if the above replay does not reproduce the problem, then you may want > to try meditation. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: How can I debug a problem triggered from jit-lock's background fontification? 2011-02-07 22:19 ` Alan Mackenzie @ 2011-02-07 22:22 ` Lennart Borgman 2011-03-08 8:02 ` Daniel Colascione 0 siblings, 1 reply; 7+ messages in thread From: Lennart Borgman @ 2011-02-07 22:22 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Stefan Monnier, emacs-devel On Mon, Feb 7, 2011 at 11:19 PM, Alan Mackenzie <acm@muc.de> wrote: > > I've actually inserted a call to `ignore' into the critical place, with > all the things I want to see as parameters to ignore. Then I trace > `ignore'. I _think_ I've got the problem tied down, but that will have > to wait till tomorrow. Thanks for that trick, I never thought about using ignore like that. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: How can I debug a problem triggered from jit-lock's background fontification? 2011-02-07 22:22 ` Lennart Borgman @ 2011-03-08 8:02 ` Daniel Colascione 0 siblings, 0 replies; 7+ messages in thread From: Daniel Colascione @ 2011-03-08 8:02 UTC (permalink / raw) To: Lennart Borgman; +Cc: Alan Mackenzie, Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 955 bytes --] On 2/7/11 2:22 PM, Lennart Borgman wrote: > On Mon, Feb 7, 2011 at 11:19 PM, Alan Mackenzie <acm@muc.de> wrote: >> >> I've actually inserted a call to `ignore' into the critical place, with >> all the things I want to see as parameters to ignore. Then I trace >> `ignore'. I _think_ I've got the problem tied down, but that will have >> to wait till tomorrow. > > Thanks for that trick, I never thought about using ignore like that. > That is a neat trick. One thing I like to do is use something like this as my "debug probe": (progn (message "foo: %s" foo) (redisplay t) (sit-for 1) t ; or nil, as appropriate ) This way, I can visualize the progress a function is making as it travels up and the down the buffer and detect patterns more easily than I can by looking at numeric output. If I have debug-on-quit turned on, I can stop the process when I notice something amiss and figure out what went wrong. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: How can I debug a problem triggered from jit-lock's background fontification? 2011-02-07 15:40 ` Stefan Monnier 2011-02-07 22:19 ` Alan Mackenzie @ 2011-03-08 7:58 ` Daniel Colascione 2011-03-08 21:07 ` Stefan Monnier 1 sibling, 1 reply; 7+ messages in thread From: Daniel Colascione @ 2011-03-08 7:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1663 bytes --] On 2/7/11 7:40 AM, Stefan Monnier wrote: >> I have instrumented the CC Mode function for Edebug, yet something seems >> to be inhibiting the invocation of Edebug from inside jit. No doubt >> there's a good reason for this, but it has been getting on my nerves for >> years. I've run into this problem as well. I actually use lazy-lock for C and C++ (because the deferred fontification seems to work better), and the failure mode there even stranger: when breaking into edebug, emacs will split the current window as many times as it can until something dies from stack exhaustion. I can usually recover from this situation by switching to another buffer, killing the original, and killing the excess windows, but it's quite annoying. > Yes, the problem is that jit-lock is called when redisplay is needed so > it's tricky to let Edebug work at this time (it's easy to make it work > with redisplay inhibited, but then you'll need to use it blindly ;-). What about redisplay to a tty frame? >> Would somebody please suggest a way I can debug the actions of >> jit-locking from Edebug, or possibly some other way of making progress. > > I've had to deal with this problem, as you can imagine, and I feel > your pain. The way I generally handle this problem is as follows: Speaking of which, quitting Emacs in the middle of a hard lisp loop during redisplay on X11 (GTK and no-toolkit), nor OS X (AppKit) doesn't seem to have any effect. I've discovered that running under gdb, breaking into Emacs with C-z, and setting debug_on_next_call to 1 works, but it's cumbersome. Is quitting during redisplay *supposed* to work? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: How can I debug a problem triggered from jit-lock's background fontification? 2011-03-08 7:58 ` Daniel Colascione @ 2011-03-08 21:07 ` Stefan Monnier 0 siblings, 0 replies; 7+ messages in thread From: Stefan Monnier @ 2011-03-08 21:07 UTC (permalink / raw) To: Daniel Colascione; +Cc: Alan Mackenzie, emacs-devel > I've run into this problem as well. I actually use lazy-lock for C and > C++ (because the deferred fontification seems to work better), and the Note that lazy-lock is slated for removal (probably before Emacs-25.1). >> Yes, the problem is that jit-lock is called when redisplay is needed so >> it's tricky to let Edebug work at this time (it's easy to make it work >> with redisplay inhibited, but then you'll need to use it blindly ;-). > What about redisplay to a tty frame? Same difference, since they also support faces. > Speaking of which, quitting Emacs in the middle of a hard lisp loop > during redisplay on X11 (GTK and no-toolkit), nor OS X (AppKit) doesn't > seem to have any effect. I've discovered that running under gdb, > breaking into Emacs with C-z, and setting debug_on_next_call to 1 works, > but it's cumbersome. Is quitting during redisplay *supposed* to work? The Elisp code that is not run in direct response to a user event (pre/post-command-hook, redisplay, process filters, timers, ...) is run with inhibit-quit set to t, since the user may hit C-g without knowing that this code is running, i.e. without intending to interrupt this code. There's a pending suggestion to let a C-g C-g C-g override this, but I haven't looked at the patch yet :-( Stefan ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-03-08 21:07 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-02-06 20:54 How can I debug a problem triggered from jit-lock's background fontification? Alan Mackenzie 2011-02-07 15:40 ` Stefan Monnier 2011-02-07 22:19 ` Alan Mackenzie 2011-02-07 22:22 ` Lennart Borgman 2011-03-08 8:02 ` Daniel Colascione 2011-03-08 7:58 ` Daniel Colascione 2011-03-08 21:07 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.