GNU bug report logs - #7368
display-buffer may not respect pop-up-frames value

Previous Next

Full log

Message #58 received at 7368 <at> debbugs.gnu.org (full text, mbox):

From: Андрей Парамонов
	<cmr.pent <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 7368 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#7368: display-buffer a softly dedicated window
Date: Thu, 18 Nov 2010 11:32:04 +0300

2010/11/18 martin rudalics <rudalics <at> gmx.at>:
> They are implemented in ELisp on the window-pub branch.
> ...
> Use a window parameter say `delete-window-when-buffer-is-buried'.  When
> a window is created by `display-buffer', right after the
> `set-window-buffer' call, set the parameter to the buffer argument.  In
> `bury-buffer', `replace-buffer-in-windows', ... if the parameter value
> of `delete-window-when-buffer-is-buried' equals the buffer of the
> window, delete the window if possible.  Look at the quit-restore
> parameter in the window-pub branch.

Now I'm tempted to try out that branch. What is the best way to do so?

> If that's the case you can do away with the completions window whenever
> you want to.  I see little difference between deleting the completions
> window manually and having `display-buffer' use it for showing another
> buffer.

Deleting *Completions* manually requires a keystroke, and more
importantly, remembering to do that keystroke. Every time when I wish
to switch to interpreter. That's very disruptive!

> The distinction is that the _user_ should be allowed to reuse a weakly
> dedicated window, for example, when switching buffers in the selected
> window.  Application programs should not be allowed to use them.

Now I think see your point.

>> No. The command showing *Completions* and command calling
>> display-buffer are totally unrelated. See the first message.
>
> This doesn't make sense to me.  I consider popping up a completions
> window and subsequently deleting it one user interaction that should not
> be disrupted by other activities like displaying some unrelated buffer.

Well, maybe my workflow is not typical, but I find it effective:

1) Write code.

2) Run it.

3) Write more code.

4) To inspect what methods an object has, hit M-Tab.

5) Look, scratch head ;-)

6) In a burst of inspiration, quickly switch to interpreter to inspect
a field of an object.

7) Switch back to the code buffer.

8) goto 1)

Everything except 1, 2, 5 should need only muscle memory, no thinking.
Hope you understand what I mean.

Best wishes,
Andrey Paramonov

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.