[Top][All Lists]

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

Re: The window-pub branch

From: grischka
Subject: Re: The window-pub branch
Date: Sun, 21 Nov 2010 14:34:37 +0100
User-agent: Thunderbird (Windows/20090812)

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.


reply via email to

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