From: Torsten Anders <t.anders@qub.ac.uk>
Subject: Multi-line comment font-lock problem for lisp-mode
Date: 12 Feb 2003 16:51:36 +0000 [thread overview]
Message-ID: <1045068696.1262.329.camel@chewa> (raw)
In-Reply-To: <87y94lqyyd.fsf@lynx.ionific.com>
Hi,
I came across some strange of the fontification of multi-line
comments in lisp mode.
I am used to put some tests calls in my code (commented out). So I
surround them by #| and |#. Emacs colours multi-line comments properly
as long as they only contain text. But as soon as I put code in the
comment (i.e. a line starting with an open parenthesis), the colouring
becomes, well, strange (i.e. rather complicated behaviour). E.g., all
code after the multi-line comment (i.e. starting with the the | in |#)
is coloured in string face (up the the next |).
To give an example, the following behaves as expected.
(defun foo ()
t)
#|
(defun foo ()
t)
(defparameter *hop* 1)
|#
(defun foo ()
t)
But just add a newline between the two expressions
commented out, and you probably see what I am speaking about.
(defun foo ()
t)
#|
(defun foo ()
t)
(defparameter *hop* 1)
|#
(defun foo ()
t)
Remove this newline again: colouring does not change back.
You might argue: OK, just use only a single expression per comment.
But change anything in the comment (e.g. add a space) and wait a few
seconds...
(defun foo ()
t)
#|
(defun foo (x)
(+ x
x)
|#
(defun foo ()
t)
Or try a more complex comment (just some arbitrary code...):
(defun foo ()
t)
#|
(defun convert-to-package (form from-package to-package)
(if (eq (find-package from-package) (find-package to-package))
form
(cond ((null form) nil)
((listp form)
(loop for item in form
collect (convert-to-package item from-package
to-package)))
((constantp form) form)
((symbolp form)
(if (eq (symbol-package form)
(find-package from-package))
(intern (symbol-name form) to-package) ; converts it to
to-package
form)) ; pass it unchanged otherwise
(T (error "Do not know how to handle ~A" form)))))
|#
(defun foo ()
t)
I read in the Emacs doc that an open parenthesis always starts a new
code block (e.g. a defun). But this behaviour looks somewhat more
complex ;-) Anyway, is this a bug? Or is there some way to switch of
this behaviour?
Thanks!
Kind regards,
Torsten Anders
PS: I am running GNU-Emacs 21.2 on a RH 8.0 Linux box
(I believe I also saw this problem on Emacs running on Win).
PPS: I am not subscribed to bug-gnu-emacs@gnu.org
--
Torsten Anders
Sonic Arts Research Centre
Queens University Belfast
Tel: +44 28 9027 4831 (office)
+44 28 9066 7439 (private)
parent reply other threads:[~2003-02-12 16:51 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <87y94lqyyd.fsf@lynx.ionific.com>]
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=1045068696.1262.329.camel@chewa \
--to=t.anders@qub.ac.uk \
/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).