From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#7368: display-buffer a softly dedicated window Date: Thu, 18 Nov 2010 09:03:36 +0100 Message-ID: <4CE4DDD8.8000105@gmx.at> References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1290068070 716 80.91.229.12 (18 Nov 2010 08:14:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 18 Nov 2010 08:14:30 +0000 (UTC) Cc: 7368@debbugs.gnu.org To: =?UTF-8?Q?=D0=90=D0=BD=D0=B4=D1=80=D0=B5=D0=B9_?= =?UTF-8?Q?=D0=9F=D0=B0=D1=80=D0=B0=D0=BC=D0=BE=D0=BD=D0=BE=D0=B2?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 18 09:14:26 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PIzdR-0006ig-H6 for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Nov 2010 09:14:25 +0100 Original-Received: from localhost ([127.0.0.1]:42199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIzdQ-0004qH-DK for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Nov 2010 03:14:24 -0500 Original-Received: from [140.186.70.92] (port=54815 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIzdL-0004qC-92 for bug-gnu-emacs@gnu.org; Thu, 18 Nov 2010 03:14:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIzdK-0006aM-0l for bug-gnu-emacs@gnu.org; Thu, 18 Nov 2010 03:14:19 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIzdJ-0006aI-RS for bug-gnu-emacs@gnu.org; Thu, 18 Nov 2010 03:14:17 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PIzOY-0000kD-8B; Thu, 18 Nov 2010 02:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Nov 2010 07:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7368 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7368-submit@debbugs.gnu.org id=B7368.12900671212855 (code B ref 7368); Thu, 18 Nov 2010 07:59:02 +0000 Original-Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 07:58:41 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIzOD-0000k0-4Y for submit@debbugs.gnu.org; Thu, 18 Nov 2010 02:58:41 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PIzO8-0000jv-SC for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 02:58:38 -0500 Original-Received: (qmail invoked by alias); 18 Nov 2010 08:03:39 -0000 Original-Received: from 62-47-48-54.adsl.highway.telekom.at (EHLO [62.47.48.54]) [62.47.48.54] by mail.gmx.net (mp037) with SMTP; 18 Nov 2010 09:03:39 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+wG9c2ttew69Go/LEod+vNMk/sZuLOp63Hmg8oQ4 X+heCya414EpdC User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 18 Nov 2010 02:59:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:41722 Archived-At: > 1) In principle, set-window-buffer may fail. When the window is strongly dedicated to its buffer and doesn't show the buffer already. > 2) set-window-buffer doesn't fail in > > (let ((foo (get-buffer-create "foo")) > (bar (get-buffer-create "bar")) > (baz (get-buffer-create "baz"))) > (switch-to-buffer foo) > (delete-other-windows) > (let ((bar-window (display-buffer bar t))) > (set-window-dedicated-p bar-window 'soft) > (set-window-buffer bar-window baz))) > > 3) display-buffer uses set-window-buffer as a subroutine. > > 4) display-buffer checks some conditions before calling > set-window-buffer, because the latter may fail. To avoid that `set-window-buffer' reports an error. > 5) display-buffer fails in > > (let ((foo (get-buffer-create "foo")) > (bar (get-buffer-create "bar")) > (baz (get-buffer-create "baz"))) > (switch-to-buffer foo) > (delete-other-windows) > (let ((bar-window (display-buffer bar t))) > (set-window-dedicated-p bar-window 'soft)) > (display-buffer baz t)) > The fact that it doesn't use bar-window for displaying the buffer is not a "failure" per se. > 6) This is because checks in display-buffer before calling > set-window-buffer and inside set-window-buffer are different. Yes. > 7) I believe this is not logical and should be fixed. Logic is in the mind of the beholder. I can see two reasons for making a window weakly dedicated: (a) Give the application programmer a way to tell `display-buffer' that it should finding another window for displaying the buffer. The user is allowed to switch to another buffer whenever she wants to. (b) Make the window disappear when it's no more needed. If there's consensus that (a) is not needed or useful I agree with your conclusion. Personally, I do not need weakly dedicated windows, so I have no opinion about this. > 8) I think there is an easy way to fix it by checking for dedicated = > t instead of dedicated != nil inside get-lru-window and > get-largest-window (by the way, is there any chance those are > implemented in Lisp?). They are implemented in ELisp on the window-pub branch. >> If the window is dedicated for the sole purpose to make it disappear >> when it's no more need I tend to agree. There are better solutions. > > Please tell which. 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. > The minibuffer.el 's completion mechanism does not impose any > restrictions on what you can do while *Completions* is visible. That's > slightly off-topic, but I think it allows more user freedom and > clearer code. 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. >> The _only_ purpose of weakly dedicated windows is to not allow >> `display-buffer' to use them. > > I disagree. As a matter of fact, weakly dedicated windows possess > another property: they are deleted when their buffer is killed. > > As a matter of personal opinion, "not allow `display-buffer' to use > them, but allow `set-window-buffer' to use them" is very hard concept > to understand. Especially given that `display-buffer' uses > `set-window-buffer' inside ;-) Even harder to understand is the > distinction between weakly and truly dedication. 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. >> IIUC the sequence of events is >> >> (1) the application issues a call for getting the name of a buffer, >> >> (2) the user enters the name with the assistance of the completion >> routines, >> >> (3) the completion routines return the name, >> >> (4) the caller displays the buffer with that name. >> > > 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. martin