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 08:34:28 +0300 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87fza4x53v.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> <878yfx2bv7.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 1084426994 1640 80.91.224.253 (13 May 2004 05:43:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 13 May 2004 05:43:14 +0000 (UTC) Cc: tzz@lifelogs.com, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 13 07:43:01 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 1BO8zl-0002tD-00 for ; Thu, 13 May 2004 07:43:01 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BO8zk-0002pX-00 for ; Thu, 13 May 2004 07:43:00 +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 1BO8y6-0001YH-W6 for emacs-devel@quimby.gnus.org; Thu, 13 May 2004 01:41:19 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BO8xy-0001XW-Me for emacs-devel@gnu.org; Thu, 13 May 2004 01:41:10 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BO8vT-0000BW-Uv for emacs-devel@gnu.org; Thu, 13 May 2004 01:39:08 -0400 Original-Received: from [66.33.219.19] (helo=spoon.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BO8vT-0000BK-IW; Thu, 13 May 2004 01:38:35 -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 5F67813D863; Wed, 12 May 2004 22:38:32 -0700 (PDT) Original-To: Miles Bader In-Reply-To: (Miles Bader's message of "13 May 2004 13:57:52 +0900") 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:23302 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23302 Miles Bader writes: > Juri Linkov writes: >> (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? > > It's not `switching frames', it's _using_ an existing compilation buffer > in a different frame. > > This is good -- the previous behavior (which didn't do that) was very > annoying: if you happened to have a *compilation* buffer displayed in > another frame, starting a compilation would none-the-less insist on > popping up another window in _this_ frame, resulting in two redundant > windows showing the *compilation* buffer. So what? I have no objection to having two compilation buffers on different frames. But the current behavior is more annoying: another frame is raised over the current frame, but is not activated. So you see the inactive frame with the point in the other frame. >> So I think `display-buffer' should use the default values: > > No. But there is the variable `display-buffer-reuse-frames' for users who like to reuse windows on another frames. I even have no objections to changing its default value to t, since I can change it to nil in .emacs. But there is no way to ignore the frame argument of `display-buffer' if it's specified explicitly. -- Juri Linkov http://www.jurta.org/emacs/