From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#6280: 24.0.50; (elisp) Dedicated Windows Date: Fri, 28 May 2010 09:16:14 -0700 Message-ID: <0C40D97636E64B6D82C3D37C28F54878@us.oracle.com> References: <4BFEAAE6.60301@gmx.at> <4BFF8A9C.8060700@gmx.at> <804C0F1267E447EE983B0C90E01F1573@us.oracle.com> <4BFFDCD5.90706@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1275064064 9761 80.91.229.12 (28 May 2010 16:27:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 28 May 2010 16:27:44 +0000 (UTC) Cc: 'Stefan Monnier' , 6280@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 28 18:27:42 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OI2PK-0003Lo-7N for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 May 2010 18:27:38 +0200 Original-Received: from localhost ([127.0.0.1]:38193 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OI2PJ-0006lb-Jj for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 May 2010 12:27:37 -0400 Original-Received: from [140.186.70.92] (port=34976 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OI2PD-0006lV-Fm for bug-gnu-emacs@gnu.org; Fri, 28 May 2010 12:27:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OI2PA-0005HU-Jm for bug-gnu-emacs@gnu.org; Fri, 28 May 2010 12:27:31 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37074) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OI2PA-0005HC-I3 for bug-gnu-emacs@gnu.org; Fri, 28 May 2010 12:27:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OI2F4-0007xT-0R; Fri, 28 May 2010 12:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 May 2010 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6280 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6280-submit@debbugs.gnu.org id=B6280.127506340430582 (code B ref 6280); Fri, 28 May 2010 16:17:01 +0000 Original-Received: (at 6280) by debbugs.gnu.org; 28 May 2010 16:16:44 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OI2El-0007xD-Hf for submit@debbugs.gnu.org; Fri, 28 May 2010 12:16:43 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OI2Ei-0007x7-Sa for 6280@debbugs.gnu.org; Fri, 28 May 2010 12:16:41 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SGGToI005315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 May 2010 16:16:33 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SGGQSa025900; Fri, 28 May 2010 16:16:26 GMT Original-Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 277780161275063363; Fri, 28 May 2010 09:16:03 -0700 Original-Received: from dradamslap1 (/141.144.64.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 May 2010 09:16:02 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BFFDCD5.90706@gmx.at> Thread-Index: Acr+d+Kd5fre4duxTMCAEzPm9n3fugAAnX5g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090205.4BFFEC62.00FD:SCFMA922111,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 28 May 2010 12:17:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:37368 Archived-At: Martin, you are trying to take this bug report far afield. I won't bother to get into it with you. I was clear about what is needed for the doc about this topic: 1. Put something in the Emacs manual about how to make windows dedicated. 2. In the Elisp manual, mention `special-display' buffers in node `Dedicated Windows'. See the original bug report for details. When you say things like this, you seem to be playing provocateur: > Suppose I have a window showing a buffer in `emacs-lisp-mode' and I > split that window. Then the new window obviosuly should be > dedicated to that buffer as well. I fail to understand how you achieve that. My value of `special-display-regexps' is ("[ ]?[*][^*]+[*]"), so buffers named `*...*' are special. That means that most of the time they are in dedicated windows. Can I split a `*Help*' window or an `*Info*' window? Of course. Is each of the two windows dedicated to the buffer? No, only the first (original) one is. So what? Do you want to change all of the doc about special buffers, to make your point? The doc string of `special-display-regexps' is technically incorrect/incomplete, since it suggests that displaying such a buffer (with the default `special-display-function') gives it its own frame. Should we add a note here, there, and everywhere saying "Martin wants you to know that this is not strictly true in all cases. Here is the truth (fasten your seat belt and shoulder harness): ... [3 pages of details about the true relations between windows and buffers]"? [** - see below] This is all beside the point. What is important is that knowing about the existence of `special-display-regexps' I am able to have Emacs open such buffers in their own window and inhibit their replacement in that window. It is that knowledge that needs to be better communicated to users. That's all. You are up on your soap box and totally missing the point. It's about the doc. It's about new users. It's about making it more obvious that you can dedicate windows to buffers, that there is a notion of special buffer. This is not about the intricacies of special-buffer display. > I earlier mentioned how you can do what the OP wants. Write > a function that you _globally_ add to > `window-configuration-change-hook'. That function would have to > scan `window-list', check for each window whether > its buffer is in a mode that shall have dedicated windows, > and, if that is the case, call `set-window-dedicated-p' for that > window with some non-nil, non-t flag. If someone can come up > with a simpler solution I'll be all ears. Sigh. ---- ** Such a tendency is already underway. Compare the `special-display-regexps' doc strings for Emacs 20 and 23, below. Will the Emacs 26 doc string read only like a legal disclaimer? Don't get me wrong. The reference doc should be complete and correct. But doc should also help you to see the forest, not just become lost in the forest litter. 20: List of regexps saying which buffers should have their own special frames. If a buffer name matches one of these regexps, it gets its own frame. Displaying a buffer whose name is in this list makes a special frame for it using `special-display-function'. An element of the list can be a list instead of just a string. There are two ways to use a list as an element: (REGEXP FRAME-PARAMETERS...) (REGEXP FUNCTION OTHER-ARGS...) In the first case, FRAME-PARAMETERS are used to create the frame. In the latter case, FUNCTION is called with the buffer as first argument, followed by OTHER-ARGS--it can display the buffer in any way it likes. All this is done by the function found in `special-display-function'. If this variable appears "not to work", because you add a regexp to it but the matching buffers still appear in the selected window, look at the values of `same-window-buffer-names' and `same-window-regexps'. Those variables take precedence over this one. 23: List of regexps saying which buffers should be displayed specially. Displaying a buffer with `display-buffer' or `pop-to-buffer', if any regexp in this list matches its name, displays it specially using `special-display-function'. `special-display-popup-frame' (the default for `special-display-function') usually displays the buffer in a separate frame made with the parameters specified by `special-display-frame-alist'. If `special-display-function' has been set to some other function, that function is called with the buffer as first, and nil as second argument. Alternatively, an element of this list can be specified as (REGEXP FRAME-PARAMETERS), where REGEXP is a regexp as above and FRAME-PARAMETERS an alist of (PARAMETER . VALUE) pairs. `special-display-popup-frame' will then interpret these pairs as frame parameters when creating a special frame for a buffer whose name matches REGEXP, overriding the corresponding values from `special-display-frame-alist'. As a special case, if FRAME-PARAMETERS contains (same-window . t) `special-display-popup-frame' displays buffers matching REGEXP in the selected window. (same-frame . t) in FRAME-PARAMETERS means to display such buffers in a window on the selected frame. If `special-display-function' specifies some other function than `special-display-popup-frame', that function is called with the buffer whose name matched REGEXP as first, and FRAME-PARAMETERS as second argument. Finally, an element of this list can be also specified as (REGEXP FUNCTION OTHER-ARGS). `special-display-popup-frame' will then call FUNCTION with the buffer whose name matched REGEXP as first, and OTHER-ARGS as second argument. If `special-display-function' specifies some other function, that function is called with the buffer whose name matched REGEXP as first, and the element's cdr as second argument. If this variable appears "not to work", because you added a name to it but the corresponding buffer is displayed in the selected window, look at the values of `same-window-buffer-names' and `same-window-regexps'. Those variables take precedence over this one. See also `special-display-buffer-names'.