strange behavior with multi-buffer Lisp code

strange behavior with multi-buffer Lisp code

[Ian Zimmerman]

Hi, I am having a terrible time tracking this down.  Help!

I have written a programming language mode that can communicate with
an asynchronous process in a separate comint buffer.  The subprocess
runs an interpreter for the language, there are commands to send
chunks of code from the editing buffer to the interpreter.  And the
output from the interpreter is shown in the comint buffer.  Pretty
standard fare, I think.

One last thing I'd like to do is to look for error messages from the
interpreter in the comint buffer and jump to the error location in the
editing buffer.  This already mostly works, too.  The problem I am
having is that point changes in the comint buffer are not preserved.
Here's the code:

(defun simple-ml-goto-error ()
  "Jump to the location of a syntax error indicated in interpreter output.
Initially, this is the first error in the last chunk of code sent;
when repeated this command locates subsequent errors."
  (interactive)
  (let ((err-line
         (with-current-buffer (get-buffer "*Simple ML*")
           (if (eobp)
               (comint-previous-prompt 1))
           (if (re-search-forward simple-ml-error-regexp nil 'move)
                (string-to-int (match-string 1)) nil))))
    (if err-line
        (progn
          (goto-char simple-ml-eval-marker)
          (forward-line (1- err-line)))
      (message "No more errors in this code"))))

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

Even stranger, this only happens when the comint buffer is already
shown in some window.  It works perfectly when it is hidden.

I should add that I use GNU Emacs 20.7.

-- 
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

Re: strange behavior with multi-buffer Lisp code

[Stefan Monnier <foo@acm.com>]

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

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

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

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

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


        Stefan

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

Re: strange behavior with multi-buffer Lisp code

[Stefan Monnier <foo@acm.com>]

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

As I said, there is no such thing as THE value of point.  Instead,
there's a different value for every buffer+window pair (and this is
mostly independent from which buffer is displayed in which window.
I.e. a buffer that's not displayed anywhere still has a value of point for
each and every window).

I think what you want in your case is to look for a window displaying
this buffer, select that window, do `goto-char'.  This way, you'll
change the value of point for this buffer+window combination.  If the buffer
is displayed in several windows, you might want to move `point' in each
one of them, or to just choose one and change it only in that one.


        Stefan

Re: strange behavior with multi-buffer Lisp code

[Ian Zimmerman]

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

Stefan> As I said, there is no such thing as THE value of point.
Stefan> Instead, there's a different value for every buffer+window
Stefan> pair (and this is mostly independent from which buffer is
Stefan> displayed in which window.  I.e. a buffer that's not displayed
Stefan> anywhere still has a value of point for each and every
Stefan> window).

Stefan> I think what you want in your case is to look for a window
Stefan> displaying this buffer, select that window, do `goto-char'.
Stefan> This way, you'll change the value of point for this
Stefan> buffer+window combination.  If the buffer is displayed in
Stefan> several windows, you might want to move `point' in each one of
Stefan> them, or to just choose one and change it only in that one.

OK, that sounds like a plan.  I'll try it and report.

-- 
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

Re: strange behavior with multi-buffer Lisp code

[Ian Zimmerman]

Stefan> I think what you want in your case is to look for a window
Stefan> displaying this buffer, select that window, do `goto-char'.
Stefan> This way, you'll change the value of point for this
Stefan> buffer+window combination.  If the buffer is displayed in
Stefan> several windows, you might want to move `point' in each one of
Stefan> them, or to just choose one and change it only in that one.

itz> OK, that sounds like a plan.  I'll try it and report.

It works now :-)  Thanks for setting me on the right path.

-- 
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