Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > ..., let application pass a label along
>  > with the buffer.
>  >
>  > For example, ediff could label its buffers 'ediff-A and 'ediff-B,
>  > which would point to entries such as:
>  >
>  >  (setq display-buffer-names '(
>  >    ((ediff-A) <specifiers>)
>  >    ((ediff-B) <specifiers>)
>  >    ...
>  >  ))
>
> This is problematic in some respects:
>
> (1) ediff must not set `display-buffer-names' directly, it's a user
>     option.  So I would have to provide two additional shadow variables
>     and merge in their values in `display-buffer'.

I (you?) don't understand.

ediff would not set 'display-buffer-names'.

ediff merely does:
        (display-buffer "/tmp/foo(1).c" 'diff-A)
        (display-buffer "/tmp/foo(2).c" 'diff-B)

So the label is passed like a specifier, just that it works as
a pointer to an entry with specifiers.

The entry with specifiers is in `display-buffer-names' and it
is set by the user.

There are no "shadow variables".

However there are some pre-configured entries with specifiers
in `display-buffer-names'.

You have already pre-configured entries in `display-buffer-regexps'

> (2) I would have to decide what happens when different applications work
>     on, for example, groups of files with the same extension and want to
>     display the respective buffers in different locations of the screen.

application-foo does:
        (display-buffer "*foo*" 'foo-win)

application-bar does:
        (display-buffer "*foo*" 'bar-win)

> (3) One and the same application might want to display one and the same
>     buffer in different ways.  Typical examples are the -other-window
>     and -other-frame postfixed commands.  I could also imagine some ad
>     hoc decisions based on the actual size of the buffer or other buffer
>     local values.

application-foo does:
    (display-buffer "*foo*" 'foo-normal)

application-foo does also:
    (display-buffer "*foo*" 'foo-special)

> I could imagine setting the values of these variables in a buffer-local
> fashion which would still not DTRT when two applications try to display
> one and the same buffer in different locations.

What "variables"?

>  > I guess, for emacs' own packages there is no problem as you can
>  > have the entries pre-configured.  For other packages you might
>  > invent some method that allows them to add entries on the fly
>  > when they are first installed.
>
> Would your really allow "other packages" mess with user options?

Yes, sure.  As long as it's done safely via an helper-function that
you wrote.  For example:

   (display-add-buffer-names-default-entry '((foo-normal) <specifiers))

>  > Indeed, but for the sole reason to completely ignore what the application
>  > wants and instead let ewm show buffers where the user wants ;)
>
> It will take us some time to get there.

To get there it is important that your design is powerful.

Say, if GUD was changed to use nothing but display-buffer with
labels, then ewm would have not problem to show any nice layout
that the user wants.

The question is:  Would your built-in wm work well too for GUD?
Because if it does not then packages like GUD would still have
to use hard-calls to 'split-window'.  Which in turn makes it
impossible to use ewm.

That means: If your built-in wm does not work well then not only
doesn't emacs have a well working wm, but also users wont have
the option to install a better one.

>  > Free users!  No power to applications!
>
> Is ewm a user or an application?

ewm is a friend of the user.
1) It does exactly what the user wants.
2) In case it doesn't the user is free not to use it.

> martin