From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: next-error-last-buffer Date: Wed, 12 May 2004 02:46:48 +0300 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87hdumto1j.fsf@mail.jurta.org> References: <871xluig40.fsf@mail.jurta.org> <873c6983t9.fsf@mail.jurta.org> <8765b3vm0r.fsf@mail.jurta.org> <4nn04fgeli.fsf@lifelogs.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084327416 16650 80.91.224.253 (12 May 2004 02:03:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 May 2004 02:03:36 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 12 04:03:27 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNj5j-00029r-00 for ; Wed, 12 May 2004 04:03:27 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNj5j-0002Vm-00 for ; Wed, 12 May 2004 04:03:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNizw-0002KV-Di for emacs-devel@quimby.gnus.org; Tue, 11 May 2004 21:57:28 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNiyY-0001Uj-EO for emacs-devel@gnu.org; Tue, 11 May 2004 21:56:02 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNixs-00014w-0L for emacs-devel@gnu.org; Tue, 11 May 2004 21:55:57 -0400 Original-Received: from [66.33.219.6] (helo=knife.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNixr-00014c-L0 for emacs-devel@gnu.org; Tue, 11 May 2004 21:55:19 -0400 Original-Received: from mail.jurta.org (80-235-44-143-dsl.mus.estpak.ee [80.235.44.143]) by knife.dreamhost.com (Postfix) with ESMTP id 68556E4094; Tue, 11 May 2004 18:55:17 -0700 (PDT) Original-To: Ted Zlatanov In-Reply-To: <4nn04fgeli.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 11 May 2004 11:36:57 -0400") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23208 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23208 Ted Zlatanov writes: > I'll be glad to help with suggestions and code to implement the > changes you want in the next-error API. The current implementation of next-error framework is general enough to allow implementing different approaches easily (for example, I was able to implement the desired behavior with only one small change in the `next-error' function), but it is still not extensible enough. Based on my recent experience, I want to make some suggestions how to make it more extensible: 1. Add an option to allow the user to select among predefined behaviors. Though, this will not help the user if he will not find a desired option in the predefined set. 2. Add a new user variable `next-error-find-buffer-function' and try to call it (i.e. to call it if it's fbound and return its value, but if it returns `nil', try other rules) in `next-error-find-buffer' at the top precedence level before all other rules. This will allow the user to override the standard rules for finding the next-error capable buffer with his own rule. 3. Add a hook to `next-error' after the `funcall next-error-function' to allow the user to perform actions (such as setting buffer-local variables) in the buffer found by `next-error-function'. Making the next-error framework more extensible is only half the job. Finding a good default behavior is no less important. I thought again about why the current behavior is too confusing and I think I found the reason: the most confusing is the fact that the compilation buffer is visible in the window adjacent to the source file window where the point is located, but typing C-x ` uses the last but not visible compilation buffer. So w.r.t. `next-error-find-buffer' I propose to modify it to use the following priority order: 1(new). Try to call a user-defined `next-error-find-buffer-function'. 2. If the current buffer is a next-error capable buffer, return it. 3(new). If a next-error capable buffer is in one of the windows of the current frame, return it. 4. If next-error-last-buffer is set to a live buffer, use that. 5. Otherwise, look for a next-error capable buffer 6. Signal an error if there are none. -- Juri Linkov http://www.jurta.org/emacs/