display-buffer-alist simplifications - gmane.emacs.devel

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
gmane.emacs.devel
Message from discussion display-buffer-alist simplifications
From: Juanma Barranquero <lek...@gmail.com>
Newsgroups: gmane.emacs.devel
Subject: Re: display-buffer-alist simplifications
Date: Sun, 17 Jul 2011 03:38:30 +0200
Lines: 67
Approved: n...@gmane.org
Message-ID: <CAAeL0STNY8NRFuVT=-G6ezAvxJvM5Lk25rmFEspckCPix-8iww@mail.gmail.com>
References: <87mxgem09k.fsf@stupidchicken.com>
NNTP-Posting-Host: lo.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
NNTP-Posting-Date: Sun, 17 Jul 2011 01:39:35 +0000 (UTC)
Cc: Martin Rudalics <rudal...@gmx.at>, emacs-de...@gnu.org
To: Chong Yidong <c...@stupidchicken.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane....@gnu.org Sun Jul 17 03:39:31 2011
Envelope-to: ged-emacs-de...@m.gmane.org
Original-Received: from lists.gnu.org ([140.186.70.17])
	by lo.gmane.org with esmtp (Exim 4.69)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane....@gnu.org>)
	id 1QiGKQ-0000Es-Pe
	for ged-emacs-de...@m.gmane.org; Sun, 17 Jul 2011 03:39:30 +0200
Original-Received: from localhost ([::1]:47349 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane....@gnu.org>)
	id 1QiGKP-0001uv-LM
	for ged-emacs-de...@m.gmane.org; Sat, 16 Jul 2011 21:39:29 -0400
Original-Received: from eggs.gnu.org ([140.186.70.92]:39304)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lek...@gmail.com>) id 1QiGK8-0001ui-Fv
	for emacs-de...@gnu.org; Sat, 16 Jul 2011 21:39:13 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lek...@gmail.com>) id 1QiGK7-0003x3-HL
	for emacs-de...@gnu.org; Sat, 16 Jul 2011 21:39:12 -0400
Original-Received: from mail-pv0-f169.google.com ([74.125.83.169]:45502)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lek...@gmail.com>) id 1QiGK7-0003wy-8d
	for emacs-de...@gnu.org; Sat, 16 Jul 2011 21:39:11 -0400
Original-Received: by pvc12 with SMTP id 12so2563735pvc.0
	for <emacs-de...@gnu.org>; Sat, 16 Jul 2011 18:39:10 -0700 (PDT)
Original-Received: by 10.143.90.14 with SMTP id s14mr2417259wfl.138.1310866750243; Sat,
	16 Jul 2011 18:39:10 -0700 (PDT)
Original-Received: by 10.142.144.4 with HTTP; Sat, 16 Jul 2011 18:38:30 -0700 (PDT)
In-Reply-To: <87mxgem09k....@stupidchicken.com>
Precedence: list
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane....@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane....@gnu.org
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/142057>
Path: g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.erje.net!nntp.club.cc.cmu.edu!news.mccarragher.com!news.gmane.org!not-for-mail

On Sat, Jul 16, 2011 at 22:35, Chong Yidong <c...@stupidchicken.com> wrote:

> Here are several suggestions, and one question.

From someone who has read the docstring of `display-buffer-alist' once
too many and gleaned way too little meaning from it (no offense,
Martin, I love your work, just not this variable's doc)...

> =C2=A0- Instead of allowing the car of each `display-buffer-alist' elemen=
t to
> =C2=A0 be a _list_ of matchers, let it just be a matcher. =C2=A0This is
> =C2=A0 semantically cleaner, and more consistent with other facilities in
> =C2=A0 Emacs, e.g. font-lock-keywords. =C2=A0Any caller desiring multiple
> =C2=A0 matching conditions can just add multiple alist elements.

Well, perhaps. No biggie IMHO.

> =C2=A0- Instead of buffer matchers that are cons cells like (name . NAME)=
,
> =C2=A0 (regexp . REGEXP), and (label . LABEL), just use strings or symbol=
s.
> =C2=A0 Strings are to be treated as regexps (if an exact match is desired=
,
> =C2=A0 the caller uses regexp-quote); symbols are treated as label matche=
rs.

Yes, though the `name' case is perhaps common and it's a bit of a PITA
having to go through `regexp-quote'.

> =C2=A0- Some of the display specifiers seem to allow contradictory meanin=
gs,
> =C2=A0 e.g.
>
> =C2=A0 =C2=A0 =C2=A0(reuse-window same nil other)
>
> =C2=A0 means to reuse the selected window, provided the window is not on =
the
> =C2=A0 selected frame. =C2=A0What does this mean? =C2=A0And what happens =
if it's
> =C2=A0 impossible for Emacs to meet the requirements of the specifier? =
=C2=A0This
> =C2=A0 is not explained in the docstring.

Yes!

> =C2=A0- I don't like the fact that different specifiers are set up in a w=
ay
> =C2=A0 that the meaning of each specifier depends on the presence of othe=
r
> =C2=A0 specifiers. =C2=A0For example, in the spec list
>
> =C2=A0 ((reuse-window same nil nil) (reuse-window-even-sizes . t))
>
> =C2=A0 the second element only has a meaning if the first element is
> =C2=A0 present---they are not independent. =C2=A0It would be cleaner to u=
se a
> =C2=A0 plist, like this:
>
> =C2=A0 =C2=A0(reuse-window :window same :reuse-window-even-sizes t)
>
> =C2=A0 where ALL the behaviors are grouped together.

YES!!!

=C2=A0 =C2=A0 Juanma
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
