emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scheme.el bug & fix


From: Luc Teirlinck
Subject: Re: scheme.el bug & fix
Date: Mon, 17 Feb 2003 18:30:16 -0600 (CST)

Stefan Monnier wrote:

   I grepped through lisp/**/*.el and couldn't find a single case where
   the table needed to be copied.

According to Kim the following would break (and hence would need to be
fixed if we make the change):
autoconf.el: autoconf-current-defun-function

   > (I believe it is meant to very temporarily change the syntax table of
   > the current buffer, not to be used to actually define syntax tables.)

   Indeed, and you don't want this temporary syntax-table-switch to make
   a copy of the table and then drop it on the floor (turning it into
   garbage) unless there's a very good reason for it.

I now agree that it would be (or at the very least would have been)
better not to copy.  However, the change still seems to involve some
risks, and if we change the macro, we will need to be careful and
alert to the potential problems.

   As a matter of fact, syntax-tables are very rarely modified at
   all, other than when they're created.

Yes, but the point is that, in its current form, with-syntax-table
uses a newly created (copied) syntax-table.  It is very customary to
create a new syntax-table by first copying an old one and then making
a few changes.  The current version of with-syntax-table (and its
documentation string) clearly seems to allow (in fact, nearly
encourage) such use.  One could argue that this may have been a
mistake, but it is still the current behavior.

The type of bugs we are talking about can be extremely nasty.  An
obscure, seldom-but-not-never called function modifies, say,
standard-syntax-table.  All of a sudden, one of the user's abbrevs
does not expand.  After carefully double checking his abbrev-tables,
the user decides to file a bug report.  For safety, first try 
emacs -q.  Bug gone.  Check .emacs.  Starting a new emacs makes the
problem disappear.  The user must have hit some "wrong key" or
something.  No bug report.  A week or so later another strange
completely unrelated problem appears.  Same story.  Hit some wrong key
again, no bug report.  These are the kind of bugs where it will be
even hard for the user to file anything close to a useful bug report.

If we make the change, we should realize that some strange
irreproducible bug reports we might get could be due to people using
specialized Elisp programs, not included with the Emacs distribution
(there actually are quite a few of those), that rely on the old
with-syntax-table behavior and hence, with the new behavior, modify,
say, standard-syntax-table.  One will also have to be careful with
packages written by people who themselves use a released version
instead of the latest CVS.  Gerd does not seem to remember the
details, but if the reason would have been compatibility with XEmacs,
one will also have to be careful with packages originally written for
XEmacs.  (I myself am not familiar with XEmacs, so I do not know what
the situation is.)

If one makes the change, it should be emphasized in the News (C-h n).
The new behavior and the danger involved should be clearly mentioned
in the documentation string and the Elisp manual.  If we are going to
make the change, it may actually be best to include it in a released
version sooner rather than later, to minimize the time during which
people get accustomed to and use the old version.  (Fortunately, it is
a relatively new macro.)

Sincerely,

Luc.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]