[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications

From: Stephen J. Turnbull
Subject: Re: display-buffer-alist simplifications
Date: Tue, 26 Jul 2011 10:15:54 +0900

Juri Linkov writes:

 > > 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.

The behavior (by which I do *not* mean any behavior that anybody has
so far specified, but the *union* of all behaviors that users want)
*is* *very* complicated.  +1 for accepting that as a fact and getting
on with the business of learning (as a project, though hopefully
within a few months individual users and even many developers can
mostly just accept the defaults) to use Martin's specifiers.

Note that XEmacs has had specifiers (in a somewhat different sense,
but the basic idea of a more or less hierarchical mapping from
contexts to instances is the same) for literally decades, they are
automatically merged, and with the exception of David Kastrup (a
self-proclaimed Simple Mind From the City of Light :-), nobody has
really complained about their complexity and merging generally DTRTs.
Rather users and third-party developers have asked how to accomplish
what they want to do, and generally are pleased with the results they
get.  Specifiers are one thing that nobody in the SXEmacs fork has
suggested getting rid of, by the way.

Since XEmacs specifiers are *not* used to configure buffer to window
mapping, I can't promise that Martin's design will be as successful in
this application, but I think it's very much worth a try.

BTW, designing defaults is IMHO basically impossible.  It's much more
profitable (at least, if the architect is as available and responsive
as Martin has been) to make the basic design as flexible as possible,
start with the architect's preferences as default, and tweak, with the
ongoing advice of the architect on how-to.  Again, I think that it's
probably a good idea to accept that the defaults for Emacs 24 will be
way suboptimal (except in Martin's personal opinion :-), and aim for
good defaults in 24.1 *after* a wide variety of users who usually just
lurk on emacs-devel have had their say.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]