emacs-devel
[Top][All Lists]
Advanced

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

Re: display-buffer-alist simplifications


From: martin rudalics
Subject: Re: display-buffer-alist simplifications
Date: Tue, 09 Aug 2011 14:55:58 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

>>>>> I'm not sure why you're so concerned about this reuse-window behavior of
>>>>> special-display-popup-frame.
>>>> Because I had some very hard time here discussing this with a user who
>>>> can't live with such behavior.
>>> And yet he wants to use dedicated frames?  Can you give some more
>>> details, because that sounds pretty odd.
>> That person can't use `special-display-popup-frame' because it doesn't
>> work correctly on his system.
>
> Again, I don't know where in that thread he says that nor why.

The author said

> > The main reason I want to do all within the current frame is because
> > Emacs doesn't raise a hidden frame.  On cygwin (I use it in the office)
> > and on Fedora 14 Linux (I use it in home), Emacs puts a newly created
> > frame on the top of the screen, but it doesn't for a frame that exists
> > but is hidden.
> >
> > As for Fedora 14, I use an external program called `wmctrl' to make
> > `raise-frame' work, but it has no effect on cygwin.  Cf.
> > http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg01117.html

> All I saw was requests to get back the Emacs-23 behavior (tho I don't
> really understand what was different there either).

The difference was that I interpreted `pop-up-frames' non-nil as the
user's agreement to reuse a window on another frame.  The same
interpretation is implicit whenever a user adds a buffer to
`special-display-regexps' making `special-display-popup-frame' search
all visible frames.

>> Sure.  But using the old code _as is_ is impossible if you want "to turn
>> the NOT-THIS-WINDOW into a SPECIFIER/RULE argument which could then make
>> same-window-* really obsolete".
>
> Maybe not absolutely "as is", but it should be possible to keep most of
> the code unchanged, I think.

For some value of "most".

>> It's just as if you wanted to reperesent one of those users who want
>> the old behavior back.  What would happen in your setup if a frame
>> were not dedicated?
>
> It all depends, but when your code recently failed to mark windows as
> dedicated, I pretty quickly noticed it because I ended up accumulating
> lots of frames showing the same buffer (often a buffer I didn't even
> ask to see).

IIUC, dedicated frames make sense in one and only one constellation:

(1) `pop-up-frames' is nil.

(2) Not all windows get a special frame.

(3) You are in a special frame and a `display-buffer' for some other
    buffer than the one shown there happens.

This is the only scenario I can think of that should cause troubles when
the frame of (3) is not dedicated.  But the buffer shown instead should
be a buffer the user asked to see.  So what you report above indicates
the existence of a bug elsewhere.  As soon as you have the time please
look into this again and report such behavior.

> It'll take me a while to change my setup to avoid dedicating windows, so
> don't hold your breath,

There's one thing that won't work for you: `bury-buffer' doesn't iconify
the frame but deletes it.  Iconification would need some extra work.

martin



reply via email to

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