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 18:09:34 +0300 Message-ID: References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1290006878 4429 80.91.229.12 (17 Nov 2010 15:14:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 17 Nov 2010 15:14:38 +0000 (UTC) Cc: 7368@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 17 16:14:33 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 1PIjiO-0005mH-IQ for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Nov 2010 16:14:29 +0100 Original-Received: from localhost ([127.0.0.1]:43997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIjiN-0007LT-UO for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Nov 2010 10:14:27 -0500 Original-Received: from [140.186.70.92] (port=52275 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIjiH-0007Ks-4S for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2010 10:14:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIjiB-0002Ll-UO for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2010 10:14:21 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIjiB-0002Lh-RL for bug-gnu-emacs@gnu.org; Wed, 17 Nov 2010 10:14:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PIjaE-0000OG-3i; Wed, 17 Nov 2010 10:06:02 -0500 X-Loop: help-debbugs@gnu.org 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 15:06: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.12900063251491 (code B ref 7368); Wed, 17 Nov 2010 15:06:02 +0000 Original-Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 15:05:25 +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 1PIjZc-0000O0-Ke for submit@debbugs.gnu.org; Wed, 17 Nov 2010 10:05:24 -0500 Original-Received: from mail-gy0-f172.google.com ([209.85.160.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIjZb-0000Nt-C6 for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 10:05:23 -0500 Original-Received: by gyh20 with SMTP id 20so1245685gyh.3 for <7368@debbugs.gnu.org>; Wed, 17 Nov 2010 07:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=bsWM0gG8lM32Eoy2Ccra4c4ELXdsZT9xxxi7yZv83NU=; b=nwVgomJDiCqotve0sHDKrilJhDVtQkmne/QQz1mnRufMxSBQSD84CVjruppXNTQ8nE w42ilRFUbklQLeUEtWsz8e/XtG/PpXYCONAR8RblvJ05uYqRdkolAJVk5vdg/MqjrmMH UKCFSiOj43yFCCgoDkBzvXkTc22rDXkhLeQUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Wcy2M1HaAoPTG7sbKPDvI/yeexkmbvxfN3GQg3ufSVZxUlCg8AOBVphx+0UISpEkIz ETmbZSzDJ8vb1JWSsDJbTMMFUUIUe9IqGRDhc98NcnG8ikPb7VKs2msBsi3I9lRcZ0fs ItUuuonRi/eosOsLtYzhJhoWBSpR6u1RqhdqM= Original-Received: by 10.204.84.156 with SMTP id j28mr9325833bkl.101.1290006623739; Wed, 17 Nov 2010 07:10:23 -0800 (PST) Original-Received: by 10.204.49.208 with HTTP; Wed, 17 Nov 2010 07:09:34 -0800 (PST) In-Reply-To: <4CE3E3C4.6060201@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 17 Nov 2010 10:06: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:41701 Archived-At: 2010/11/17 martin rudalics : > It doesn't fail in your example. =C2=A0I explained above how it can fail. Yes, I agree that switch-to-buffer fails, for example, if there is a single window on a single frame :-) I wanted to say the following: 1) In principle, switch-to-buffer may fail. 2) switch-to-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) (select-window bar-window) (switch-to-buffer baz))) 3) display-buffer uses switch-to-buffer as a subroutine. 4) display-buffer checks some conditions before calling switch-to-buffer, because the latter may fail. 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)) 6) This is because checks in display-buffer before calling switch-to-buffer and inside switch-to-buffer are different. 7) I believe this is not logical and should be fixed. 8) I think there is an easy way to fix it by checking for dedicated =3D t instead of dedicated !=3D nil inside get-lru-window and get-largest-window. Do you agree with points 1-6? > But rather than thinking about how to "fix" this I'd try to find out why > `display-buffer' is called _before_ burying the completions buffer. =C2= =A0The > plain fact that the completions buffer can be reused by `display-buffer' > indicates that it is no more useful at the time `display-buffer' gets > called. You are right, completions buffer is not useful at the time display-buffer is executed. Now completions buffer doesn't get buried because no one buries it. To bury it before display-buffer is my plan B actually ;-) The problem with this solution is that it's not general: one will have to modify many top-level commands capable of displaying a buffer to bury *Completions* beforehand. Also such modification would most likely be rejected for upstream, as properly coding when to bury *Completions* is not trivial, and that nontrivial code would be in many places. comint.el solves this problem somehow, but so far I'm not able to fully understand the code. What I see is that comint.el 's *Completions* intercepts keyboard events while it's active. Andrey Paramonov