From: Ian Zimmerman <itz@speakeasy.org>
Subject: strange behavior with multi-buffer Lisp code
Date: 17 Nov 2002 18:40:53 -0800 [thread overview]
Message-ID: <86heefd2h6.fsf@kronstadt.homeunix.net> (raw)
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
next reply other threads:[~2002-11-18 2:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-18 2:40 Ian Zimmerman [this message]
2002-11-18 16:17 ` strange behavior with multi-buffer Lisp code Stefan Monnier <foo@acm.com>
2002-11-18 18:31 ` Ian Zimmerman
2002-11-18 22:36 ` Stefan Monnier <foo@acm.com>
2002-11-19 0:38 ` Ian Zimmerman
2002-11-19 6:04 ` Ian Zimmerman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86heefd2h6.fsf@kronstadt.homeunix.net \
--to=itz@speakeasy.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.