unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: monnier+gnu/emacs@rum.cs.yale.edu
Subject: Re: scheme.el bug & fix
Date: Mon, 17 Feb 2003 18:30:16 -0600 (CST)	[thread overview]
Message-ID: <200302180030.SAA19726@eel.dms.auburn.edu> (raw)
In-Reply-To: <200302171439.h1HEdH926957@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu)

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	other threads:[~2003-02-18  0:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3E26DA700109A72E@mel-rta8.wanadoo.fr>
2003-02-16 23:53 ` scheme.el bug & fix Stefan Monnier
2003-02-17  1:05   ` Luc Teirlinck
2003-02-17 10:19     ` Kim F. Storm
2003-02-17  9:34       ` Miles Bader
2003-02-17 20:37       ` Richard Stallman
2003-02-17 14:39     ` Stefan Monnier
2003-02-18  0:30       ` Luc Teirlinck [this message]
2003-02-18 15:33         ` Stefan Monnier
2003-02-19  7:17           ` Richard Stallman
2003-02-19 14:31             ` Stefan Monnier
2003-02-19 15:11               ` Miles Bader
2003-02-20 18:21               ` Richard Stallman
2003-02-20 20:14                 ` Stefan Monnier
2003-04-14  1:21                   ` Luc Teirlinck

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=200302180030.SAA19726@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=monnier+gnu/emacs@rum.cs.yale.edu \
    /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).