From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 10 16:54:53 2010 Received: (at submit) by debbugs.gnu.org; 10 Nov 2010 21:54:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PGId2-00048a-RW for submit@debbugs.gnu.org; Wed, 10 Nov 2010 16:54:53 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PGId0-00048V-Bi for submit@debbugs.gnu.org; Wed, 10 Nov 2010 16:54:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PGIhZ-0002uw-S9 for submit@debbugs.gnu.org; Wed, 10 Nov 2010 16:59:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:34472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PGIhZ-0002uT-PN for submit@debbugs.gnu.org; Wed, 10 Nov 2010 16:59:33 -0500 Received: from [140.186.70.92] (port=37067 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGIhY-0007mr-IN for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2010 16:59:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PGIhX-0002ts-3f for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2010 16:59:32 -0500 Received: from mail-ey0-f169.google.com ([209.85.215.169]:35449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PGIhW-0002to-O7 for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2010 16:59:31 -0500 Received: by eydd26 with SMTP id d26so724329eyd.0 for ; Wed, 10 Nov 2010 13:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:to:subject:date :message-id:mime-version:content-type; bh=h8CrfP14C2Ha8ciHbkIqsDf8Zfgq0rnBRSvb2Cc/YMA=; b=QNAR3veEWBu7kl+jb1Tzgl7aWW3CGepEVVYwB1QLKGTIVr69/v4BLt3GEDPZglzAJF k6zcBMhqARJvYFLYxHqzA9YyZJadaK52NHfAatc20jVbAWzQ6IVRnezp6/qg8NBJ8tDj /j/MIGX0K9WXY3DxcnFC/VZ62EtXb9zNdGxaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type; b=loz3zTUyvqNF/A6rS0LGiKfiWMNLhIgG7pX4s8lVFw/KlTAWS4pF3Bp6qb027JYVfv VjKXPXNV6HxcOUJVGts+T3zmzupABAB8oR+2OSMAHDSVhk8VRMcOybkuvujrmuF//Prl FDYGlbg23G2Q2qdp2aVijCAr/nVV27jdZxXYI= Received: by 10.14.127.2 with SMTP id c2mr2898997eei.3.1289426369708; Wed, 10 Nov 2010 13:59:29 -0800 (PST) Received: from neo.paramonovs (aparamon.static.corbina.ru [89.179.245.94]) by mx.google.com with ESMTPS id w20sm1170729eeh.12.2010.11.10.13.59.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 13:59:27 -0800 (PST) Received: from pent by neo.paramonovs with local (Exim 4.72) (envelope-from ) id 1PGIhS-0007Xf-1P for bug-gnu-emacs@gnu.org; Thu, 11 Nov 2010 00:59:26 +0300 From: Andrey Paramonov To: bug-gnu-emacs@gnu.org Subject: 23.2; Python interpreter buffer should never appear in separate frame Date: Thu, 11 Nov 2010 00:59:25 +0300 Message-ID: <87y690q1qa.fsf@neo.paramonovs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) Hello! Most of the time, python-switch-to-python splits current frame and activates Python interpreter buffer in a new window. This is handy and consistent with other interpreter modes, i.e. ESS. However, *sometimes* Python interpreter is activated in a separate frame. This is very inconvenient, especially because of "sometimes". Python interpreter buffer should always appear in the current frame, and never in separate frame. To reproduce: 0) emacs -Q 1) Create/open the following minimal example (| shows cursor pos): import os.path os.path.| 2) Press C-c C-z. Python interpreter buffer appears *in a new window*. This is correct. 3) Switch to python code buffer, press ESC-ESC-ESC. 4) Press M-Tab. Completion buffer appears in a new window. This is correct. 5) Press C-c C-z. Python interpreter buffer pops up *in a new frame*. This is incorrect. I'm ready to provide any additional info, Andrey Paramonov In GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-08-15 on raven, modified by Debian Windowing system distributor `The X.Org Foundation', version 11.0.10707000 configured using `configure '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS='' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ru_RU.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Inferior Python Minor modes in effect: compilation-shell-minor-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Fontifying *Python*... (regexps...........) Making completion list... [2 times] Load-path shadows: /usr/share/emacs/23.2/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup /usr/share/emacs/23.2/site-lisp/flim/md4 hides /usr/share/emacs/23.2/lisp/md4 /usr/share/emacs/23.2/site-lisp/flim/hex-util hides /usr/share/emacs/23.2/lisp/hex-util /usr/share/emacs/23.2/site-lisp/flim/sha1 hides /usr/share/emacs/23.2/lisp/sha1 /usr/share/emacs/23.2/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/23.2/lisp/textmodes/flyspell /usr/share/emacs/23.2/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/23.2/lisp/textmodes/ispell /usr/share/emacs/23.2/site-lisp/flim/ntlm hides /usr/share/emacs/23.2/lisp/net/ntlm /usr/share/emacs/23.2/site-lisp/flim/sasl-cram hides /usr/share/emacs/23.2/lisp/net/sasl-cram /usr/share/emacs/23.2/site-lisp/flim/sasl hides /usr/share/emacs/23.2/lisp/net/sasl /usr/share/emacs/23.2/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/23.2/lisp/net/sasl-ntlm /usr/share/emacs/23.2/site-lisp/flim/sasl-digest hides /usr/share/emacs/23.2/lisp/net/sasl-digest /usr/share/emacs/23.2/site-lisp/flim/hmac-md5 hides /usr/share/emacs/23.2/lisp/net/hmac-md5 /usr/share/emacs/23.2/site-lisp/flim/hmac-def hides /usr/share/emacs/23.2/lisp/net/hmac-def Features: (shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1 sha1-el hex-util hashcash mail-utils emacsbug compile python-21 python comint ring help-mode easymenu view cyril-util tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 13 01:32:08 2010 Received: (at 7368) by debbugs.gnu.org; 13 Nov 2010 06:32:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PH9ei-0004D8-6G for submit@debbugs.gnu.org; Sat, 13 Nov 2010 01:32:08 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PH9eg-0004Cm-Fj for 7368@debbugs.gnu.org; Sat, 13 Nov 2010 01:32:06 -0500 Received: by bwz12 with SMTP id 12so3782780bwz.3 for <7368@debbugs.gnu.org>; Fri, 12 Nov 2010 22:36:56 -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:content-type; bh=Z5XWCokJiyxDiLkjmnrnj79AudKsC+BZIaJKyMUNv6E=; b=k3b8YzAgqY5D3k7artcrforHaRPd/witzSsyCiZM5CHBX9FW3WPCmuVEfhKKeZDoaX 47WnW2CWcofjeg9m0dlHR2DyD0pKIl8OJEBkJQJoNPB/aT65d1qsA7pEoCxzQNVteC1H P04AULpM3U3rzu2/9sMdRq3xDITR28Sy0vtO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=h7S8nqrYttI7OH2VR4nvfQr8ufaqJdOW9htu63qWvk6OtCrCNbdB0wZZaqThFmtLLw TfjsXGVZEQYcNIeVUvsR8ae+Qp2KIv2Yr7VGHEZeKbx4MOV2AOJdYtdrelpSL/UAXHRh pYPKSKULcIk77+ETOCgjMMtoJjYbQe28JSvZc= Received: by 10.204.84.156 with SMTP id j28mr3729401bkl.101.1289630216484; Fri, 12 Nov 2010 22:36:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Fri, 12 Nov 2010 22:36:16 -0800 (PST) From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Sat, 13 Nov 2010 09:36:16 +0300 Message-ID: Subject: Testcase To: 7368@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 7368 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) It turns out that the problem is not specific to Python mode. The following minimal example reproduces it. C-h v pop-up-frames RET says: pop-up-frames's value is nil Documentation: Whether `display-buffer' should make a separate frame. If nil, never make a separate frame. However, a new frame *does* pop up for me after running the following code: (let ((foo (get-buffer-create "foo.el")) (bar (get-buffer-create "bar.el"))) (switch-to-buffer foo) (delete-other-windows) (completion-at-point) (display-buffer bar t)) Best wishes, Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 13 03:06:53 2010 Received: (at control) by debbugs.gnu.org; 13 Nov 2010 08:06:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHB8O-0006GJ-Tk for submit@debbugs.gnu.org; Sat, 13 Nov 2010 03:06:53 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHB8N-0006GE-8j for control@debbugs.gnu.org; Sat, 13 Nov 2010 03:06:51 -0500 Received: by bwz12 with SMTP id 12so3816301bwz.3 for ; Sat, 13 Nov 2010 00:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=656T8OaVIf/pEdK3/i+Sv3ff8Uj5PwVuzqpQYkAKCYo=; b=AR/BSEviDjDpzLGPu1oDfYMIaUgEEYKHg2ws8K1vpLG/8DOfZlrnfvVN5s7IORykYm 3MRuyUvT+vACbg3DW4iYpX423zX1vetHoNKo0a0aylhLNpMUwIRwV0Cwz7XeKBYVU2n5 FNIXctjMK4cRXVRxMY0ZzFekj6/HjgUSiuVx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=K9VX3C36/8/iWJpO38EYFqHkXI0Yp4S9H5hpwCbKL4srmHKW0oMxxGI4Zh2Biu3BnQ ESd4VPhy/n6RDbRHz025+CW3AGJMhseFUKRuoiHekww3X5EsR1vIYlX6qtsVL7h6auH3 ipUgYgDsWcH0Dh9rmYkjRiVJsSKIVcUXED2ZM= Received: by 10.204.119.145 with SMTP id z17mr3749252bkq.128.1289635901525; Sat, 13 Nov 2010 00:11:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Sat, 13 Nov 2010 00:11:01 -0800 (PST) From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Sat, 13 Nov 2010 11:11:01 +0300 X-Google-Sender-Auth: ZUerL5WFUr9Un-H-8R477uQht8Y Message-ID: Subject: display-buffer may not respect pop-up-frames value To: control@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) retitle 7368 display-buffer may not respect pop-up-frames value From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 13 03:27:59 2010 Received: (at 7368) by debbugs.gnu.org; 13 Nov 2010 08:27:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHBSo-00075g-VS for submit@debbugs.gnu.org; Sat, 13 Nov 2010 03:27:59 -0500 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 1PHBSm-00075Q-Gt for 7368@debbugs.gnu.org; Sat, 13 Nov 2010 03:27:57 -0500 Received: (qmail invoked by alias); 13 Nov 2010 08:32:46 -0000 Received: from 62-47-61-175.adsl.highway.telekom.at (EHLO [62.47.61.175]) [62.47.61.175] by mail.gmx.net (mp055) with SMTP; 13 Nov 2010 09:32:46 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19UTPJbZYFU8Aeh/VXwh10rc18kmymy59aCwdwrMf YT134oyB7XDsym Message-ID: <4CDE4D2D.2000304@gmx.at> Date: Sat, 13 Nov 2010 09:32:45 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: Testcase References: <87y690q1qa.fsf@neo.paramonovs> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > C-h v pop-up-frames RET says: > > pop-up-frames's value is nil > > Documentation: > Whether `display-buffer' should make a separate frame. > If nil, never make a separate frame. > > However, a new frame *does* pop up for me after running the following code: > > (let ((foo (get-buffer-create "foo.el")) > (bar (get-buffer-create "bar.el"))) > (switch-to-buffer foo) > (delete-other-windows) > (completion-at-point) > (display-buffer bar t)) On my trunk Emacs your code produces a new window on the selected frame. Apparently, some of your settings prevent it from splitting the selected window and the second argument t means `display-buffer' must not reuse the selected window. So `display-buffer' simply has no other choice but making a new frame. BTW, the snippet (progn (delete-other-windows) (display-buffer (other-buffer) t)) should be sufficient for exhibiting the behavior you observe. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 13 03:43:12 2010 Received: (at 7368) by debbugs.gnu.org; 13 Nov 2010 08:43:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHBhX-0007CM-V1 for submit@debbugs.gnu.org; Sat, 13 Nov 2010 03:43:12 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHBhV-0007CH-Ip for 7368@debbugs.gnu.org; Sat, 13 Nov 2010 03:43:10 -0500 Received: by bwz12 with SMTP id 12so3830912bwz.3 for <7368@debbugs.gnu.org>; Sat, 13 Nov 2010 00:47:59 -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=E6tyyWBESCvx6Mk7QEqfbYqSjizAVAf39S4JGeUQFgw=; b=TRyj1KjqpHyD8//MypdtLlGOcmM8no1IodO84tyQLS4CeoIciyTZksTDloyb+mUrxp RbNkHPwpyG0Xbvjh4atoiG6OBN+B7Ict6Y01YwyfvIYpcELdITLDLUGGVBJjVju/t6Vw UaRP5XxgYIkAn5OcHGWyLVa8f5wCkI73RfmuU= 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=qBambFNCx2+AP/PQEfYyoUNf17nMObDdnl3p58HCxFIpR+9UHMucf/s7lzxEt/iJTt 9RAblbaifk3/vxgSVuujIFgC/D94RQSsOf+ZOWE9N23gPqF50plSF1mcNMFkEKRW/Or9 hqkbTanIBD5VzNw1C7qSzIjMP279YNsb99QBY= Received: by 10.204.104.5 with SMTP id m5mr3799537bko.47.1289638079800; Sat, 13 Nov 2010 00:47:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Sat, 13 Nov 2010 00:47:19 -0800 (PST) In-Reply-To: <4CDE4D2D.2000304@gmx.at> References: <87y690q1qa.fsf@neo.paramonovs> <4CDE4D2D.2000304@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Sat, 13 Nov 2010 11:47:19 +0300 Message-ID: Subject: Re: bug#7368: Testcase To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) 2010/11/13 martin rudalics : > On my trunk Emacs your code produces a new window on the selected frame. Ah, sorry. Here is the modified version which I've actually checked ;-) (let ((foo (get-buffer-create "foo.el")) (bar (get-buffer-create "bar.el"))) (switch-to-buffer foo) (delete-other-windows) (emacs-lisp-mode) (insert "(a") (completion-at-point) (display-buffer bar t)) > So `display-buffer' simply has no other choice but > making a new frame. In principle, in this very awkward situation display-buffer has 3 options: 1) To display buffer in selected window -- but not-in-this-window=3Dt. 2) To display buffer in a new frame -- but pop-up-frames says we *never* make a separate frame. 3) To display buffer in place of completions window -- but that window is "dedicated". To me option 3 seems the least unexpected. Anyway, something needs to be fixed, as current documentation for pop-up-frames is wrong. > BTW, the snippet > > (progn > =C2=A0(delete-other-windows) > =C2=A0(display-buffer (other-buffer) t)) > > should be sufficient for exhibiting the behavior you observe. No, the completions buffer plays important role. Thanks for your support, Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 13 04:50:37 2010 Received: (at 7368) by debbugs.gnu.org; 13 Nov 2010 09:50:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PHCkn-0007eA-1u for submit@debbugs.gnu.org; Sat, 13 Nov 2010 04:50:37 -0500 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 1PHCkk-0007e3-Aa for 7368@debbugs.gnu.org; Sat, 13 Nov 2010 04:50:35 -0500 Received: (qmail invoked by alias); 13 Nov 2010 09:55:24 -0000 Received: from 62-47-61-175.adsl.highway.telekom.at (EHLO [62.47.61.175]) [62.47.61.175] by mail.gmx.net (mp067) with SMTP; 13 Nov 2010 10:55:24 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+B9xZG2zqBc3oyd+xJTtPeCZ64rpG480EYLSag3B oHZXCLUTq7HeFl Message-ID: <4CDE608A.8040003@gmx.at> Date: Sat, 13 Nov 2010 10:55:22 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: Testcase References: <87y690q1qa.fsf@neo.paramonovs> <4CDE4D2D.2000304@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > In principle, in this very awkward situation display-buffer has 3 options: > > 1) To display buffer in selected window -- but not-in-this-window=t. > > 2) To display buffer in a new frame -- but pop-up-frames says we > *never* make a separate frame. > > 3) To display buffer in place of completions window -- but that window > is "dedicated". > > To me option 3 seems the least unexpected. Anything can happen here. If `display-buffer' doesn't find a better window "the normal way", it may use the selected or the dedicated window as well. > Anyway, something needs to be fixed, as current documentation for > pop-up-frames is wrong. Most `display-buffer' related doc-strings are "wrong" in this regard. They are based on behaviors where at least one approach gets through "the normal way". Note that `display-buffer' is supposed to _always_ return a window although you can easily set up options in a way that do not allow to do that (as in your example). We would have to introduce some sort of priority telling Emacs which option is allowed to violate which restriction in which order, document that, and confuse people even more. BTW, you might want to have a look at my window-pub branch where all `display-buffer' related options are combined in two almost identic options called `display-buffer-names' and `display-buffer-regexps'. The doc-string of the former and its documentation are formulated in less stringent terms. >> BTW, the snippet >> >> (progn >> (delete-other-windows) >> (display-buffer (other-buffer) t)) >> >> should be sufficient for exhibiting the behavior you observe. > > No, the completions buffer plays important role. Make your frame small enough and you can see the problem here too. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 15 17:37:54 2010 Received: (at 7368) by debbugs.gnu.org; 15 Nov 2010 22:37:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PI7gP-0004RD-PL for submit@debbugs.gnu.org; Mon, 15 Nov 2010 17:37:53 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PI7gN-0004R5-7b for 7368@debbugs.gnu.org; Mon, 15 Nov 2010 17:37:51 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQHALtG4UxFpY76/2dsb2JhbAChXX1ywR+FSgSEWo1f X-IronPort-AV: E=Sophos;i="4.59,202,1288584000"; d="scan'208";a="82629049" Received: from 69-165-142-250.dsl.teksavvy.com (HELO ceviche.home) ([69.165.142.250]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 15 Nov 2010 17:42:48 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 4966C660DC; Mon, 15 Nov 2010 17:42:48 -0500 (EST) From: Stefan Monnier To: =?utf-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: Testcase Message-ID: References: <87y690q1qa.fsf@neo.paramonovs> <4CDE4D2D.2000304@gmx.at> Date: Mon, 15 Nov 2010 17:42:48 -0500 In-Reply-To: (=?utf-8?B?ItCQ0L3QtNGA0LXQuSDQn9Cw0YDQsNC80L7QvdC+0LIiJ3M=?= message of "Sat, 13 Nov 2010 11:47:19 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 7368 Cc: martin rudalics , 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > In principle, in this very awkward situation display-buffer has 3 options: > 1) To display buffer in selected window -- but not-in-this-window=t. > 2) To display buffer in a new frame -- but pop-up-frames says we > *never* make a separate frame. > 3) To display buffer in place of completions window -- but that window > is "dedicated". It's actually soft-dedicated (i.e. dedicated but switch-to-buffer can override it). > To me option 3 seems the least unexpected. Agreed. Another option is to create a third window. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 16 15:15:32 2010 Received: (at 7368) by debbugs.gnu.org; 16 Nov 2010 20:15:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIRwC-0007hF-Lf for submit@debbugs.gnu.org; Tue, 16 Nov 2010 15:15:32 -0500 Received: from mail-gw0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIRwB-0007hA-5L for 7368@debbugs.gnu.org; Tue, 16 Nov 2010 15:15:31 -0500 Received: by gwb10 with SMTP id 10so723534gwb.3 for <7368@debbugs.gnu.org>; Tue, 16 Nov 2010 12:20:31 -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; bh=zixwijzHNC2TsnnG+mggm5gu5cTPZ0ACNWddI+TIaa0=; b=jwcJwYw+o0auFZO4LWLfBM5ObEVampJ8vW8O43a2q7Kui0QlmBIn2K3PsIHLvfR+xN 6icv+ypUZ8gXeO5x2CQTkP0kKbU6iUMRm0S8jaKMZ70mVqbl8B5yzJh802YLOiJ6gihQ tk9VyI8/FhVqhhAjSNfdpVgD003w/Z7q5GKzE= 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; b=NZ2iHyUjQIJ3AqWge65DU+d2FedEym7vaJc/iNlYpLIYPPKuCsBtZ9ew9PBahH2QUP HpVEzBzWnm8oH8N4G10/5qEt5CE4wzRCUq88DfNfPGGLSr4DFX3OnTA4QZNGKANiXFs4 gksqWc5nPri7cW5kcXWsH8+0z4beQeqn3oRW8= Received: by 10.204.102.141 with SMTP id g13mr8036519bko.74.1289938830379; Tue, 16 Nov 2010 12:20:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Tue, 16 Nov 2010 12:19:50 -0800 (PST) In-Reply-To: References: <87y690q1qa.fsf@neo.paramonovs> <4CDE4D2D.2000304@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Tue, 16 Nov 2010 23:19:50 +0300 Message-ID: Subject: Re: bug#7368: Testcase To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 7368 Cc: martin rudalics , 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 2010/11/16 Stefan Monnier : > It's actually soft-dedicated (i.e. dedicated but switch-to-buffer can > override it). After another debug session I see that there are 2 types of special windows: 1) A "softly dedicated" window is a window with 2 properties: a) it is tied to a certain buffer, and when that buffer is destroyed the window is destroyed too; b) it cannot be target of display-buffer. 2) A "truly dedicated" window is a window with 3 properties: a) it is tied to a certain buffer, and when that buffer is destroyed the window is destroyed too; b) it cannot be target of display-buffer; c) it cannot be target of switch-to-buffer. Wouldn't it be more logical to have the following? 1) A "softly dedicated" window is a window tied to a certain buffer, and when that buffer is destroyed the window is destroyed too. 2) A "truly dedicated" window is a "softly dedicated" window which cannot be target of neither display-buffer nor switch-to-buffer. That would solve the problem, but I'm beginning to doubt if it's worth it to solve the problem generally... Best wishes, Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 16 16:21:05 2010 Received: (at 7368) by debbugs.gnu.org; 16 Nov 2010 21:21:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PISxc-00088q-HO for submit@debbugs.gnu.org; Tue, 16 Nov 2010 16:21:04 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PISxa-00088P-4O for 7368@debbugs.gnu.org; Tue, 16 Nov 2010 16:21:02 -0500 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id oAGLQ1dj010709; Tue, 16 Nov 2010 16:26:01 -0500 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id BF34B130096; Tue, 16 Nov 2010 16:25:56 -0500 (EST) From: Stefan Monnier To: =?utf-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: Testcase Message-ID: References: <87y690q1qa.fsf@neo.paramonovs> <4CDE4D2D.2000304@gmx.at> Date: Tue, 16 Nov 2010 16:25:56 -0500 In-Reply-To: (=?utf-8?B?ItCQ0L3QtNGA0LXQuSDQn9Cw0YDQsNC80L7QvdC+0LIiJ3M=?= message of "Tue, 16 Nov 2010 23:19:50 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3681=0 X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 7368 Cc: martin rudalics , 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > After another debug session I see that there are 2 types of special windows: > 1) A "softly dedicated" window is a window with 2 properties: > a) it is tied to a certain buffer, and when that buffer is destroyed > the window is destroyed too; > b) it cannot be target of display-buffer. > 2) A "truly dedicated" window is a window with 3 properties: > a) it is tied to a certain buffer, and when that buffer is destroyed > the window is destroyed too; > b) it cannot be target of display-buffer; > c) it cannot be target of switch-to-buffer. > Wouldn't it be more logical to have the following? > 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). 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. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 03:53:13 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 08:53:13 +0000 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 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 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= Received: by 10.204.100.206 with SMTP id z14mr8718008bkn.209.1289984293087; Wed, 17 Nov 2010 00:58:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Wed, 17 Nov 2010 00:57:32 -0800 (PST) From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Wed, 17 Nov 2010 11:57:32 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 7368 Cc: martin rudalics , 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 04:41:13 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 09:41:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIeVs-0004PY-Qv for submit@debbugs.gnu.org; Wed, 17 Nov 2010 04:41:13 -0500 Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PIeVp-0004PT-Ck for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 04:41:10 -0500 Received: (qmail invoked by alias); 17 Nov 2010 09:46:09 -0000 Received: from 62-47-60-30.adsl.highway.telekom.at (EHLO [62.47.60.30]) [62.47.60.30] by mail.gmx.net (mp064) with SMTP; 17 Nov 2010 10:46:09 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18L+IVQdJwL9GmV3TCGAS+XEi28pD9JwT3KTJxqCA K9ZQnH8Qoc7eOu Message-ID: <4CE3A45E.9090705@gmx.at> Date: Wed, 17 Nov 2010 10:46:06 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: Testcase References: <87y690q1qa.fsf@neo.paramonovs> <4CDE4D2D.2000304@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > 1) A "softly dedicated" window is a window with 2 properties: > a) it is tied to a certain buffer, and when that buffer is destroyed > the window is destroyed too; Not necessarily. If there are no other windows left or the window previoulsy showed another buffer the window is not destroyed. > b) it cannot be target of display-buffer. > > 2) A "truly dedicated" window is a window with 3 properties: > a) it is tied to a certain buffer, and when that buffer is destroyed > the window is destroyed too; See above. > b) it cannot be target of display-buffer; > c) it cannot be target of switch-to-buffer. It cannot be target of `set-window-buffer' which subsumes all other cases. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 04:41:32 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 09:41:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIeWC-0004Pm-4U for submit@debbugs.gnu.org; Wed, 17 Nov 2010 04:41:32 -0500 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 1PIeWA-0004Pg-MT for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 04:41:31 -0500 Received: (qmail invoked by alias); 17 Nov 2010 09:46:26 -0000 Received: from 62-47-60-30.adsl.highway.telekom.at (EHLO [62.47.60.30]) [62.47.60.30] by mail.gmx.net (mp069) with SMTP; 17 Nov 2010 10:46:26 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19lLDkzeSRlfB0cc27d6Os/K5FVy+7zBTOVR82E+a r5DJ6r6NcJRJx3 Message-ID: <4CE3A46C.6080605@gmx.at> Date: Wed, 17 Nov 2010 10:46:20 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > 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, It could fail because it falls back on `display-buffer' when the selected window is a minibuffer window or dedicated. `pop-to-buffer' and the remaining members of the `switch-to-buffer' family always fail to use a weakly dedicated window. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 04:54:28 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 09:54:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIeih-0004V2-DA for submit@debbugs.gnu.org; Wed, 17 Nov 2010 04:54:27 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIeif-0004Uw-Fw for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 04:54:25 -0500 Received: by bwz12 with SMTP id 12so1413290bwz.3 for <7368@debbugs.gnu.org>; Wed, 17 Nov 2010 01:59:26 -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=TtrI0No5ZUtc6N9jfrzrnP3y0f7PgMdAMe4CGasNS1Q=; b=hXhA2HIZFbzbmEuQYK+H1UgSojvXGvakxukXmBkkirlbImmjPOBFFSqv9tYsYGyvkh AmzVsW8XyVHC9EvzNj8xq0Xj2wYFC3VWkvaroCDyFQuWmnpeQ7D/abOGVReAWVDzb8Ug iZdxsVLZdNsahLB1Q3xq8h/ubZQMgMUGe84mo= 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=rROsJg5lfN4rRHNakeA5SZHwbUZJ3y7mjNK5rl9Rtjhry7JAEIJTqMt3StUvdLYM4x yQMJMidiLJngfK6HrrkiB4hV7lZyylxoBhr5c5nKn+Ksh9kxOYOuSHj1NsssJB4uqku4 l9fk9c/oG3Caa53yQAI0M7XxNyMei0fDJ88ME= Received: by 10.204.53.135 with SMTP id m7mr486463bkg.74.1289987966236; Wed, 17 Nov 2010 01:59:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Wed, 17 Nov 2010 01:58:45 -0800 (PST) In-Reply-To: <4CE3A46C.6080605@gmx.at> References: <4CE3A46C.6080605@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Wed, 17 Nov 2010 12:58:45 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) 2010/11/17 martin rudalics : >> I bevieve it's reasonable to override soft-dedication unconditionally. >> The checks for dedicated !=3D 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, > > It could fail because it falls back on `display-buffer' when the > selected window is a minibuffer window or dedicated. =C2=A0`pop-to-buffer= ' > and the remaining members of the `switch-to-buffer' family always fail > to use a weakly dedicated window. > I mean override soft-dedication *inside* display-buffer. And switch-to-buffer actually doesn't fail to override "softly dedicated" window (see my examle). Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 09:11:54 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 14:11:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIijq-0008Mz-9h for submit@debbugs.gnu.org; Wed, 17 Nov 2010 09:11:54 -0500 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 1PIijn-0008Mu-Ir for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 09:11:53 -0500 Received: (qmail invoked by alias); 17 Nov 2010 14:16:48 -0000 Received: from 62-47-60-99.adsl.highway.telekom.at (EHLO [62.47.60.99]) [62.47.60.99] by mail.gmx.net (mp003) with SMTP; 17 Nov 2010 15:16:48 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18A/Bd17/kAnLVZ8EImN1JGULYVgUP4ghQY5ic60G N+H8zYkrxliIcM Message-ID: <4CE3E3C4.6060201@gmx.at> Date: Wed, 17 Nov 2010 15:16:36 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) >> It could fail because it falls back on `display-buffer' when the >> selected window is a minibuffer window or dedicated. `pop-to-buffer' >> and the remaining members of the `switch-to-buffer' family always fail >> to use a weakly dedicated window. >> > > I mean override soft-dedication *inside* display-buffer. And > switch-to-buffer actually doesn't fail to override "softly dedicated" > window (see my examle). It doesn't fail in your example. I explained above how it can fail. 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. The 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. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 10:05:25 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 15:05:25 +0000 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 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 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= Received: by 10.204.84.156 with SMTP id j28mr9325833bkl.101.1290006623739; Wed, 17 Nov 2010 07:10:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Wed, 17 Nov 2010 07:09:34 -0800 (PST) In-Reply-To: <4CE3E3C4.6060201@gmx.at> References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Wed, 17 Nov 2010 18:09:34 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 12:09:03 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 17:09:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIlVG-0001uh-Q7 for submit@debbugs.gnu.org; Wed, 17 Nov 2010 12:09:03 -0500 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 1PIlUx-0001uR-Ln for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 12:09:00 -0500 Received: (qmail invoked by alias); 17 Nov 2010 17:13:43 -0000 Received: from 62-47-60-99.adsl.highway.telekom.at (EHLO [62.47.60.99]) [62.47.60.99] by mail.gmx.net (mp055) with SMTP; 17 Nov 2010 18:13:43 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+sQflQEq+seQnQrMC5zaKbKmiVeAofoJDXiEc+fM b+pL/YIeJ7HJaG Message-ID: <4CE40D45.8080004@gmx.at> Date: Wed, 17 Nov 2010 18:13:41 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > 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. That would be a very bad idea ;-) > 4) display-buffer checks some conditions before calling > switch-to-buffer, because the latter may fail. As a matter of fact, both 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. See above. > 7) I believe this is not logical and should be fixed. 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. But if an application is allowed to display another buffer _while the completions window is shown_ it would be a bad idea to use the completions window. > 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. The _only_ purpose of weakly dedicated windows is to not allow `display-buffer' to use them. What else would they be good for after your "fix"? And what would you do if someone made completion windows strongly dedicated to their buffer? > Do you agree with points 1-6? If you rewrote them correctly, maybe. > 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. 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. Now why does the completion window not go away after (3) and before (4) and what makes it go away after (4)? > 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. After returning a value the completions buffer should be buried immediately. So there must be something tricky in this. > 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. It's not the task of the application to care about the window. > 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. That's not very nice either :-( martin From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 17 13:51:08 2010 Received: (at 7368) by debbugs.gnu.org; 17 Nov 2010 18:51:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIn63-00041W-H7 for submit@debbugs.gnu.org; Wed, 17 Nov 2010 13:51:07 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIn61-000414-Kp for 7368@debbugs.gnu.org; Wed, 17 Nov 2010 13:51:06 -0500 Received: by bwz12 with SMTP id 12so1940980bwz.3 for <7368@debbugs.gnu.org>; Wed, 17 Nov 2010 10:56:07 -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=BVXdUZ0MxZoO9sbP3+cB5FM1hoQgJgbRWTmIYBOJ2MA=; b=HvEVCzdhPh5rSUsJSBBUwE+eKExfDohCb5lKfX7h+S81lKe0gueQ0gF3qCgSJ/2gp6 cPQqwobweQv9g0TJ2PqiJn8qIL/v9EJiTx/Ky/0n3rr6McGG7uV+O7ll31FmQsEs50I8 rVQIlwq6rj3cgQocc30Yb8c2M8v8NOiwSkyeY= 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=cyGVbKjLBtB9N/O2PpglCySx3Rfb0Z2SK4Scq9U0HdtDplH92524XDPbEP4PRXUPwe iDOG4SQ7cpQ/B5LDNyKkeRZPx2pq4K9xEI75uC9KiAj4sEHJh99NeUaSuiAETacs6J5z 9fdihGSG/UVZ1jbjuDOAYSALz9XhOEJH1z7yw= Received: by 10.204.80.97 with SMTP id s33mr9752867bkk.182.1290020167408; Wed, 17 Nov 2010 10:56:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Wed, 17 Nov 2010 10:55:27 -0800 (PST) In-Reply-To: <4CE40D45.8080004@gmx.at> References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Wed, 17 Nov 2010 21:55:27 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) 2010/11/17 martin rudalics : >> Do you agree with points 1-6? > > If you rewrote them correctly, maybe. Ok, let's try again ;-) I completely messed up set-window-buffer and switch-to-buffer, sorry. 1) In principle, set-window-buffer may fail. 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. 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 set-window-buffer and inside set-window-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 (by the way, is there any chance those are implemented in Lisp?). 2010/11/17 martin rudalics : > If the window is dedicated for the sole purpose to make it disappear > when it's no more need I tend to agree. =C2=A0There are better solutions. Please tell which. > But if an application is allowed to display another buffer _while the > completions window is shown_ it would be a bad idea to use the > completions window. 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. > 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. I think that the following is much easier to grasp (although that's not the primary goal): 1) Weakly dedicated: auto-closes when it's buffer is closed. 2) Truly dedicated: cannot display another buffer, auto-closes when it's buffer is closed. >=C2=A0What else would they be good for after > your "fix"? =C2=A0And what would you do if someone made completion window= s > strongly dedicated to their buffer? I do not know. But thinking a bit, completion windows would be "persistent" (would not disappear until you kill it explicitly). I can imagine it might be not useless. However I personally wouldn't make them strongly dedicated and wouldn't advice to do so. > 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 > =C2=A0 =C2=A0routines, > > (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. Best wishes, Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 02:58:41 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 07:58:41 +0000 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 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 Received: (qmail invoked by alias); 18 Nov 2010 08:03:39 -0000 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 Message-ID: <4CE4DDD8.8000105@gmx.at> Date: Thu, 18 Nov 2010 09:03:36 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 03:27:43 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 08:27:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIzqI-0000w5-Pn for submit@debbugs.gnu.org; Thu, 18 Nov 2010 03:27:42 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIzqH-0000w0-8I for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 03:27:41 -0500 Received: by bwz12 with SMTP id 12so2562499bwz.3 for <7368@debbugs.gnu.org>; Thu, 18 Nov 2010 00:32:44 -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=zAhtCUtH7OqF0qXrt3SRUlGwsvr4CU9+hS98U4+vl7Y=; b=N7vGl2xQM6k75PilQ6NGvtQ6hN8UJIEFXCChJoezGw0tFwuHIIlo13wtAdAfXiCUMa lqf351vS3B5YRA4WkYDDTE48ZLiVSJO3oXUn1LYOyRR2nhnMUzcewwCoVckrmhh7vvC5 chDgRsVrJpedvtjmebEp9gE4JDR7bNmWtvXpw= 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=HuAQTNB7gtx8FJFn8V+9W/aUh2g8HJ3R3f9nuiA9QgkPySkSokTkfw8jG1nO8cFzoB wqekIxA71BMUuehYfAu16KEM8fdjlv0xwU+WJSXUUOrUC2j9lJSm4yHiId+sCBpjK5Fg TR5qdBU0+W5NT1NZxK82hIMiOSYn/wrcNAhpI= Received: by 10.204.84.156 with SMTP id j28mr264595bkl.101.1290069164514; Thu, 18 Nov 2010 00:32:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Thu, 18 Nov 2010 00:32:04 -0800 (PST) In-Reply-To: <4CE4DDD8.8000105@gmx.at> References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Thu, 18 Nov 2010 11:32:04 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) 2010/11/18 martin rudalics : > They are implemented in ELisp on the window-pub branch. > ... > Use a window parameter say `delete-window-when-buffer-is-buried'. =C2=A0W= hen > a window is created by `display-buffer', right after the > `set-window-buffer' call, set the parameter to the buffer argument. =C2= =A0In > `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. =C2=A0Look 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. =C2=A0I see little difference between deleting the completio= ns > 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. =C2=A0Application 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. =C2=A0I 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 04:02:58 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 09:02:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ0OP-0001EY-TN for submit@debbugs.gnu.org; Thu, 18 Nov 2010 04:02:58 -0500 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 1PJ0ON-0001ER-AF for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 04:02:56 -0500 Received: (qmail invoked by alias); 18 Nov 2010 09:07:57 -0000 Received: from 62-47-48-54.adsl.highway.telekom.at (EHLO [62.47.48.54]) [62.47.48.54] by mail.gmx.net (mp003) with SMTP; 18 Nov 2010 10:07:57 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+WBnEfcLeWUre3YI0CaUeMvET8/bZHHhlxG8olfR v+BhLZtZ9+B8b2 Message-ID: <4CE4ECEA.8030602@gmx.at> Date: Thu, 18 Nov 2010 10:07:54 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > Now I'm tempted to try out that branch. What is the best way to do so? I never tried but if you checked out the trunk with bzr something like bzr branch bzr://bzr.savannah.gnu.org/emacs/window-pub window-pub in the directory of your shared emacs repository should work. I don't know how to work with the git mirror. [...] > 6) In a burst of inspiration, quickly switch to interpreter to inspect > a field of an object. And here you want the completions window show the interpreter? > 7) Switch back to the code buffer. But here you've lost the completions window. > 8) goto 1) > > Everything except 1, 2, 5 should need only muscle memory, no thinking. > Hope you understand what I mean. Why don't you use three windows in your workflow? martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 04:36:02 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 09:36:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ0uP-0001Sz-W4 for submit@debbugs.gnu.org; Thu, 18 Nov 2010 04:36:02 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ0uM-0001Sq-6Y for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 04:35:59 -0500 Received: by bwz12 with SMTP id 12so2608206bwz.3 for <7368@debbugs.gnu.org>; Thu, 18 Nov 2010 01:41:01 -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; bh=0K/7vRfGlOB4Jldrs9k+8yjmLor1pZFMUh5+UkYtp3c=; b=koGxVpl9y0Wi56aEb6UVQhzmlqwHNlOTiTw9CoerWigwXYtowU0UwuzbDeS/r4XKJ1 gtlRXD3WOQPwLFhVKEtNcDEce0FElFpre135zTNzsEfausJI4eD2az0lumnICWgLU2TW WQ0C/mGtiFNNSg5JtjdfydJKEB/XfRQxuYKe8= 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; b=RkVe+rhbeuHk+3SpnvBqGeBcPQtp+w3iMm8JlX7GJ9P+ZjvbjFEaDBajp9lQQ+zZ+4 UJ+XIqgWHz0kS3SJj25DnKUYmKC+dGvGaazZxcjsqyRY5mgC7dXJOqC0/IPoJVFRKQrl C6kAn0C0WWJEXIfgsfVt1M/8EtY6puug87aJY= Received: by 10.204.80.97 with SMTP id s33mr315339bkk.182.1290073260596; Thu, 18 Nov 2010 01:41:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Thu, 18 Nov 2010 01:40:20 -0800 (PST) In-Reply-To: <4CE4ECEA.8030602@gmx.at> References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Thu, 18 Nov 2010 12:40:20 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) 2010/11/18 martin rudalics : > I never tried but if you checked out the trunk with bzr something like > bzr branch bzr://bzr.savannah.gnu.org/emacs/window-pub window-pub Thanks, I'll try it soon and report the results. >> 6) In a burst of inspiration, quickly switch to interpreter to inspect >> a field of an object. > > And here you want the completions window show the interpreter? comint.el forces *Completions* to close and shows the interpreter immediately, in its place. That's what I want, exactly. Showing the interpreter in place of *Completions* would have the same effect, so it's what I want, too. >> 7) Switch back to the code buffer. > > But here you've lost the completions window. Yes, but that's no problem as I'll be able to quickly resurrender it by hitting M-Tab. > Why don't you use three windows in your workflow? My code window occupies full frame most of the time. That allows me to see more code. Best wishes, Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 05:22:16 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 10:22:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ1d8-0001kf-I3 for submit@debbugs.gnu.org; Thu, 18 Nov 2010 05:22:15 -0500 Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PJ1d5-0001kY-Qw for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 05:22:13 -0500 Received: (qmail invoked by alias); 18 Nov 2010 10:27:14 -0000 Received: from 62-47-48-54.adsl.highway.telekom.at (EHLO [62.47.48.54]) [62.47.48.54] by mail.gmx.net (mp012) with SMTP; 18 Nov 2010 11:27:14 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18KB28+yUYK86kSYLrEgISudz4NaNEFI5ChHKT589 erNLp8W2OzZ0cJ Message-ID: <4CE4FF80.4080404@gmx.at> Date: Thu, 18 Nov 2010 11:27:12 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > comint.el forces *Completions* to close and shows the interpreter > immediately, in its place. That's what I want, exactly. Showing the > interpreter in place of *Completions* would have the same effect, so > it's what I want, too. I've looked into comint.el. It's apparently based on window configurations and restores the old configuration when you do `choose-completion' or type SPACE. I don't see where it deletes the window when you do something else. Very contrived code. > My code window occupies full frame most of the time. That allows me to > see more code. Hm... What about setting `display-buffer-function' to something like: (defun my-display-buffer (buffer flag) (let (window display-buffer-function) (when (and (= (length (window-list)) 2) (setq window (get-buffer-window "*Completions*"))) (set-window-dedicated-p window nil)) (display-buffer buffer flag))) martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 05:32:38 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 10:32:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ1nC-0001oz-0w for submit@debbugs.gnu.org; Thu, 18 Nov 2010 05:32:38 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ1nA-0001ou-81 for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 05:32:36 -0500 Received: by bwz12 with SMTP id 12so2655711bwz.3 for <7368@debbugs.gnu.org>; Thu, 18 Nov 2010 02:37:39 -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=KZrU932tcm4ctMANCwmFTvFNc409rojbt/0uqezhakE=; b=Kf+qDRY68LqjzY55KhUjAN17Uc81gpIsE/8hQ2VoZX+XFIhmw7Z0YJA4o36l9ApzUQ 33TALmKrEGBYcFr2P9xLipkCnB+CbBRPWuKmpgRET7j6TKVyx0CZbpn3yrDbc/+OqdzV gcOH+pYvpYuz37WAcHchb+aNzVEMLDklb7TSg= 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=PHL3xdvgq313ACw/Epq/QKGpugM4PYjgSAVOU+5RRZaQ1tcAWaMb72vZvSmnSz0N6a 5nu63RfPeEU550v/0M5xU6S2I3QYzk1IeBN1myiZJf80YvXxj/rfklZluqSOQt4bL42b 6xtu9kaAYm8jQFjc1uKFDre+LJXdFTwn55Z4s= Received: by 10.204.100.206 with SMTP id z14mr375871bkn.209.1290076659688; Thu, 18 Nov 2010 02:37:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Thu, 18 Nov 2010 02:36:59 -0800 (PST) In-Reply-To: <4CE4FF80.4080404@gmx.at> References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Thu, 18 Nov 2010 13:36:59 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) 2010/11/18 martin rudalics : >> comint.el forces *Completions* to close and shows the interpreter >> immediately, in its place. That's what I want, exactly. Showing the >> interpreter in place of *Completions* would have the same effect, so >> it's what I want, too. > > I've looked into comint.el. =C2=A0It's apparently based on window > configurations and restores the old configuration when you do > `choose-completion' or type SPACE. =C2=A0I don't see where it deletes the > window when you do something else. =C2=A0Very contrived code. If you are interested you may check the example I provided in my recent emacs.devel thread. *Completions* is somehow closed before comint-dynamic-list-completions is finished (comint-dynamic-list-completions doesn't exit immediately upon showing *Completions*). > Hm... =C2=A0What about setting `display-buffer-function' to something lik= e: > > (defun my-display-buffer (buffer flag) > =C2=A0(let (window display-buffer-function) > =C2=A0 =C2=A0(when (and (=3D (length (window-list)) 2) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq window (get-buffer= -window "*Completions*"))) > =C2=A0 =C2=A0 =C2=A0(set-window-dedicated-p window nil)) > =C2=A0 =C2=A0(display-buffer buffer flag))) > Hm, nice idea. But isn't display-buffer-function called from display-buffer (infinite recursion)? I'll check it when I get to my Emacs box. Best wishes, Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 08:15:38 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 13:15:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ4Kv-0003mV-Tf for submit@debbugs.gnu.org; Thu, 18 Nov 2010 08:15:38 -0500 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 1PJ4Ks-0003mQ-PW for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 08:15:36 -0500 Received: (qmail invoked by alias); 18 Nov 2010 13:20:38 -0000 Received: from 62-47-48-54.adsl.highway.telekom.at (EHLO [62.47.48.54]) [62.47.48.54] by mail.gmx.net (mp047) with SMTP; 18 Nov 2010 14:20:38 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18TMRAzvXIT6R9S5shTNxFrcVNh4bIp5rq5hU6QP4 O69aN18hUTGecK Message-ID: <4CE52824.4050304@gmx.at> Date: Thu, 18 Nov 2010 14:20:36 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > Hm, nice idea. But isn't display-buffer-function called from > display-buffer (infinite recursion)? I'll check it when I get to my > Emacs box. Whenever you call `display-buffer' from `display-buffer-function' make sure that you've bound the latter to nil around the call. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 14:51:28 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 19:51:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJAVz-0006Wj-Lx for submit@debbugs.gnu.org; Thu, 18 Nov 2010 14:51:27 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJAVw-0006WH-9q for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 14:51:24 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id oAIJuRtW006677; Thu, 18 Nov 2010 14:56:28 -0500 Received: by pastel.home (Postfix, from userid 20848) id EAE86A82D6; Thu, 18 Nov 2010 09:18:13 -0500 (EST) From: Stefan Monnier To: =?utf-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window Message-ID: References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> Date: Thu, 18 Nov 2010 09:18:13 -0500 In-Reply-To: (=?utf-8?B?ItCQ0L3QtNGA0LXQuSDQn9Cw0YDQsNC80L7QvdC+0LIiJ3M=?= message of "Thu, 18 Nov 2010 11:32:04 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3683=0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 7368 Cc: martin rudalics , 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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! Maybe the fact that *Completions* is still shown at this point is a bug. If I were you, I'd focus on this point first. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 14:51:45 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 19:51:45 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJAWG-0006X6-4q for submit@debbugs.gnu.org; Thu, 18 Nov 2010 14:51:44 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJAWE-0006X1-Px for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 14:51:43 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id oAIJucv7016856; Thu, 18 Nov 2010 14:56:38 -0500 Received: by pastel.home (Postfix, from userid 20848) id 7C98AA82AD; Wed, 17 Nov 2010 08:10:01 -0500 (EST) From: Stefan Monnier To: =?utf-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Subject: Re: bug#7368: display-buffer a softly dedicated window Message-ID: References: Date: Wed, 17 Nov 2010 08:10:01 -0500 In-Reply-To: (=?utf-8?B?ItCQ0L3QtNGA0LXQuSDQn9Cw0YDQsNC80L7QvdC+0LIiJ3M=?= message of "Wed, 17 Nov 2010 11:57:32 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3683=0 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 7368 Cc: martin rudalics , 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.3 (-) > I strongly believe display-buffer and switch-to-buffer should do the > same thing in the following minimal example: This is irrelevant because calling switch-to-buffer from Elisp is a bug in my book. One important property of soft-dedicated windows is that the window's buffer won't be changed except upon explicit request from the user (with C-x b). Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 18 15:51:28 2010 Received: (at 7368) by debbugs.gnu.org; 18 Nov 2010 20:51:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJBS4-0006x6-EV for submit@debbugs.gnu.org; Thu, 18 Nov 2010 15:51:28 -0500 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJBS2-0006x1-W0 for 7368@debbugs.gnu.org; Thu, 18 Nov 2010 15:51:27 -0500 Received: by eyd10 with SMTP id 10so2376666eyd.3 for <7368@debbugs.gnu.org>; Thu, 18 Nov 2010 12:56:32 -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; bh=rNIF7EU78KxMYc14ythCIrHOZDQIFJhNspk8Sz4oKtk=; b=t1xVuaYST2t1qttwUCjVO7sYp+l0Mw9tyV2w6uazJlRWjSr1qa64nnFM5Nq7kkT4GU tylJ9Pm0Ic+AsnWM3Ff2AFJaQiG/PrVdLeBeqx5lR7wn5aV42NIonQjRxZY3XZD+vttp nSbhtKHQqnHNvM8ObAEwsvZOMEucoUWysfOLY= 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; b=NMcq5p85gP7DgsPwLVVsnwopRyLR3WeQCGBjAGZ96hllw/7ehd+SvvpSd7JbDf9h94 VAQcFJBoy0zluflgcGrxwIDiOTr26vRBEsIidNFCkONhsUZ3yrqjJOOwibtBi7H3ti9w UrKMBgtk5PwlusV16nOEdRAqRp8qZ2gf6W8PA= Received: by 10.213.28.131 with SMTP id m3mr4044661ebc.58.1290113791354; Thu, 18 Nov 2010 12:56:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.22.135 with HTTP; Thu, 18 Nov 2010 12:56:11 -0800 (PST) In-Reply-To: References: From: Lennart Borgman Date: Thu, 18 Nov 2010 21:56:11 +0100 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org, =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) 2010/11/17 Stefan Monnier : > > This is irrelevant because calling switch-to-buffer from Elisp is a bug > in my book. Which book is that? (I thought the elisp manual was yours.) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 19 01:26:24 2010 Received: (at 7368) by debbugs.gnu.org; 19 Nov 2010 06:26:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJKQS-0002BK-4B for submit@debbugs.gnu.org; Fri, 19 Nov 2010 01:26:24 -0500 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PJKQQ-0002BE-5h for 7368@debbugs.gnu.org; Fri, 19 Nov 2010 01:26:22 -0500 Received: by bwz12 with SMTP id 12so3655947bwz.3 for <7368@debbugs.gnu.org>; Thu, 18 Nov 2010 22:31:27 -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; bh=it8cx2Kl628xvKO0PCszHMhXPMJsqnbPwyvhLZpuz6E=; b=I4oLsqA2jQDFFUOoeQkdab1Pp3TVFtby/VQZ5+s9Zx0arfSuIxk8a+XIHcgAbwFR72 9zxVZaAAVcv/9MqfPutbniarZ7ghPEPYllYgXAL1RvzSz9h5NFCdofOjOV/3bsG2CwUW vhbeRq4wLwLJZRirDK8a31fyMmI622xGKjoQs= 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; b=ktpFqNRfAV/1saElWhcYXOIEDoh5nD09Ki2IHgRQx3tv/0htwR4Y3v1AarzPsOXz3f r/S3W1MOxrThuzWea7IFY+bqpoYO9VZkpbMQ+bJLLJCbXoKkusTjLfix4ulAJK8jsF+d rbA8eVHJAToGN1/oRBlR+wXpBLTR+TwxM32bU= Received: by 10.204.55.140 with SMTP id u12mr1620648bkg.155.1290148287862; Thu, 18 Nov 2010 22:31:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.49.208 with HTTP; Thu, 18 Nov 2010 22:30:47 -0800 (PST) In-Reply-To: <4CE52824.4050304@gmx.at> References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> <4CE52824.4050304@gmx.at> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?= Date: Fri, 19 Nov 2010 09:30:47 +0300 Message-ID: Subject: Re: bug#7368: display-buffer a softly dedicated window To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) I've checked out window-pub and played with it bit. Basically, everything worked great for me so far (note: I use default window options). Didn't notice any regressions. The problem with *Completions* is gone because in window-pub *Completions* is not dedicated :-) Also, I liked that many functions moved from C to Lisp (one can explore and tweak them much easier). As a temporary solution to the bug I now use the following code. It has some minor issues (i.e. if *Completions* is above code buffer, and I switch to interpreter, code buffer would come above and interpreter buffer would come below), but I can definitely live with it. However, proper upstream fix would still be very welcome. (defun my-display-buffer (buffer flag) (when (not (eq (buffer-name buffer) "*Completions*")) (let ((completions-window (get-buffer-window "*Completions*"))) (when completions-window (quit-window nil completions-window)))) (let (display-buffer-function) (display-buffer buffer flag))) (setq display-buffer-function 'my-display-buffer) Thanks for your support, Andrey Paramonov From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 12 22:07:38 2011 Received: (at 7368-done) by debbugs.gnu.org; 13 Jul 2011 02:07:39 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QgorS-00060L-Gp for submit@debbugs.gnu.org; Tue, 12 Jul 2011 22:07:38 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QgorQ-000608-Ef for 7368-done@debbugs.gnu.org; Tue, 12 Jul 2011 22:07:37 -0400 Received: from localhost ([127.0.0.1]:40083) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgorL-00008Q-48; Tue, 12 Jul 2011 22:07:31 -0400 From: Glenn Morris To: 7368-done@debbugs.gnu.org Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> <4CE52824.4050304@gmx.at> X-Spook: Gazprom enemy of the state S Box Vickie Weaver corporate X-Ran: Y%qc#1YR|}Q2xn3-g>{0/%)hpvA|oN$nkE0gt(D%XX&5Aw>1tr+BG};"~m0yeuZ/]S\h@o X-Hue: yellow X-Attribution: GM Date: Tue, 12 Jul 2011 22:07:30 -0400 In-Reply-To: (=?utf-8?B?ItCQ0L3QtNGA0LXQuSDQn9Cw0YDQsNC80L7QvdC+0LIiJ3M=?= message of "Fri, 19 Nov 2010 09:30:47 +0300") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.8 (----) X-Debbugs-Envelope-To: 7368-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.8 (----) Version: 24.1 > I've checked out window-pub and played with it bit. Basically, > everything worked great for me so far (note: I use default window > options). Didn't notice any regressions. Since this branch was merged to the trunk, I am assuming this report can now be closed. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 13 02:24:22 2011 Received: (at 7368) by debbugs.gnu.org; 13 Jul 2011 06:24:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qgsru-0004Be-0V for submit@debbugs.gnu.org; Wed, 13 Jul 2011 02:24:22 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Qgsrr-0004BS-Fk for 7368@debbugs.gnu.org; Wed, 13 Jul 2011 02:24:20 -0400 Received: (qmail invoked by alias); 13 Jul 2011 06:24:13 -0000 Received: from 62-47-45-92.adsl.highway.telekom.at (EHLO [62.47.45.92]) [62.47.45.92] by mail.gmx.net (mp055) with SMTP; 13 Jul 2011 08:24:13 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+o+PNSEL+oMAFVaM34fCzGildEkZ53KIXFwVNx0Q zsDIxJ6MqnR/q5 Message-ID: <4E1D3A0A.3060603@gmx.at> Date: Wed, 13 Jul 2011 08:24:10 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: 7368@debbugs.gnu.org, rgm@gnu.org Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> <4CE52824.4050304@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > Since this branch was merged to the trunk, I am assuming this report can > now be closed. So far only the routines in window.el have been merged. The calling routines are mostly the same, so this report is probably still valid. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 13 02:45:39 2011 Received: (at 7368) by debbugs.gnu.org; 13 Jul 2011 06:45:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QgtCV-0004go-Lp for submit@debbugs.gnu.org; Wed, 13 Jul 2011 02:45:39 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QgtCS-0004gb-Pa for 7368@debbugs.gnu.org; Wed, 13 Jul 2011 02:45:37 -0400 Received: from localhost ([127.0.0.1]:44776) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QgtCL-0003AQ-RR; Wed, 13 Jul 2011 02:45:30 -0400 From: Glenn Morris To: martin rudalics Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> <4CE52824.4050304@gmx.at> <4E1D3A0A.3060603@gmx.at> X-Spook: global industrial intelligence covert video FBI Lon X-Ran: 8a]DWbMQ5eLmr`k{cJ.KX{o/v2]\~l (martin rudalics's message of "Wed, 13 Jul 2011 08:24:10 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) martin rudalics wrote: >> Since this branch was merged to the trunk, I am assuming this report can >> now be closed. > > So far only the routines in window.el have been merged. The calling > routines are mostly the same, so this report is probably still valid. Do you plan to merge the rest of it, or ... ? From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 13 04:37:36 2011 Received: (at 7368) by debbugs.gnu.org; 13 Jul 2011 08:37:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qguwp-0008AG-Rc for submit@debbugs.gnu.org; Wed, 13 Jul 2011 04:37:36 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Qguwn-00089z-Hy for 7368@debbugs.gnu.org; Wed, 13 Jul 2011 04:37:34 -0400 Received: (qmail invoked by alias); 13 Jul 2011 08:37:27 -0000 Received: from 62-47-45-92.adsl.highway.telekom.at (EHLO [62.47.45.92]) [62.47.45.92] by mail.gmx.net (mp016) with SMTP; 13 Jul 2011 10:37:27 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1//Isp5Emv/hhID25HN9TH7C8umN88wg3BQMwfy/V P/0SaFTKIzJFXW Message-ID: <4E1D5945.7090601@gmx.at> Date: Wed, 13 Jul 2011 10:37:25 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glenn Morris Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> <4CE52824.4050304@gmx.at> <4E1D3A0A.3060603@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > Do you plan to merge the rest of it, or ... ? Sure. But the problems with *Completions* windows still represent a subject for further investigation as a recent thread here shows. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 13 12:07:45 2011 Received: (at 7368) by debbugs.gnu.org; 13 Jul 2011 16:07:46 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh1yT-000219-H9 for submit@debbugs.gnu.org; Wed, 13 Jul 2011 12:07:45 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh1yR-00020x-FM for 7368@debbugs.gnu.org; Wed, 13 Jul 2011 12:07:43 -0400 Received: from localhost ([127.0.0.1]:50140) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qh1yL-0003x6-PQ; Wed, 13 Jul 2011 12:07:37 -0400 From: Glenn Morris To: martin rudalics Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> <4CE52824.4050304@gmx.at> <4E1D3A0A.3060603@gmx.at> <4E1D5945.7090601@gmx.at> X-Spook: Mahmoud Ahmadinejad ANC M-14 quarter codes Indigo anarchy X-Ran: |wNf5DwCqA@zDmt!MC,`5=jxEPn1zqFbko19US8|gCyjTePmP5/(&%*yPIq@qAP^lbB`Gc X-Hue: blue X-Debbugs-No-Ack: yes X-Attribution: GM Date: Wed, 13 Jul 2011 12:07:37 -0400 In-Reply-To: <4E1D5945.7090601@gmx.at> (martin rudalics's message of "Wed, 13 Jul 2011 10:37:25 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 7368 Cc: 7368@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) martin rudalics wrote: >> Do you plan to merge the rest of it, or ... ? > > Sure. But the problems with *Completions* windows still represent a > subject for further investigation as a recent thread here shows. OK, then I misunderstood and will reopen this. From unknown Sat Sep 13 11:13:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug No longer marked as fixed in versions 24.1 and reopened. Date: Wed, 13 Jul 2011 16:10:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug No longer marked as fixed in versions 24.1 and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 25 05:55:33 2014 Received: (at 7368-done) by debbugs.gnu.org; 25 Dec 2014 10:55:33 +0000 Received: from localhost ([127.0.0.1]:56945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y464r-0000Qw-EK for submit@debbugs.gnu.org; Thu, 25 Dec 2014 05:55:33 -0500 Received: from mout.gmx.net ([212.227.15.15]:60758) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y464o-0000Ql-S2 for 7368-done@debbugs.gnu.org; Thu, 25 Dec 2014 05:55:31 -0500 Received: from [88.117.118.144] ([88.117.118.144]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MgKUo-1YHnCd09Ti-00Ni5W; Thu, 25 Dec 2014 11:55:25 +0100 Message-ID: <549BED14.3000807@gmx.at> Date: Thu, 25 Dec 2014 11:55:16 +0100 From: martin rudalics MIME-Version: 1.0 To: Glenn Morris Subject: Re: bug#7368: display-buffer a softly dedicated window References: <4CE3A46C.6080605@gmx.at> <4CE3E3C4.6060201@gmx.at> <4CE40D45.8080004@gmx.at> <4CE4DDD8.8000105@gmx.at> <4CE4ECEA.8030602@gmx.at> <4CE4FF80.4080404@gmx.at> <4CE52824.4050304@gmx.at> <4E1D3A0A.3060603@gmx.at> <4E1D5945.7090601@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:F3fp6WASgF8rPWSM5QYMGrRAr+h93n8YBpZwPrH/uJ5TZcvk47H p0TeL9AKeOa/07TEW/Xjw6OTvKiQIE0MhrBW8o9avLC/Z2I6rQgzNZ3+gjiDsOinHuB0TmE dyyJM8FdXL8I7xGAxgdOo3C+hnM0F/kyd6p0QhsqAdBkIDP4SzoxbyKJyOFUbovnQ9rqCKX K49jv+vtk5HZPifONuX4g== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 7368-done Cc: 7368-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> Sure. But the problems with *Completions* windows still represent a >> subject for further investigation as a recent thread here shows. > > OK, then I misunderstood and will reopen this. The more recent changes to displaying the *Completions* window should have made this report at least completely out-dated so I'm closing it. martin From unknown Sat Sep 13 11:13:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 22 Jan 2015 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator