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: Thu, 13 May 2004 07:23:12 +0300 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <878yfx2bv7.fsf@mail.jurta.org> References: <871xluig40.fsf@mail.jurta.org> <873c6983t9.fsf@mail.jurta.org> <8765b3vm0r.fsf@mail.jurta.org> <4nn04fgeli.fsf@lifelogs.com> <87hdumto1j.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084422884 28128 80.91.224.253 (13 May 2004 04:34:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 13 May 2004 04:34:44 +0000 (UTC) Cc: tzz@lifelogs.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 13 06:34:36 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 1BO7vY-0000ka-00 for ; Thu, 13 May 2004 06:34:36 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BO7vW-00019i-00 for ; Thu, 13 May 2004 06:34:34 +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 1BO7pa-0005ou-AN for emacs-devel@quimby.gnus.org; Thu, 13 May 2004 00:28:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BO7pC-0005nE-Pd for emacs-devel@gnu.org; Thu, 13 May 2004 00:28:02 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BO7of-0005hj-S0 for emacs-devel@gnu.org; Thu, 13 May 2004 00:28:02 -0400 Original-Received: from [66.33.219.19] (helo=spoon.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BO7of-0005hY-H5; Thu, 13 May 2004 00:27:29 -0400 Original-Received: from mail.jurta.org (80-235-35-214-dsl.mus.estpak.ee [80.235.35.214]) by spoon.dreamhost.com (Postfix) with ESMTP id DD06013D871; Wed, 12 May 2004 21:27:26 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Wed, 12 May 2004 15:42:12 -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:23296 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23296 Richard Stallman writes: > 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. > > Is this really an improvement? It is not that hard for users > who want different behavior to edit the code. With the goal to improve configurability of the rules for finding an appropriate compilation buffer this is really an improvement. But with a list of rules suggested by Ted, there will be no need in a special variable for user-defined function. > 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. > > Perhaps next-error should always choose a compilation or occur buffer > that is visible in a window, rather than one that isn't. And it > should prefer one that is visible in the current frame to one that is > visible in another frame. This might help us get a better default > behavior. It seems this behavior will satisfy most users. BTW, there is one related inconvenience in the compilation functionality: when there is the compilation window on another frame, starting compilation places another frame over the current frame, but doesn't make it active. This is because in the function `compilation-start' the `frame' argument of `display-buffer' is `t': (display-buffer outbuf nil t) ^--- consider windows on all frames Why should compilation insist on switching frames? Shouldn't `display-buffer-reuse-frames' define the user preference instead? So I think `display-buffer' should use the default values: diff -u emacs/lisp/progmodes/compile.el~ emacs/lisp/progmodes/compile.el @@ -898,7 +905,7 @@ (if (eq outbuf (current-buffer)) (goto-char (point-max))) ;; Pop up the compilation buffer. - (setq outwin (display-buffer outbuf nil t)) + (setq outwin (display-buffer outbuf)) (with-current-buffer outbuf (if (not (eq mode t)) (funcall mode) -- Juri Linkov http://www.jurta.org/emacs/