home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / lucidem / help / 920 < prev    next >
Encoding:
Text File  |  1993-01-21  |  1.4 KB  |  49 lines
  1. x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 21 Jan 1993 13:26:05 EST
  2. Return-Path: <digi.lonestar.org!mbattagl>
  3. Date: Thu, 21 Jan 1993 12:10:09 CST
  4. From: mbattagl@digi.lonestar.org (Mike Battagl)
  5. Message-ID: <9301211810.AA04529@enterprise-gw>
  6. Subject: hilit bug.....
  7. Newsgroups: alt.lucid-emacs.help
  8. Path: sparky!uunet!wendy-fate.uu.net!help-lucid-emacs
  9. Sender: help-lucid-emacs-request@lucid.com
  10. Lines: 37
  11.  
  12.  
  13. The regexp for c++ comments in lhilit can freeze emacs.  Well ^g will get you out...
  14.  
  15. if you have a comment like this:
  16.  
  17. //********* this is a comment *******
  18.  
  19. When you do a ^C^H emacs is frozen until a ^g
  20.  
  21.  
  22. I corrected my c++-mode-hilit 'c-style-comment' to: 
  23.  
  24. ("[^/]/\\*" "\\*/" hilit0)
  25.  
  26. and that corrects the problem.
  27.  
  28.  
  29.  
  30. It would also seem that no matter what regexp you use, hilit should not freeze.
  31. When the end of the buffer is reached and the 'end' regexp is not reached then it should
  32. give up.  I don't know if you highlight the region or not (if you do it may be easier to
  33. find the problem) but, you should not freeze.  I have found other regexp that does the 
  34. same thing. I one case I have no idea where the problem is. 
  35.  
  36. One other point deals with comments.  It seems that there should be a special
  37. entry for comments (based on comment-start and comment-end), then all other highlighting
  38. should NOT take place in comments.
  39.  
  40.  
  41.  
  42. Thanks,
  43.  
  44. Mike Battaglia
  45. Dsc Communications Corp.
  46. (214) 519-3253
  47. mbattagl@dsccc.com
  48.  
  49.