From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Sun, 24 Jul 2011 09:54:34 -0400 Message-ID: <8739hvu6lh.fsf@stupidchicken.com> References: <87mxgem09k.fsf@stupidchicken.com> <4E2A7EBD.7050300@gmx.at> <87livooqt6.fsf@stupidchicken.com> <4E2B158B.1080101@gmx.at> <87wrf8iyse.fsf@stupidchicken.com> <4E2BEED2.5040608@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1311515688 19574 80.91.229.12 (24 Jul 2011 13:54:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2011 13:54:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 24 15:54:43 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 1Qkz8l-00073Q-6g for ged-emacs-devel@m.gmane.org; Sun, 24 Jul 2011 15:54:43 +0200 Original-Received: from localhost ([::1]:52804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qkz8k-0007LK-R1 for ged-emacs-devel@m.gmane.org; Sun, 24 Jul 2011 09:54:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qkz8h-0007LE-V4 for emacs-devel@gnu.org; Sun, 24 Jul 2011 09:54:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qkz8g-00056b-Te for emacs-devel@gnu.org; Sun, 24 Jul 2011 09:54:39 -0400 Original-Received: from vm-emlprdomr-03.its.yale.edu ([130.132.50.144]:54073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qkz8g-00056X-Qd for emacs-devel@gnu.org; Sun, 24 Jul 2011 09:54:38 -0400 Original-Received: from furball (c-76-28-93-216.hsd1.ct.comcast.net [76.28.93.216]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id p6ODsYo8012594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2011 09:54:35 -0400 In-Reply-To: <4E2BEED2.5040608@gmx.at> (martin rudalics's message of "Sun, 24 Jul 2011 12:07:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.144 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:142257 Archived-At: martin rudalics writes: > (setq > display-buffer-alist > '((((regexp . ".*")) > (reuse-window other same) > (reuse-window-even-sizes . t) > (reuse-window other other) > (reuse-window-even-sizes . nil)))) This is not clean. The specifiers interact with one another, and their ordering affects the behavior of other specifiers. Semantically it is even more complicated than font-lock-keywords---which isn't even user-customizable. >> display-buffer-alist is trying to serve two purposes: "merging" >> specifiers passed to display-buffer, and "overriding" them completely. >> That makes it very complicated to use/understand. > > Merging should be the rule. Overriding should happen only in a few > cases, when a user is completely dissatisfied with the application's > specifier. In practice, this means that we can either tell a user on > Emacs-devel something like "this should get fixed by the application > soon, meanwhile try to override this by ..." or "the behavior you want > is very unusual so could you please try overriding it by ...". Getting this to work right seems complicated. If you can provide a *specific* example of how you intend merging to work, maybe it will make it clearer for me. For example, suppose I want Emacs to (i) always avoid displaying in the current window first, even if the display-buffer specifier says so; (ii) when trying to reuse a window that already has the desired buffer on the current frame, also try looking in other frames at the same time; and (iii) if all other specifiers fail, fall back on using the current window. How is that done? >> Why not let display-buffer-alist exclusively perform the "override" >> case---i.e. let it take precedence over display-buffer's argument >> specifiers? > > Impossible. The first consequence of this would be applications > rebinding `display-buffer-alist' to nil around `display-buffer' calls. > How would you implement `info-other-window' or `find-file-other-frame' > when the user has a `display-buffer-alist' entry for *Info* or the file > in question? Isn't that what you introduced labels for?