Re: display-buffer-alist simplifications

[John Yates]

On Mon, Aug 8, 2011 at 8:26 AM, martin rudalics <address@hidden> wrote:
>
> With the scheme sketched above users have no chance to specify what they
> want when they want to use the new design _and_ respect the application
> specifiers.  When they set the new specifiers they would override the
> application.

In recent months face themes have gained significant moment.  This has
been facilitated by the communities' adoption of a limited number of
common faces along with increased consistency in the way that
supported modes use and inherit from those faces.

The problem of customizing buffer display details does not seem to be
nearly as far along.  This is evidenced by the fact that a user
specifies his display rules in terms of buffer names.  That in turn
requires the user to intuit a naming pattern, to hope that all mode
(including those not yet explored) hew to that naming pattern, and to
pray that modes defining buffers matching a given pattern all request
buffer display consistently.  This makes trying to achieve consistent
display behavior across multiple modes feel ad hoc, analogous to
attempting to tame "angry fruit salad".  This is especially true when
trying out a mode that one has not used before.

An alternative might be to identify explicitly a limited number of
buffer display protocols:
- transient selection list
- persistent control panel
- etc

Continuing with the face analogy, such buffer display protocols could
easily include a notion of inheritance.

Displaying a buffer would require subscribing to display a protocol.
(Subscribing to a particular protocol likely would impose additional
requirements / constraints.)  User customization could then be
associated with protocols instead of buffer names.

While a big change from the current gestalt I think that such a scheme
could feel significantly less ad hoc and might be easier for
unsophisticated end users to master.

/john