[Top][All Lists]

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

Re: display-buffer-alist simplifications

From: Chong Yidong
Subject: Re: display-buffer-alist simplifications
Date: Sat, 23 Jul 2011 15:26:25 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

martin rudalics <address@hidden> writes:

> This has the disadvantage that Lisp users would have to set the value
> of every specifier like even-sizes unless it's nil.  In practice, this
> means that you have to repeat the values of min-height and min-width
> for pop-up-windows and the value of pop-up-frame-alist for each and
> every entry that wants to use them.

This is not important.  If this is an issue, it would be cleaner to use
global variables to specify defaults.

> The major problem with this approach, however, is an inconsistency
> when handling specifiers passed by the application.  Currently, these
> specifiers are merged into the user's specifiers.  Suppose I write
> (setq
>  display-buffer-alist
>  '((((regexp . ".*"))
>     (reuse-window nil same)
>     (reuse-window-even-sizes . t))))
> (display-buffer "*scratch*" '((reuse-window other)))
> then the `display-buffer' call does even window sizes because it's
> specified in `display-buffer-alist'.  What would you propose here?

IIUC, the current system also has a limitation: there is no way to use
display-buffer-alist to tell Emacs to apply even-sizes selectively,
e.g. only when reusing a window already containing the buffer.

I think this indicates that the idea of "merging" specifiers is flawed.
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.

Why not let display-buffer-alist exclusively perform the "override"
case---i.e. let it take precedence over display-buffer's argument

As for the "merge" functionality, some of it is already handled using
global variables, like `even-window-heights'.  In the future, we could
provide a more versatile way to do merging (e.g.  provide an abnormal
hook that accepts the display specifier that Emacs is told to use, and
return a modified specifier for it to actually use).  But I think we can
defer that part to post-24.1.

reply via email to

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