Re: Syntax table issues
-- Vin Shelton <acs(a)xemacs.org> spake thusly:
1. Start up xemacs -vanilla
2. Add the following text (comment included) into the *scratch*
buffer:
;; This buffer is for notes you don't want to save, and for Lisp
evaluation. ;; If you want to create a file, first visit that file
with C-x C-f, ;; then enter the text in that file's own buffer. (C-x
is the standard ;; XEmacs abbreviation for `Control+x', i.e. hold
down the Control key ;; while hitting the x key.)
;;
;; For Lisp evaluation, type an expression, move to the end and hit
C-j.
(when (or (featurep 'xemacs) window-system)
(require 'mic-paren)
(setq paren-sexp-mode t)
(set (if (boundp 'paren-face) 'paren-face 'paren-match-face) 'bold)
(and (fboundp 'paren-activate) (paren-activate)))
3. Evaluate the buffer.
4. Put the cursor after the closing paren in 'the x key.)' You will
notice that, even though the parens are balanced and in a comment,
the closing paren turns yellow, indicating a matching open paren
can not be found.
A simpler test is:
1. xemacs -vanilla
2. Insert into *scratch*:
;; (
;; )
3. Move point to just after ")".
4. Do: "M-:(scan-sexps (point) -1)"
--> Error "Unbalanced parentheses"
I just tested this with emacs 20.7 and xemacs 21.1 and got the same
behavior. The problem is that scan_lists (which scan-sexps uses) won't
find a matching parenthesis inside a preceding comment. You might
notice that in your test if you insert an open paren at the start of
the buffer and then put the cursor after "x key.)", that the open paren
_outside_ the comment is matched.
The bug is either in mic-paren or paren or, more likely, in syntax.c.
Presumably placing the cursor after a parenthesis inside a comment
should either match another parenthesis in the same comment or return
'nil, just as it would if placed after a non-parenthesis.
Either way, the bug exists in prior versions of Emacs and XEmacs, so
shouldn't affect any decision as to whether to roll back the
syntax-table changes.
Attachments:
- attachment.sig (application/pgp-signature — 232 bytes)