Re: font-lock-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: Bill Wohler [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) ... I think the bug is in font-lock, not in MH-E. I see that font-lock-default-fontify-buffer calls font-lock-set-defaults. It seems that font-lock-fontify-region is a perfectly good entry point to font-lock so that font-lock-default-fontify-region might as well call font-lock-set-default too. When I added a call to font-lock-set-default to to the top of font-lock-default-fontify-region, the bug went away. Does this sound right? Are the modes responsible for calling this seemingly internal function. It certainly isn't documented. I do see that dig.el, sh-script.el, and vhdl-mode.el call this function, but maybe these were added to work around this bug. I'd appreciate it if someone who was more familiar with this code inserted the call to font-lock-set-default in the correct place (I had just inserted it blindly at the top). Also, it would be a good idea to check the other functions and see if there are other entry points that are missing this call. There is one inconsistent call to font-lock-set-default. font-lock-fontify-block checks for (not font-lock-mode) first before calling font-lock-set-default. The rest just go ahead and call font-lock-set-default. Maybe all these calls to font-lock-set-defaults can be replaced with a single call to font-lock-set-defaults in font-lock-compile-keywords to replace this code: (if (not font-lock-set-defaults) ;; This should never happen. But some external packages sometimes ;; call font-lock in unexpected and incorrect ways. It's important to ;; stop processing at this point, otherwise we may end up changing the ;; global value of font-lock-keywords and break highlighting in many ;; other buffers. (error Font-lock trying to use keywords before setting them up)) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. The manual seems to indicate that setting font-lock-defaults in this fashion is exactly the right way to proceed. It also implies that font-lock-defaults is already buffer local so we should be able to delete the make-local-variable call above, right? I haven't gotten any replies to this message. I've been running the following patch for the past week which has fixed the Gnus fontification bug. May I check it in? Index: font-lock.el === RCS file: /cvsroot/emacs/emacs/lisp/font-lock.el,v retrieving revision 1.290 diff -u -r1.290 font-lock.el --- font-lock.el3 Jan 2006 17:00:35 - 1.290 +++ font-lock.el5 Jan 2006 22:50:10 - @@ -1028,6 +1028,8 @@ a very meaningful entity to highlight.) (defun font-lock-default-fontify-region (beg end loudly) + ;; Make sure we have the right `font-lock-keywords' etc. + (font-lock-set-defaults) (save-buffer-state ((parse-sexp-lookup-properties (or parse-sexp-lookup-properties font-lock-syntactic-keywords)) -- 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-add-keywords in hi-lock.el
I haven't gotten any replies to this message. Sorry I didn't reply, but I did install a patch that does something similar to what you suggest. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] wrote: I haven't gotten any replies to this message. Sorry I didn't reply, but I did install a patch that does something similar to what you suggest. Now I see it. Thanks. I'll take out my patch and run with yours. I was thinking along the same lines too, but was too timid to go up a function call. -- 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-add-keywords in hi-lock.el
Richard M. Stallman [EMAIL PROTECTED] wrote: Is this the usual way of injecting one's keywords? You don't want to start injecting keywords. What if you got addicted to them? I'd probably get to know font-lock a lot more than I do now. -- 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-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] writes: Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). Thanks. I'll have to try that. In the meantime, I can now reproduce the problem! And, it's uh, in MH-E :-(. emacs -Q C-x b foo RET M-: font-lock-keywords RET = nil C-x k RET M-x mh-rmail C-x b foo RET M-: font-lock-keywords RET = (t nil) (but only if you have unseen messages in +inbox) C-x k RET F v +some-folder RET(mh-visit-folder, must have at least one message) C-x b foo RET M-: font-lock-keywords RET = (t nil) Interestingly, I found that if you kill a folder's buffer and then revisit that folder, this problem does not reappear. But choose a folder that you haven't yet visited with at least one message, and it does. Can you guys take a quick peek and see if you see anything obvious? If not, I'll debug this. If you have GNU mailutils or nmh installed, and you can get a message in +some-folder you should be able to perform the above steps. (Hint: the first chapter of the MH-E manual--even the old one that is currently in Emacs--is a tutorial which will help you do this.) I've opened an MH-E bug #1393879 on this: https://sourceforge.net/tracker/index.php?func=detailaid=1393879group_id=13357atid=113357 -- 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-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: Can you guys take a quick peek and see if you see anything obvious? If not, I'll debug this. I didn't see anything obvious, but I'm not intimately familiar with the font-lock stuff. mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? -- 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-add-keywords in hi-lock.el
On closer look, it appears that the error can be triggered both at compile and at run time (because the keywords can be compiled at run time). Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). This error was not triggered when I visited a folder in MH-E. Have you re-dumped Emacs in the mean time. font-lock is now preloaded. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] wrote: Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). This error was not triggered when I visited a folder in MH-E. Have you re-dumped Emacs in the mean time. font-lock is now preloaded. Nope. Thanks for the reminder. Dumping... Running... signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) mh-notate-user-sequences() mh-regenerate-headers((all)) mh-scan-folder(+tmp/laptops all) mh-visit-folder(+tmp/laptops all) call-interactively(mh-visit-folder) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. -- 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-add-keywords in hi-lock.el
signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) So it looks like the problem is that you call font-lock-fontify-region without first setting up font-lock variables (e.g. by calling font-lock-mode or font-lock-set-defaults). OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Yes. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) ... I think the bug is in font-lock, not in MH-E. I see that font-lock-default-fontify-buffer calls font-lock-set-defaults. It seems that font-lock-fontify-region is a perfectly good entry point to font-lock so that font-lock-default-fontify-region might as well call font-lock-set-default too. When I added a call to font-lock-set-default to to the top of font-lock-default-fontify-region, the bug went away. Does this sound right? Are the modes responsible for calling this seemingly internal function. It certainly isn't documented. I do see that dig.el, sh-script.el, and vhdl-mode.el call this function, but maybe these were added to work around this bug. I'd appreciate it if someone who was more familiar with this code inserted the call to font-lock-set-default in the correct place (I had just inserted it blindly at the top). Also, it would be a good idea to check the other functions and see if there are other entry points that are missing this call. There is one inconsistent call to font-lock-set-default. font-lock-fontify-block checks for (not font-lock-mode) first before calling font-lock-set-default. The rest just go ahead and call font-lock-set-default. Maybe all these calls to font-lock-set-defaults can be replaced with a single call to font-lock-set-defaults in font-lock-compile-keywords to replace this code: (if (not font-lock-set-defaults) ;; This should never happen. But some external packages sometimes ;; call font-lock in unexpected and incorrect ways. It's important to ;; stop processing at this point, otherwise we may end up changing the ;; global value of font-lock-keywords and break highlighting in many ;; other buffers. (error Font-lock trying to use keywords before setting them up)) OK, that's better, thanks! I still need to check the other calls on the stack, but mh-visit-folder contains this: (make-local-variable 'font-lock-defaults) (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) Is this the usual way of injecting one's keywords? Will also RTFM. The manual seems to indicate that setting font-lock-defaults in this fashion is exactly the right way to proceed. It also implies that font-lock-defaults is already buffer local so we should be able to delete the make-local-variable call above, right? -- 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-add-keywords in hi-lock.el
Stefan Monnier [EMAIL PROTECTED] writes: signal(error (Font-lock trying to use keywords before setting them up)) error(Font-lock trying to use keywords before setting them up) font-lock-compile-keywords(nil t) font-lock-fontify-keywords-region(1 81 nil) font-lock-default-fontify-region(1 80 nil) font-lock-fontify-region(1 80) mh-add-sequence-notation(1 t) So it looks like the problem is that you call font-lock-fontify-region without first setting up font-lock variables (e.g. by calling font-lock-mode or font-lock-set-defaults). The manual doesn't mention either font-lock-fontify-buffer or font-lock-fontify-region. Is that because the manual is incomplete or because we are using font-lock in an undocumented way? Nonetheless, if font-lock-default-fontify-buffer calls font-lock-set-defaults, it seems that font-lock-default-fontify-region should as well, thereby fixing the problem. -- 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-add-keywords in hi-lock.el
Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? ... Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. I've added a sanity check in font-lock-compile-keywords which should at least catch the offenders before they wreak havoc (hopefully the offenders are not font-lock itself). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
I just went a couple of days without reproducing, but it happened pretty quickly just now (after reading some mail with MH-E--h). It's gonna be hard to fix until we have a reproducible testcase. Local in buffer *Apropos*; global value is (t nil) This global value is the indirect source of your problem. The real source is the one that causes this value. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
font-lock-keywords in the affected Gnus buffers is (t nil). [...] Is that enough information to find the culprit, or is there a watch I can put on the global value of font-lock-keywords which will print a stacktrace or enter the debugger when it is changed? I think this information is enough to find the culprit. The function `font-lock-fontify-keywords-region' is the only remaining function in font-lock.el that compiles font-lock-keywords without calling `(font-lock-set-defaults)' first. Before fixing it, it would be useful to know how it gets called. In the buffer list you sent earlier there is the *Occur* buffer. Do you remember on what buffer you called `occur'? Very likely `occur' forced fontification on a non-font-lock buffer. However, I can't reproduce this bug with `emacs -Q'. Do you have a special font-lock configuration in .emacs, like calling `(font-lock-turn-on-thing-lock)' directly on non-font-lock buffers or something like that? -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Juri Linkov [EMAIL PROTECTED] writes: I just did another update this morning and now the highlighting goes away in Gnus buffers even faster than before (or I just got lucky with what I was doing). I managed to reproduce it twice already this morning. When this happens, I also notice that the highlighting is also broken in *Help* buffers. I think it was last week where I didn't observe this behavior at all. Hard to say if I got lucky, or whether there was a good change a week before that and a bad change this week. But it's what I observed. Sorry, this is so sporadic that I haven't been able to generate a recipe to reproduce it yet. Do you use Hi-Lock (either by putting global-hi-lock-mode in .emacs or by using highlight-regexp or other hi-lock functions)? Not explicitly. Here are my buffers and their modes. I just fired up Gnus with this set and the highlighting was off. Do you know if any of the modes listed below might be triggering the bug? . * *followup to Juri Li: 1305 Message ~/var/news/drafts/drafts/1 %* *Summary gmane.emacs: 1080 Summary %* *Article* 1071 Article %* *Group*614 Group % +inbox1120 MH-Folder ~/var/mail/inbox/ % show-+mhe-index/sequ: 2006 MH-Show ~/var/mail/mhe-index/sequence/unseen/1 % +mhe-index/sequence/u: 99 MH-Folder ~/var/mail/mhe-index/sequence/unseen/ * mh-e.texi 309787 Texinfo /usr/local/src/mh-e/doc/mh-e.texi mh-customize.el 111626 Emacs-Lisp /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-customize.el TODO 15022 Outline /usr/local/src/mh-e/doc/TODO %* *compilation* 5495 Compilation:exit * *scratch* 41 Lisp Interaction mh-e.el 114953 Emacs-Lisp /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-e.el devguide.texi92642 Texinfo /usr/local/src/mh-e/htdocs/doc/devguide.texi % *info* 290114 Info * *Messages*1576 Fundamental % *Completions* 199 Completion List * *desktop* 4791 Fundamental *MH-E Log* 0 Fundamental % *Occur*537 Occur % show-+inbox 1011 MH-Show ~/var/mail/inbox/14 -- 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-add-keywords in hi-lock.el
Do you use Hi-Lock (either by putting global-hi-lock-mode in .emacs or by using highlight-regexp or other hi-lock functions)? Not explicitly. Here are my buffers and their modes. I just fired up Gnus with this set and the highlighting was off. Do you know if any of the modes listed below might be triggering the bug? I see nothing to suspect in the buffer list. Could you look at the value of `font-lock-keywords' in the Gnus buffer where highlighting is off. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
I just did another update this morning and now the highlighting goes away in Gnus buffers even faster than before (or I just got lucky with what I was doing). I managed to reproduce it twice already this morning. When this happens, I also notice that the highlighting is also broken in *Help* buffers. I think it was last week where I didn't observe this behavior at all. Hard to say if I got lucky, or whether there was a good change a week before that and a bad change this week. But it's what I observed. Sorry, this is so sporadic that I haven't been able to generate a recipe to reproduce it yet. Do you use Hi-Lock (either by putting global-hi-lock-mode in .emacs or by using highlight-regexp or other hi-lock functions)? -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. This bug (Gnus losing its highlighting) reared its ugly head again a couple of times in the past two days for me. I believe this is now fixed by Stefan's font-lock patch. With this patch, when hi-lock is turned off on a non-font-lock buffer, highlighting in all other non-font-lock buffers don't get broken. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Romain Francoise [EMAIL PROTECTED] writes: Bill Wohler [EMAIL PROTECTED] writes: Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. This bug (Gnus losing its highlighting) reared its ugly head again a couple of times in the past two days for me. -- 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-add-keywords in hi-lock.el
When discussing what to do in hi-lock, could you please include David M. Koppelman, [EMAIL PROTECTED] Yes, I know. I already CC'd him on two my messages with patches. Somehow he was removed from the CC list on replies. Anyway, due to CC in my first messages, he follows the proposed changes and confirmed off-list that he has no objections. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. -- Romain Francoise [EMAIL PROTECTED] | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Romain Francoise [EMAIL PROTECTED] wrote: Bill Wohler [EMAIL PROTECTED] writes: Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. That explains why I haven't seen the problem in a week ;-). Thanks. -- 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-add-keywords in hi-lock.el
When discussing what to do in hi-lock, could you please include David M. Koppelman, [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
font-lock-add-keywords in hi-lock.el
hi-lock-mode breaks existing highlighting when its regexps cover areas highlighted by standard font-lock keywords (non-syntactic). This is especially undesirable on large highlighted areas like outline headings etc. A good solution for this problem is to append new hi-lock keywords at the end of the current highlighting list instead of adding them at the beginning. Thus hi-lock regexps always will be placed over standard highlighted keywords. A patch below sets the 3rd arg `HOW' (former `APPEND') of `font-lock-add-keywords' to t. (The parameter `OVERRIDE' of the MATCH-HIGHLIGHT form is already t on every hi-lock keyword, so this will work correctly.) Index: lisp/hi-lock.el === RCS file: /sources/emacs/emacs/lisp/hi-lock.el,v retrieving revision 1.35 diff -c -r1.35 hi-lock.el *** lisp/hi-lock.el 10 Dec 2005 11:47:28 - 1.35 --- lisp/hi-lock.el 14 Dec 2005 17:07:29 - *** *** 526,532 Highlight REGEXP with face FACE. (let ((pattern (list regexp (list 0 (list 'quote face) t (unless (member pattern hi-lock-interactive-patterns) ! (font-lock-add-keywords nil (list pattern)) (push pattern hi-lock-interactive-patterns) (let ((buffer-undo-list t) (inhibit-read-only t) --- 543,549 Highlight REGEXP with face FACE. (let ((pattern (list regexp (list 0 (list 'quote face) t (unless (member pattern hi-lock-interactive-patterns) ! (font-lock-add-keywords nil (list pattern) t) (push pattern hi-lock-interactive-patterns) (let ((buffer-undo-list t) (inhibit-read-only t) *** *** 544,550 (when (or hi-lock-file-patterns patterns) (font-lock-remove-keywords nil hi-lock-file-patterns) (setq hi-lock-file-patterns patterns) ! (font-lock-add-keywords nil hi-lock-file-patterns) (font-lock-fontify-buffer))) (defun hi-lock-find-patterns () --- 561,567 (when (or hi-lock-file-patterns patterns) (font-lock-remove-keywords nil hi-lock-file-patterns) (setq hi-lock-file-patterns patterns) ! (font-lock-add-keywords nil hi-lock-file-patterns t) (font-lock-fontify-buffer))) (defun hi-lock-find-patterns () *** *** 573,580 (defun hi-lock-font-lock-hook () Add hi lock patterns to font-lock's. (if font-lock-mode ! (progn (font-lock-add-keywords nil hi-lock-file-patterns) !(font-lock-add-keywords nil hi-lock-interactive-patterns)) (hi-lock-mode -1))) (provide 'hi-lock) --- 590,598 (defun hi-lock-font-lock-hook () Add hi lock patterns to font-lock's. (if font-lock-mode ! (progn ! (font-lock-add-keywords nil hi-lock-file-patterns t) ! (font-lock-add-keywords nil hi-lock-interactive-patterns t)) (hi-lock-mode -1))) (provide 'hi-lock) -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Juri Linkov [EMAIL PROTECTED] writes: hi-lock-mode breaks existing highlighting when its regexps cover areas highlighted by standard font-lock keywords (non-syntactic). This is especially undesirable on large highlighted areas like outline headings etc. ... A patch below... Was this patch expected to fix the broken Gnus highlighting me and others have reported? After running M-x font-lock-fontify-buffer in the *Group* buffer (which I think is a recipe that was posted here), the highlighting goes away. It also goes away in subsequent *Summary* and *Article* buffers! By the way, I haven't noticed the broken highlighting in the last week. Maybe something got fixed. Maybe I've gotten lucky. I don't know. -- 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
