From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Cc: monnier+gnu/emacs@rum.cs.yale.edu
Subject: Re: scheme.el bug & fix
Date: Mon, 17 Feb 2003 09:39:17 -0500 [thread overview]
Message-ID: <200302171439.h1HEdH926957@rum.cs.yale.edu> (raw)
In-Reply-To: 200302170105.TAA17107@eel.dms.auburn.edu
> It turns out the problem is that
>
> (with-syntax-table st (modify-syntex-entry foo bar))
>
> does not modify `st' because `with-syntax-table' does not use `st'
> but a copy of it. Actually it's even documented in the docstring.
> This sounds silly. Does anybody have an idea why it is defined that way ?
> If not, any objection the patch below which should also improve
> (very marginally) the performance of Emacs ?
>
> Are you sure that you are not going to break plenty of existing code
> this way?
I grepped through lisp/**/*.el and couldn't find a single case where
the table needed to be copied.
> People could very legitimately have relied on the present
> behavior, which is, as you state yourself, very explicitly mentioned
> in the doc string. The reason for the "silly" behavior seems obvious:
> to avoid accidental modification of st.
But it is extremely rare to use modify-syntax-entry with no
third argument and within a with-syntax-table thing, so the
risk of accidental modification is basically inexistent.
As a matter of fact, syntax-tables are very rarely modified at
all, other than when they're created.
> Is there any reason why scheme.el can not possibly define its syntax
> table in a more standard and more natural way?
Of course, it can. That's a separate question. Please someone install
the patch as soon as you can: it's obviously the right thing to do.
> (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.
For example with-category-table does not copy the table.
Stefan
next prev parent reply other threads:[~2003-02-17 14:39 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 [this message]
2003-02-18 0:30 ` Luc Teirlinck
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200302171439.h1HEdH926957@rum.cs.yale.edu \
--to=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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.