From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: scheme.el bug & fix Date: Mon, 17 Feb 2003 18:30:16 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200302180030.SAA19726@eel.dms.auburn.edu> References: <3E26DA700109A72E@mel-rta8.wanadoo.fr> (added by postmaster@wanadoo.fr) <200302162353.h1GNrkG24335@rum.cs.yale.edu> <200302170105.TAA17107@eel.dms.auburn.edu> <200302171439.h1HEdH926957@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1045528285 26455 80.91.224.249 (18 Feb 2003 00:31:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 18 Feb 2003 00:31:25 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18kvfQ-0006sY-00 for ; Tue, 18 Feb 2003 01:31:24 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18kvu3-0007dH-00 for ; Tue, 18 Feb 2003 01:46:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18kvgR-00034n-01 for emacs-devel@quimby.gnus.org; Mon, 17 Feb 2003 19:32:27 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18kvg1-0002zc-00 for emacs-devel@gnu.org; Mon, 17 Feb 2003 19:32:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18kvfA-0002ba-00 for emacs-devel@gnu.org; Mon, 17 Feb 2003 19:31:09 -0500 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18kvdY-0002FL-00 for emacs-devel@gnu.org; Mon, 17 Feb 2003 19:29:28 -0500 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id SAA14264; Mon, 17 Feb 2003 18:29:25 -0600 (CST) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id SAA19726; Mon, 17 Feb 2003 18:30:16 -0600 (CST) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-reply-to: <200302171439.h1HEdH926957@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) Original-cc: David.Ponce@wanadoo.fr Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11727 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11727 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.