From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ian Zimmerman Newsgroups: gmane.emacs.help Subject: Re: strange behavior with multi-buffer Lisp code Date: 18 Nov 2002 10:31:15 -0800 Organization: http://extra.newsguy.com Sender: help-gnu-emacs-admin@gnu.org Message-ID: <86k7jaenm4.fsf@kronstadt.homeunix.net> References: <86heefd2h6.fsf@kronstadt.homeunix.net> <5lheeezwcb.fsf@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037646739 4148 80.91.224.249 (18 Nov 2002 19:12:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 18 Nov 2002 19:12:19 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18DrJh-00014h-00 for ; Mon, 18 Nov 2002 20:12:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18DrIf-0007I6-00; Mon, 18 Nov 2002 14:11:13 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews3 Original-Newsgroups: gnu.emacs.help Original-Lines: 63 Original-NNTP-Posting-Host: p-187.newsdawg.com User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Original-Xref: shelby.stanford.edu gnu.emacs.help:107163 Original-To: help-gnu-emacs@gnu.org Errors-To: help-gnu-emacs-admin@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.help:3714 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:3714 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