From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Tue, 02 Aug 2011 16:26:32 +0200 Message-ID: <4E380918.3060806@gmx.at> References: <87mxgem09k.fsf@stupidchicken.com> <4E22AE2B.5040806@gmx.at> <4E248102.6080904@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312295223 24580 80.91.229.12 (2 Aug 2011 14:27:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2011 14:27:03 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 16:26:49 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QoFvk-0003vy-G4 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 16:26:48 +0200 Original-Received: from localhost ([::1]:48275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoFvj-0007oc-V8 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 10:26:47 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoFvf-0007oA-Nw for emacs-devel@gnu.org; Tue, 02 Aug 2011 10:26:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoFvZ-0007a3-C0 for emacs-devel@gnu.org; Tue, 02 Aug 2011 10:26:43 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:60898) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QoFvY-0007Z3-SV for emacs-devel@gnu.org; Tue, 02 Aug 2011 10:26:37 -0400 Original-Received: (qmail invoked by alias); 02 Aug 2011 14:26:35 -0000 Original-Received: from 62-47-54-84.adsl.highway.telekom.at (EHLO [62.47.54.84]) [62.47.54.84] by mail.gmx.net (mp007) with SMTP; 02 Aug 2011 16:26:35 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+BoU1o9muBDY85F0FTTFNVsfpyXzCb1OWC4nP3zu cKuuJ2UNL7SN6c User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 213.165.64.23 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142700 Archived-At: >>> We can combine them with a "a\\|b\\|c" regexp. >> I wonder whether users who don't know much about regexps would like such >> a thing but it can be obviously done. > > If they're afraid of regexp, they'll run away screaming from > display-buffer-alist (and probably from Emacs as well). So I'm not > too concerned. Have you ever tried the customization interface of `display-buffer-alist'? What's so frightening about it? >>> I don't even know why you added the `label' case, so I don't think we >>> should worry about adding more types. >> The label case would specify the calling function so users can change >> the behavior if the name of the buffer is not distinctive enough. It >> can be easily removed if people think it's not needed. > > I can guess that from its "definition" but that doesn't tell me why you > considered it was worth adding. When labels were discussed on emacs-devel you wrote: I might want that, indeed, but what I wrote above is not directly related, it's just that if ediff uses symbols `ediff-A' and `ediff-B', I might like to be able to have a single entry that covers both (and covers the ediff-ancestor one as well). That would naturally extend to a more general form of classification of buffers (e.g. `ediff' for all things related to ediff... I'd probably also like to be able to use a major-mode name as a classification). If you meant something different than what I implemented you should tell me (1) what you meant then and (2) how you wanted that implemented. If all you meant in that text was to _not_ provide labels you should simply have said so then. > That's really what I'm generally > asking: a rationale document/comment that explains for each feature why > it was added (with concrete use cases). Without it, it's difficult for > me to understand why we have so much complexity here. Have you ever looked into the Elisp manual of the window-pub branch? If not, please take a look there and tell me what is missing. It's difficult to adapt a manual text to constantly changing design requests. > BTW, rather than select based on a `label' may we should make it > possible for the user to set parameters that depend on the caller's > params, and/or on the place where the buffer gets displayed (whether it's > reusing a window, using a new frame, ... which of course could only > apply to params that do not influence which window to use). The current trend intitiated by Chong aims at reducing expressiveness. How do you want me to reconcile your proposal with this trend? >> I don't know how many times I went through the code of >> `special-display-buffer-names' but I know that I still don't >> understand it. > > Yup, and your code is even more complex. Let's agree to disagree on that. `special-display-buffer-names' had only one serious user, namely Drew Adams. I know that because my rewrite had a number of bugs which we eliminated in a period of two weeks mostly by trial and error. In all that time no one else complained. I suppose you use it as well but since you apparently advice `display-buffer' (or some subset of its routines) you were not hit by these bugs. `special-display-buffer-names' is complex because it prescribes behavior for reusing the same window, reusing some other window on the same frame, popping up a new window, reusing a window on another frame and popping up a new frame. That's the kind of expressiveness Drew needs because he's got no other choice. It's far too expressive for all other users. >> Admittedly, atomic windows and side windows provide some considerable >> additional complexity but there have been frequent requests that putting >> a buffer into a window should practically always pass through >> `display-buffer'. > > I don't know what are atomic windows, nor side windows. I don't know > when they might be used either, nor where they've been requested. > And neither do I know why they should be introduced by display-buffer. > So, as explained above (and in my previous email), I need a rationale > giving concrete usage example for each such feature, without which this > all seems way too complex. Atomic windows were discussed in a thread on how to implement tabs in a separate window since you were opposed to using the headerline for them. Side windows are a first step in solving the problem of how to implement IDE like window configurations without having to advise basic functions like `delete-other-windows'. Both are described in separate sections of the manual in the window-pub branch. >> There have been requests that `display-buffer' should be able to set the >> size of a popped-up window and optionally specify a function to set the >> height by calling a function like `fit-window-to-buffer'. These can be >> easily removed and we get a doc-string that is 35 line shorter. So >> we've got plenty of room for down-engineering `display-buffer-alist'. >> Just tell me what you want to remove. > > I can't tell you that without first knowing what each thing is used for. So either you read the manual from window-pub or you have to wait until I rewrote the manual for the trunk and we continue the discussion from there. > BTW, I also agree with Jury that display-buffer-alist's default value > should be nil, to make it easier to change the default behavior (which > is hence kept elsewhere) in the future. It is nil for a couple of weeks now. >> The question whether and how to merge such a specifier is central to the >> question whether we should change the semantics of the not-this-window >> argument of `display-buffer' at all. > > I think some form of merging is indispensable, but the rule should be > simple. I don't know in which way the needs of merging influence the > current design, so again I can't judge the current design without first > some kind of explanation showing use cases, the problems they introduce > and the solution(s) you provide. The rule is simple. You scan a list of expressions until you find the first method specifier that delivers a result. You scan the tail of the list for the first additional specifier that is needed for implementing a specific behavior like evening window sizes and use it. >> Since most people do find `display-buffer-alist' much too complicated >> and Stefan is apparently opposed to almost all new features it provides, > > That's a misunderstanding. I only have a gut-feeling that we can > provide the same features (or even more features) with a simpler design, > and furthermore I can't intuitively see how you got to the current > design, so I'd like to pick your brain to understand your motivations. > The end result may very well be "Aha! Yes, your design makes a lot of > sense!". I'd immediately jump at any suggestion that is compatible with Emacs 23 options. Unfortunately, till now the discussion didn't get us very far because I didn't get satisfactoy answers on how to stay compatible with the behavior of Emacs 23. >> Another difference is that in default-frame-alist, each stored value >> (i.e. the cdrs of an alist entry) has a straightforward meaning: it is a >> value of a frame parameter. In display-buffer-alist, each stored value >> is a _list_ of specifiers, and each specifier has its own no-obvious >> meaning. For example, in the specifier > > Indeed. To me that's one of the reasons why I think > display-buffer-alist needs to be improved: each param should be as > clear, simple, and independent as is the case for frame params. > Ideally that is: before deciding it's actually true, I need to understand > why it's not already the case. Making a frame either succeeds or fails in one attempt. But when one method for displaying a buffer fails, another one must be tried ... martin