Re: font-lock is broken
I'd be happy if instead of just clearing out inhibit-quit it would cause the C-g to call the debugger. That sounds like a good idea. Would you like to try it and see how it works for you? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
If two C-g are separated by 2 seconds or more and the first is not processed by the time we see the second, then we can assume that Emacs is non-responsive and that inhibit-quit should probably be ignored. This sounds much like the emergency escape feature. That is disabled on window systems because you can go to another window and kill Emacs, if you want to do that. We could conceivably bring it back in this modified form. But I think it calls for some care. Simply clearing out inhibit-quit is likely to leave something broken. Emacs should display a message warning the user that that is the case. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
The most common such problem by far is when a regexp hits a pathological exponential-matching behavior. I wish we'd fix that one instead. It would be good to fix that, but how? It is a consequence of the algorithm, and even recognizing these cases would seem to be a hard problem. Also, they're only painful because of Emacs's lack of NMI. What is NMI? E.g. when C-g is pressed, record the time, and if a C-g is pressed again 2 seconds later and the first hasn't been processed yet, then ignore the inhibit-quit flag (i.e. set it back to nil). I don't understand the suggestion clearly. What would it do if the second C-g is less than two seconds later? What would it do if the second C-g is more than two seconds later? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Is that incorrect? If so, why did it appear to work ok before? Maybe the criterion for a bad match has to be written differently to accord with the practical rules for code that used to work. I'm tempted to just revert my patch, since it causes constant run-time checks and trips up some pre-existing code, only in the hope of occasionally working around some bugs that would need to be fixed anyway. No, don't do that! Let's see if adapting a little is better. Those bugs are rather painful. I've never bumped into this specific form of an infinite non-interruptible computation. So maybe they're painful but they seem to be much more rare than other similar problems not addressed by the patch. The most common such problem by far is when a regexp hits a pathological exponential-matching behavior. I wish we'd fix that one instead. Also, they're only painful because of Emacs's lack of NMI. I'd rather fix that part instead. E.g. when C-g is pressed, record the time, and if a C-g is pressed again 2 seconds later and the first hasn't been processed yet, then ignore the inhibit-quit flag (i.e. set it back to nil). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
Stefan Monnier [EMAIL PROTECTED] writes: Make a buffer with this content: In-reply-to: foo bar of Fri, 15 Jul 2005 20:31:33 EDT (2 lines only) Then M-x mh-letter-mode M-x font-lock-fontify-buffer You get: font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil This is introduced by my recent change to font-lock.el which checks that we do not get stuck in an empty match. Problem is that it bumps into a minor bug in mh-font-lock-field-data: (defun mh-font-lock-field-data (limit) ... (if (and field (mh-letter-skipped-header-field-p field)) (set-match-data nil) (set-match-data (list data-begin data-end data-begin data-end))) (goto-char (if (equal point data-end) (1+ data-end) data-end)) t))) As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Thanks for pointing this out. That should make it easy for us to fix. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
Bill Wohler [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: Make a buffer with this content: In-reply-to: foo bar of Fri, 15 Jul 2005 20:31:33 EDT (2 lines only) Then M-x mh-letter-mode M-x font-lock-fontify-buffer You get: font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil This is introduced by my recent change to font-lock.el which checks that we do not get stuck in an empty match. Problem is that it bumps into a minor bug in mh-font-lock-field-data: (defun mh-font-lock-field-data (limit) ... (if (and field (mh-letter-skipped-header-field-p field)) (set-match-data nil) (set-match-data (list data-begin data-end data-begin data-end))) (goto-char (if (equal point data-end) (1+ data-end) data-end)) t))) As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Thanks for pointing this out. That should make it easy for us to fix. Thanks to Satyaki Das, this has been fixed in the MH-E repository. It will appear in the Emacs repository in the next week or so when I transition the MH-E project to use the Emacs repository as its master. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Is that incorrect? If so, why did it appear to work ok before? Maybe the criterion for a bad match has to be written differently to accord with the practical rules for code that used to work. I'm tempted to just revert my patch, since it causes constant run-time checks and trips up some pre-existing code, only in the hope of occasionally working around some bugs that would need to be fixed anyway. No, don't do that! Let's see if adapting a little is better. Those bugs are rather painful. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
font-lock is broken
In the current CVS version as of today: GNU Emacs 22.0.50.8 (i686-pc-linux-gnu, X toolkit) of 2005-07-15 Make a buffer with this content: In-reply-to: foo bar of Fri, 15 Jul 2005 20:31:33 EDT (2 lines only) Then M-x mh-letter-mode M-x font-lock-fontify-buffer You get: font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
