<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>I am using Aquamacs to run supercollider
(<a class="moz-txt-link-freetext" href="http://supercollider.sourceforge.net">http://supercollider.sourceforge.net</a>) via sclang-mode. One of the
features is rudimentary document integration. When a buffer is opened
for a supercollider code file, it gets registered with a
sclang-document object on the Lisp side, and functions are called in
the supercollider interpreter to create a Document object pointing to
it.<br>
<br>
The problem is when a buffer gets killed. There's a hook to close the
document:<br>
<br>
(defun sclang-document-kill-buffer-hook-function ()<br>
  (sclang-close-document (current-buffer)))<br>
<br>
(defun sclang-close-document (buffer)<br>
  (with-sclang-document<br>
   buffer<br>
   (message "closing buf id %d" sclang-document-id)<br>
   (setq sclang-document-list (delq buffer sclang-document-list))<br>
   (sclang-perform-command-no-result<br>
    'documentClosed sclang-document-id)))<br>
<br>
(defmacro with-sclang-document (buffer &rest body)<br>
  `(when (sclang-document-p buffer)<br>
     (with-current-buffer buffer<br>
       ,@body)))<br>
<br>
I'm observing that the main body of sclang-close-document is running
every time a buffer is killed, even if the buffer should not be
associated with a sclang-document. The result is that Document objects
are being closed in the sclang interpreter even though their buffers
still exist in Emacs. <br>
<br>
But, for instance, if I open a class library file, I can see on the
interpreter side that it gets ID 3. But when I kill that buffer,
supercollider closes the document for ID 2. So now I have a Document
object in the interpreter for a buffer that is gone, and another buffer
that is still open in Emacs has no Document object in the interpreter.<br>
<br>
It sounds like with-current-buffer is operating on the wrong buffer.<br>
<br>
I've been discussing this with the sclang-mode developers and they are
convinced that the code is fine. Moreover, <i>this behavior is not
reproducible in Emacs on Linux</i>. So it suggests that Aquamacs is
evaluating the Lisp function(s) in this case differently from standard
Emacs.<br>
<br>
Any ideas? If there is a discrepancy (I know, I know, "Aquamacs is not
Emacs!"), how could the sclang-mode functions be modified to be safe
for both standard Emacs and Aquamacs?<br>
<br>
hjh<br>
<br>
<br>
</tt>
<div class="moz-signature"><tt>-- <br>
</tt>
<p><tt>James Harkins /// dewdrop world<br>
<a class="moz-txt-link-abbreviated" href="mailto:jamshark70@dewdrop-world.net">jamshark70@dewdrop-world.net</a><br>
<a class="moz-txt-link-freetext" href="http://www.dewdrop-world.net">http://www.dewdrop-world.net</a><br>
<br>
"Come said the Muse,<br>
Sing me a song no poet has yet chanted,<br>
Sing me the universal." -- Whitman<br>
<br>
blog: <a href="http://www.dewdrop-world.net/words">http://www.dewdrop-world.net/words</a><br>
audio clips: <a href="http://www.dewdrop-world.net/audio">http://www.dewdrop-world.net/audio</a><br>
more audio: <a href="http://soundcloud.com/dewdrop_world/tracks">http://soundcloud.com/dewdrop_world/tracks</a></tt>
</p>
</div>
</body>
</html>