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 07:13:32 -0700 Message-ID: <804C0F1267E447EE983B0C90E01F1573@us.oracle.com> References: <4BFEAAE6.60301@gmx.at> <4BFF8A9C.8060700@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 1275056862 12819 80.91.229.12 (28 May 2010 14:27:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 28 May 2010 14:27:42 +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 16:27:39 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 1OI0XC-00080E-Ab for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 May 2010 16:27:38 +0200 Original-Received: from localhost ([127.0.0.1]:59957 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OI0XB-0005rT-Kk for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 May 2010 10:27:37 -0400 Original-Received: from [140.186.70.92] (port=41853 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OI0X3-0005qm-Rd for bug-gnu-emacs@gnu.org; Fri, 28 May 2010 10:27:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OI0X2-0000WI-CR for bug-gnu-emacs@gnu.org; Fri, 28 May 2010 10:27:29 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59617) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OI0X2-0000W5-9E for bug-gnu-emacs@gnu.org; Fri, 28 May 2010 10:27:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OI0K2-00072l-DW; Fri, 28 May 2010 10:14: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 14:14:02 +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.127505602827069 (code B ref 6280); Fri, 28 May 2010 14:14:02 +0000 Original-Received: (at 6280) by debbugs.gnu.org; 28 May 2010 14:13:48 +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 1OI0Jn-00072Y-HO for submit@debbugs.gnu.org; Fri, 28 May 2010 10:13:48 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OI0Jk-00072T-Vq for 6280@debbugs.gnu.org; Fri, 28 May 2010 10:13:45 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SEDa1T012122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 May 2010 14:13:38 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4SBIHET014109; Fri, 28 May 2010 14:13:33 GMT Original-Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 305960301275056001; Fri, 28 May 2010 07:13:21 -0700 Original-Received: from dradamslap1 (/141.144.64.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 May 2010 07:13:21 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BFF8A9C.8060700@gmx.at> Thread-Index: Acr+Rt/Wst8LToxaSoa46RnxLu43PwAH9fjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090206.4BFFCF93.00ED:SCFMA4539811,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 10:14: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:37365 Archived-At: > >> Should users really control the dedicatedness of individual > >> windows? ECB, for example, uses a quite sophisticated > >> approach to control which buffers can be displayed in which windows. > > > BTW, why do you specify "individual" windows here? Did you > > mean something special by that? > > ECB dedicates windows to compiler output, system messages, file lists, > tags, bookmarks ... These are windows grouped around an undedicated > edit area and ECB takes care or assigning buffers to the dedicated > windows. ECB doesn't support dedicating "individual" windows > within the editor area. I see. The OP asks how to dedicate windows for the buffers that are in some mode. You reply that ECB controls which buffers/windows go where and with which properties (including special/dedicated). So I guess you are trying to point out a conflict that can arise: in _some_ cases an application might override a user's directive to make some window dedicated. Is that your point? If so: 1. That's a far cry from claiming that (or asking whether) users are not (or should never) be able to dedicate windows. Users _can_ dedicate windows, even if an app can override that. And that simple user task needs to be better documented. That is the point of this bug report. 2. There is no real difference between a user and an app. What ECB can do a user can do, and vice versa. An Emacs "user" can use Lisp (even C) code to do anything an Emacs library can do. Users _and_ apps can dedicate windows, even if another app or the user can override that. So saying that a user might try to dedicate a resource but ECB might override or prevent that is really no different from saying that the first guy or the last guy wins when executing code. X does (setq foo 13), but then Y does (setq foo 42). The important point here is not the subtlety that what a user tries to get s?he might not always get. The important point - the point of the bug, is that a fairly common user task is not adequately documented. If you want to _also_ add more doc somewhere that clarifies subtleties you are interested in, go for it. But first things first. > > The OP wants to dedicate all windows for buffers in a certain > > mode. > > Suppose you are in a help buffer and want to follow a cross > reference to an Elisp source code buffer. IIRC this usually > calls `pop-to-buffer'. Now should this action allow `display-buffer' > to "steal" a window showing another Elisp buffer? Not sure how that is relevant. Perhaps you are repeating your point above. Unlike you, I am not trying to redesign Emacs in a bug thread. This bug is about better documenting for users the _existing_ feature that you _can_ dedicate a window to a buffer. That's not sufficiently clear in the doc. Please do not confuse your personal interests and knowledge about this topic with those of a newbie user. This is not about you or how to best design the complex interaction of various possibly conflicting directives to Emacs to display buffers in windows. This is about conveying the simple knowledge that most non-newbies have about dedicated windows to newbies. > > * To dedicate all windows, can't you just > > set `special-display-regexps' to include ".*"? > > * To dedicate all windows for buffers in a mode, can't you just > > add ".*" to `special-display-regexps' on the mode hook and > > make the var buffer-local? > > > > Those both seem to work OK. If you customize > > `emacs-lisp-mode-hook' to add this function, doesn't it DTRT for you? > > > > (lambda () > > (make-local-variable 'special-display-regexps) > > (add-to-list 'special-display-regexps ".*")) > > I completely fail to understand how `special-display-regexps' would > enter here and how it could be used for the OP's purposes. Does it not do what the OP requested, when you try it? Does it not dedicate the windows for buffers that are in `emacs-lisp-mode'? Do you "_completely_ fail to understand" that it does what the OP asked? Can you create a scenario where it might not work because of some other, interfering code that has been invoked? No doubt. But that's not the point. A travel brochure for Haapadapafoo might say "Don't forget to bring your swimsuit, to enjoy our pristine beaches!", even though it might be the case that when _you_ happen to visit Haapadapafoo there is an oil spill or a hurricane. Let's get the simple travel brochure written first, telling potential visitors what Haapadapafoo generally has to offer (there _is_ a beach there!). You can write your thesis about hurricane frequency afterward. It will make a lovely appendix to the brochure and a welcome caveat for naive tourists expecting guaranteed sunshine. > Also, making `special-display-regexps' buffer-local doesn't > make sense to me. At the time `display-buffer' is called > _any_ buffer may be current. So what? Provided that the function that makes the variable local is called when the correct buffer is current, the variable is made buffer-local in the buffer in question, i.e. in a buffer in the OP's mode. Whether that is the right function to use and the hook is run at the proper time is another question. I think it is, but even if I'm mistaken about that, the point is that you _can_ make `special-display-regexps' local for a buffer that's in the mode you want, and doing that will make buffers in that mode display in dedicated windows. I do not claim that the function I gave is the right one to document. The point is that we should document this simple user task - tell users that they _can_ do it and, if simple, show them _how_ to do it. > Maybe Stefan can tell us more. I suppose he's the only one using > (weakly) dedicated windows in some organized way. Fine. But please keep in mind the aim of the bug report and, more importantly, the OP's aim. He wants to have the buffers in mode X use dedicated windows. Whether that is (a) desirable and (b) possible in _all_ circumstances is another question. If not, the doc can mention that. If there are important caveats that users should be aware of, we can mention them. But the point of the bug is that this basic info - letting users know about dedicated windows and how they might get the effect desired (at least in most cases) - that doc is missing/inadequate. This is not the place to redesign Emacs. If you feel it is important to add more to the doc to specify nuances, by all means, propose such an addition. But please do not try to make the perfect into the enemy of the good. First, let's give users the basic info they need to do what they want. When that's done, you can add your thesis about cases where subtle or unexpected interactions might take place.