From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Mon, 25 Jul 2011 14:15:11 +0300 Organization: JURTA Message-ID: <87mxg2fw74.fsf@mail.jurta.org> 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> <8739hvu6lh.fsf@stupidchicken.com> <4E2C50E6.3020103@gmx.at> <878vrnweju.fsf@stupidchicken.com> <4E2D34D7.4040002@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1311592939 5969 80.91.229.12 (25 Jul 2011 11:22:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2011 11:22:19 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 25 13:22:15 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 1QlJEh-00073D-P0 for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2011 13:22:11 +0200 Original-Received: from localhost ([::1]:41664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlJEe-0006dm-Uk for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2011 07:22:08 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlJEc-0006dW-E8 for emacs-devel@gnu.org; Mon, 25 Jul 2011 07:22:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlJEb-00056h-Fo for emacs-devel@gnu.org; Mon, 25 Jul 2011 07:22:06 -0400 Original-Received: from smarty.dreamhost.com ([208.113.175.8]:33247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlJEb-00056V-BN for emacs-devel@gnu.org; Mon, 25 Jul 2011 07:22:05 -0400 Original-Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 675F86E8051; Mon, 25 Jul 2011 04:22:03 -0700 (PDT) Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 5EA26451C07C; Mon, 25 Jul 2011 04:22:02 -0700 (PDT) In-Reply-To: <4E2D34D7.4040002@gmx.at> (martin rudalics's message of "Mon, 25 Jul 2011 11:18:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.113.175.8 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:142277 Archived-At: > martin, who begins feeling to weak to delve into this subject again. Having only one customizable variable to specify how to display a buffer is definitely a very good thing. One problem is that currently it's too complicated. I see the following ways to improve this situation. There are three levels where the window displaying behavior can be defined: 1. default behavior with good heuristics. It can be either hard-coded or defined in a defvar (or even defconst) with the current default value of `display-buffer-alist' (or the result of `display-buffer-alist-set'). 2. function-specific behavior can be defined by the arguments `specifiers' and `label' of `display-buffer' and override the default behavior. 3. user-specific behavior can override the function-specific behavior. It seems `display-buffer-alist' was intended to define that. But I think it should be separate from the definition of the default behavior and should not be merged with it. To help the users to customize the desired behavior we could allow to group a set of low-level specifiers into "themes". So e.g. for users who prefer using frames we could predefine a "frame theme" with a set of specifiers that affect displaying buffers in frames. Each group could be marked with a symbolic tag that can be used by the `specifiers' argument of `display-buffer', e.g.: (display-buffer "*Completions*" 'near-minibuffer) as well as in the user-customizable variable, e.g.: '(("*Completions*" below-selected) ("*info*" same-window)) And the value `t' could emulate the old behavior of the argument `not-this-window' in `display-buffer' for backward-compatibility. As for `labels' I expect very little use of them. Maybe we should allow specifying the command name (i.e. the value of `this-command') in `display-buffer-alist', e.g.: '((("*info*" . info-other-window) same-window))