From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?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?= Newsgroups: gmane.emacs.bugs Subject: bug#7368: display-buffer a softly dedicated window Date: Wed, 17 Nov 2010 11:57:32 +0300 Message-ID: References: <87y690q1qa.fsf@neo.paramonovs> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1289985273 31790 80.91.229.12 (17 Nov 2010 09:14:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 17 Nov 2010 09:14:33 +0000 (UTC) Cc: 7368@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 17 10:14:25 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 1PIe5w-0001ge-ON for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Nov 2010 10:14:25 +0100 Original-Received: from localhost ([127.0.0.1]:59029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIe5v-0006yn-Gr for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Nov 2010 04:14:23 -0500 Original-Received: from [140.186.70.92] (port=45563 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIe5n-0006x1-Md for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2010 04:14:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIe5m-000248-IA for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2010 04:14:15 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIe5m-00023s-Eb for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2010 04:14:14 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PIdmE-00046k-Dq; Wed, 17 Nov 2010 03:54:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87y690q1qa.fsf@neo.paramonovs> Resent-From: =?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-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Nov 2010 08:54: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.128998399315780 (code B ref 7368); Wed, 17 Nov 2010 08:54:02 +0000 Original-Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 08:53:13 +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 1PIdlR-00046T-4R for submit@debbugs.gnu.org; Wed, 17 Nov 2010 03:53:13 -0500 Original-Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIdlQ-00046O-6P for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 03:53:12 -0500 Original-Received: by bwz12 with SMTP id 12so1357502bwz.3 for <7368@debbugs.gnu.org>; Wed, 17 Nov 2010 00:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type; bh=8L4k0d2tGYlaWkwumdVA4CLOo+Q0vIi518KG9EDsqjo=; b=J2z44PrREnB2cbf7fg/K2X2AClotulcX04kfoTHvevPGrZnM56A1AlvKr+ejX4kgmC dFCmEb9PjtfJo/A9aaV5xH+PUXordXdT8Nf1Cpoa7LKmsUt5dfW+Oa5iPX4kLig4Aqus 15YSuNS+8Lk+7v4wZKKLsBTa3oDgcI4+WiUOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=U6uC5QQjAv5VvLh6+1Mm5EsgGJ0A9Kxdwc7T4xdNUSs8g0yekeo6z3zg1edZoxgpoR LbNwpK94yxYUwqngi7I8sxZA5N/n915qC9Wuy9y4a386vfCcL6zS0kzzcy6Wf1diqrPL mx4jMV9xN1I+hHnB4yl9jUGVajaLkhPTO6p4g= Original-Received: by 10.204.100.206 with SMTP id z14mr8718008bkn.209.1289984293087; Wed, 17 Nov 2010 00:58:13 -0800 (PST) Original-Received: by 10.204.49.208 with HTTP; Wed, 17 Nov 2010 00:57:32 -0800 (PST) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 17 Nov 2010 03:54: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:41685 Archived-At: 2010/11/17 Stefan Monnier : >> 1) A "softly dedicated" window is a window tied to a certain buffer, >> and when that buffer is destroyed the window is destroyed too. > > I think in general that would not be right (e.g. for my use of > soft-dedicated windows). I'm curious what is your use-case. Would truly-dedicated windows fit it? > But I agree that display-buffer should > probably override the soft-dedication in the case where it would > otherwise have to create a new frame and the user has pop-up-frames set > to nil. > I bevieve it's reasonable to override soft-dedication unconditionally. The checks for dedicated != nil seem to be needed only because switch-to-buffer would fail on a "truly dedicated" buffer. However, switch-to-buffer would never fail on a "softly dedicated" buffer, only on a "truly dedicated" one, so it seems logical to rather check for dedicated = t. I strongly believe display-buffer and switch-to-buffer should do the same thing in the following minimal example: (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) (select-window bar-window) (switch-to-buffer baz))) (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)) For that to work, only a small patch for get-lru-window and get-largest-window is needed. However I understand that although logical, this tiny change might break something. Should I relabel the bug accordingly, or create a new one? Best wishes, Andrey Paramonov