From: Richard Stallman <rms@gnu.org>
Cc: raman@users.sf.net, monnier@iro.umontreal.ca, storm@cua.dk,
emacs-devel@gnu.org
Subject: Re: font-lock and shell scripts: Raises redisplay errors in highlight pattern:
Date: Fri, 14 Jul 2006 00:06:19 -0400 [thread overview]
Message-ID: <E1G1EwV-0005uq-MV@fencepost.gnu.org> (raw)
In-Reply-To: <17589.50995.201436.401539@localhost.localdomain> (raman@users.sf.net)
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).
If there is no good reason for this to signal an error, it would be
cleaner to eliminate it. But first one has to track down what causes
the error. One way to do that is using GDB with a breakpoint at
Fsignal. Setting debug-on-signal might enable you to find the cause
using the Lisp debugger.
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.
Unhandled errors do make a beep, which is auditory feedback. So what
is the change that you propose?
next prev parent reply other threads:[~2006-07-14 4:06 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
2006-07-13 15:30 ` Stefan Monnier
2006-07-14 1:28 ` T. V. Raman
2006-07-14 4:06 ` Richard Stallman [this message]
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=E1G1EwV-0005uq-MV@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=raman@users.sf.net \
--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).