[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: next-error-last-buffer

From: Juri Linkov
Subject: Re: next-error-last-buffer
Date: Thu, 13 May 2004 08:34:28 +0300
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux)

Miles Bader <address@hidden> writes:
> Juri Linkov <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]