unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "T. V. Raman" <raman@users.sf.net>
Cc: raman@users.sf.net, emacs-devel@gnu.org, storm@cua.dk
Subject: Re: font-lock and shell scripts: Raises redisplay errors in highlight pattern:
Date: Wed, 12 Jul 2006 21:08:19 -0700	[thread overview]
Message-ID: <17589.50995.201436.401539@localhost.localdomain> (raw)
In-Reply-To: <jwvy7v5tsgl.fsf-monnier+emacs@gnu.org>


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 <monnier@iro.umontreal.ca> 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

  reply	other threads:[~2006-07-13  4:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-06  3:38 font-lock and shell scripts: Raises redisplay errors in highlight pattern: T. V. Raman
2006-07-06  8:29 ` Romain Francoise
2006-07-06 10:01 ` Kim F. Storm
2006-07-07  4:01   ` T. V. Raman
2006-07-07 14:18     ` Stefan Monnier
2006-07-13  4:08       ` T. V. Raman [this message]
2006-07-13 15:30         ` Stefan Monnier
2006-07-14  1:28           ` T. V. Raman
2006-07-14  4:06         ` Richard Stallman
2006-07-14 13:00           ` T. V. Raman
2006-07-14 13:04             ` David Kastrup
2006-07-14 13:09             ` Chong Yidong
2006-07-15  1:43               ` T. V. Raman
2006-07-15 13:37             ` Richard Stallman
2006-07-15 14:27               ` T. V. Raman
2006-07-16  6:25                 ` Richard Stallman
2006-07-16 17:18                   ` T. V. Raman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17589.50995.201436.401539@localhost.localdomain \
    --to=raman@users.sf.net \
    --cc=emacs-devel@gnu.org \
    --cc=storm@cua.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).