From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "T. V. Raman" Newsgroups: gmane.emacs.devel Subject: Re: font-lock and shell scripts: Raises redisplay errors in highlight pattern: Date: Wed, 12 Jul 2006 21:08:19 -0700 Message-ID: <17589.50995.201436.401539@localhost.localdomain> References: <17580.34248.381774.421717@localhost.localdomain> <17581.56473.552614.576371@localhost.localdomain> Reply-To: raman@users.sf.net NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1152763734 22729 80.91.229.2 (13 Jul 2006 04:08:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 13 Jul 2006 04:08:54 +0000 (UTC) Cc: raman@users.sf.net, emacs-devel@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 13 06:08:49 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G0sVE-0001Hx-K7 for ged-emacs-devel@m.gmane.org; Thu, 13 Jul 2006 06:08:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0sVD-0000PB-VJ for ged-emacs-devel@m.gmane.org; Thu, 13 Jul 2006 00:08:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0sV0-0000Ll-UT for emacs-devel@gnu.org; Thu, 13 Jul 2006 00:08:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0sUw-0000Kn-Ah for emacs-devel@gnu.org; Thu, 13 Jul 2006 00:08:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0sUw-0000Kk-62 for emacs-devel@gnu.org; Thu, 13 Jul 2006 00:08:22 -0400 Original-Received: from [204.127.192.81] (helo=rwcrmhc11.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G0sWc-0004Zz-G5 for emacs-devel@gnu.org; Thu, 13 Jul 2006 00:10:06 -0400 Original-Received: from labrador (c-67-180-167-124.hsd1.ca.comcast.net[67.180.167.124]) by comcast.net (rwcrmhc11) with ESMTP id <20060713040820m11008qelte>; Thu, 13 Jul 2006 04:08:20 +0000 Original-Received: by labrador (Postfix, from userid 500) id 7F042161C170; Wed, 12 Jul 2006 21:08:19 -0700 (PDT) Original-To: monnier@iro.umontreal.ca In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.64 x-attribution: tvr X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:56965 Archived-At: Here are some more details on this problem. The error is definitely being raised -- but also caught by the condition-case handler in functions font-lock-default-fontify-buffer and font-lock-default-fontify-region. The condition-case in those functions means that toggle-debug-on-error does not give a backtrace alas. But I am able to reliably trigger it as follows: Open an empty file and put it in sh-mode. Type: #!/bin/bash export a=1 You see the error immediately after you hit the ' ' after the keyword "export". The error being raised (from searching the font-lock.el sources, it's one of the font-lock-apply-* functions) Error during redisplay: (error No match 6 in highlight (6 font-lock-builtin-face)) So two questions: 1) Might be marginally benefitial even for the mainstream emacs user to not have these errors raised and handled -- --- what variables in my sh-mode/font-lock environment should I look at to chase down and fix the cause of the error in the first place? (Note that I'm running with font-lock turned on at the highest level). 2) And I'll possibly file this as a separate bug report once Stephane elaborates on what he said toward the end of his note: How can I tell programmatically at run time if an error that is raised has a handler somewhere above in the call stack waiting to handle it? If I had (2), then my advice on error could be smart in the following way: When (error ...) is called: Before-Advice: A) Check if there is a handler waiting to catch the error. B) If yes, do nothing; C) Else give the user auditory feedback. I could achieve an equivalent effect if I knew how to check the following in elisp: Check if an error has "bubbled" all the way up the call stack. Note that I have to advice error in Emacspeak because too many useful Emacs packages use (error ...) to signal useful information ---as an example, VM (the mail reader I use) uses error to signal end of folder. would be nice if >>>>> "Stefan" == Stefan Monnier writes: >> One possibility is that I'm noticing these errors when >> others dont because I advice 'error in emacspeak to get >> auditory alerts for errors. Since 'error does not return, >> this has to be a before advice. A side-consequence of >> this is that errors that are later by an error-handler >> further up the call stack end up still getting signaled >> auditorally. Stefan> Stefan> Please post a feature request with M-x Stefan> report-emacs-bug: it should be possible to customize Stefan> the top-level handling of errors (currently hardcoded Stefan> in cmd_error_internal). Stefan> Stefan> Stefan> Stefan Thanks, --Raman -- Best Regards, --raman Email: raman@users.sf.net WWW: http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk: tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman IRC: irc://irc.freenode.net/#emacs