Re: next-error-last-buffer

[Juri Linkov <juri@jurta.org>]

Miles Bader <miles@lsi.nec.co.jp> writes:
> Juri Linkov <juri@jurta.org> 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/