--Jeff
I don't know if this is related, but I've been running into a matching problem on large projects exclusively, but it isn't parenthesis, its double-quotes. Specifically, if I type a long text string after a function declaration like this:
(defun somefunction () "some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text some text" (format t "some long format string with vars" var1 var2 var3))
What will happen is that everything after the description text is colored the same as if it were all commented out, and indenting works the same. It doesn't compile right either. When it happens, the only fix I've been able to find is to shorton the descriptive text to a single line, then everything straightens out and flies right.
It has never happened in a short file and only occasionally in a long one.
I'm running CMUCL 19a and if I could remember how to get the slime version, I'd give you that too. :\
--Jeff cunningham
--Jeff
On Sun Sep 04, 2005 at 05:20:33PM -0700, Jeff Cunningham wrote:
--Jeff
I don't know if this is related, but I've been running into a matching problem on large projects exclusively, but it isn't parenthesis, its double-quotes. Specifically, if I type a long text string after a function declaration like this:
It doesn't depend on file length at all. I managed to extract an example with bad behavior. If you paste this bit of code 'exactly' in a .lisp file and open it in a slime buffer it looks fine. but then remove the three comments characters so the string is a string with embedded \Newlines. In my current environment everything which follows the string alternates sporadically between the string color and normal colors, as if the terminating string character is no longer matched correctly. But it seems more like an emacs problem than a slime problem.
(defun add-info-to-toc (trackblocks toctrks) ;; "Local function adds descriptive info in segment trackblock from ;; order source to TOC which is only assumed to have position/timings ;; (defined by GWC or equivalent)." (let ((ntracks (number-of-tracks trackblocks))) (cond ((= ntracks (length toctrks)) (format t "* length matchs number of segment tracks~%") (do* ((trackblock (car trackblocks)) (tracks (tracks trackblock) (cdr tracks)) (track (car tracks) (car tracks)) (toc-tracks toctrks (cdr toc-tracks)) (toc-track (car toc-tracks) (car toc-tracks)) (modtoctrks)) ((null toc-track) (reverse modtoctrks)) (unless track (setf trackblock ;get the next trackblock (car (setf trackblocks (cdr trackblocks)))) (setf tracks (tracks trackblock))) (push (move-info-to-toc track toc-track) modtoctrks))) ((= ntracks 1) (format t "* no match, but there's only one segment track~%") (spread-info (car (tracks (car trackblocks))) toctrks)) ((= (length toctrks) 1) (format t "* no match but only one toctrk~%") (mapcar #'move-info-to-toc trackblocks toctrks)) (t (format t "#ntracks=~a, trackblocks: ~s~%" ntracks trackblocks) (write-trackblocks trackblocks t :verbosity t) (format t "#toctrks [~a]: ~s~%" (length toctrks) toctrks) (error "number of segment tracks differs non-trivially from TOC tracks")))))
Jeff Cunningham jeffrey@cunningham.net writes:
(defun add-info-to-toc (trackblocks toctrks) ;; "Local function adds descriptive info in segment trackblock from ;; order source to TOC which is only assumed to have position/timings ;; (defined by GWC or equivalent)."
See (info "(emacs)Left Margin Paren")
-
bojohan+news＠dd.chalmers.se -
Jeff Cunningham