Re: display-buffer-alist simplifications

[martin rudalics <rudalics@gmx.at>]

 > In the mean time I thought of 2 more:
 > - all the args to the display methods are in the ALIST rather than
 >   having some in the ALIST and some bundled with the display method.
 > - the display method has to handle everything, there's no common/shared
 >   postprocessing.

Using a more operational reasoning I see the differences as follows:

After "normalizing" specifiers (stripping buffer identifers and
expanding "macro specifiers") my specifiers boil down to an alist of say
methods (M) and parameters (P) like

((M ...) (P ...) (P ...) (M ...) (M ...) (P ...) (M ...) (P ...) (P ...))

This alist was produced by concatening the overriding (O), application
provided (A), and non-overriding specifiers (N, where this group
contains in its tail the specifiers produced by the old buffer display
options) as indicated below

((M ...) (P ...) (P ...) (M ...) (M ...) (P ...) (M ...) (P ...) (P ...))
  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN

This alist is processed by taking the first method specifier and
handling _all_ following parameters just like frame alists - the first
parameter value that is found is taken.  If the first method fails, the
next method is tried as

((M ...) (M ...) (P ...) (M ...) (P ...) (P ...))
  OOOOOOO AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN

then the next method as

((M ...) (P ...) (M ...) (P ...) (P ...))
  AAAAAAAAAAAAAAA NNNNNNNNNNNNNNNNNNNNNNN

and if everything failed till here the last method as

((M ...) (P ...) (P ...))
  NNNNNNNNNNNNNNNNNNNNNNN


The other proposals I have seen here ask for using something I would
describe as a list of alists like

(((M ...) (P ...) (P ...) (P ...))
  ((M ...) (P ...))
  ((M ...) (P ...) (P ...)))

where, if a method specifier matches, _only_ the parameters provided
together with that specifier are processed.  That means you process

((M ...) (P ...) (P ...) (P ...))

first, if that fails

((M ...) (P ...))

and finally

((M ...) (P ...) (P ...))


IIUC I've also seen

(((M ...) (M ...) (P ...) (P ...) (P ...))
  ((M ...) (M ...) (M ...) (P ...)))

such that two or more methods may share the same parameters, maybe also
written as

((((M ...) (M ...)) . ((P ...) (P ...) (P ...)))
  (((M ...) (M ...)) . ((M ...) (P ...))))


Also dismissing non-overriding specifiers and handling old buffer
display options (D) has been proposed like

(((M ...) (P ...) (P ...) (P ...))
  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
  ((M ...) (P ...))
  AAAAAAAAAAAAAAAAA
  ((M ...) (P ...) (P ...))
  DDDDDDDDDDDDDDDDDDDDDDDDD
)

where I'm still not able to see how to

(1) Respect the application _and_ supply user parameters.

(2) Respect the application _and_ supply parameters resulting from old
     user options.

both of which I've called merging here.


Finally, I've seen a very high priority application provided level of
specifiers (H) which would appear as

(((M ...) (P ...))
  HHHHHHHHHHHHHHHHH
  ((M ...) (P ...) (P ...) (P ...))
  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
  ((M ...) (P ...))
  AAAAAAAAAAAAAAAAA
  ((M ...) (P ...) (P ...))
  DDDDDDDDDDDDDDDDDDDDDDDDD
)


Does this approximately describe the current state of affairs?  I've
deliberately dismissed things I consider sugar like whether methods
represent functions or just symbols to look up functions, or whether a
parameter actually is a condition enabling a method (like a window's
minimum height) rather then ask for some kind of post-action (like
setting a window's height).

martin