Re: strange behavior with multi-buffer Lisp code

[Ian Zimmerman]

itz> This command is intended to be executed when the language buffer
itz> is in the selected window.  simple-ml-eval-marker is set earlier
itz> by the code that sends the chunk over to the interpreter.  What
itz> happens is that this _always jumps to the same error_, because
itz> even after the point is moved by the re-search-forward in the
itz> comint buffer, it is restored for some unfathomable (to me - not
itz> to you, I hope) reason when the command returns.

Stefan> The notion of `point' is not unique for a buffer.  Each buffer
Stefan> can have several `point's, one per window.  What happens is
Stefan> that whenever you leave and re-enter the *Simple ML* buffer,
Stefan> the point is re-initialized from the point corresponding to
Stefan> the cursor in the window where *Simple ML* is displayed (or
Stefan> something like that: it's not completely clear how and when
Stefan> those things happen).

Well, I guess that was my question: how and when _do_ these things
happen? :-)  Is there anyone here who knows?  Certainly reading the
Emacs Lisp manual, the section about "excursions", gave me reason to
believe what I did should have worked.  It says the save-excursion
form exists, among other things, to preserve the value of point in the
current buffer -- implying that it is _not_ preserved unless
save-excursion is in effect.

Stefan> I.e. you'll want to explicitly maintain a marker indicating
Stefan> up-to-where you've processed the output.

Stefan> Now as to what you're doing I'd recommend you simply use the
Stefan> mechanism used for `next-error': put the *Simple ML* buffer in
Stefan> some kind of compilation-minor-mode and set the
Stefan> compilation-error-regexp-alist and friends.  Then C-x ` will
Stefan> magically work.

Stefan> Check sml-mode to see how I've done it.

Several objections:

1/ There's no "up-to-where".  I don't want to process all the errors
in linear fashion like next-error does.  The docstring in my posted
chunk of code explains the functionality I desire.

2/ I _want_ the point to change in the comint buffer, as part of the
user feedback.  The error message not only identifies the location but
also contains explanatory text about the error.  The user should
immediately see that text if she switches to the comint window.

3/ I don't want to subsume this command under next-error, both because
it works differently and because normal make-driven compilation _also_
makes sense with this tool.  If I were to do that users would have to
laboriously juggle the normal compilation buffer and the interpreter
comint buffer to switch between the two ways of working.


The more general question, abstracted from my particular situation:

How does one programatically, peristently, and reliably (independently
of variables such as window configuration) change the value of point
in a non-current buffer?

-- 
Ian Zimmerman, Oakland, California, U.S.A. I did not vote for Emperor Bush.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087