Re: The window-pub branch

Re: The window-pub branch

[grischka]

Is it possible to have display-buffer-function back?  (Or same
functionality with new name if you prefer.)

Also, is it possible to route any other functions that effect to
displaying a buffer (such as switch-to-buffer) through display-buffer
exclusively?

Also, is it possible to have same logic to "un-display" (hide) a
buffer, such that delete-buffer and bury-buffer are routed through
that, also exclusively? And then to have a hook too, such as
"hide-buffer-function"?

And yes, that would be to bypass all the interesting logic you just
designed and to replace it with something completely different. ;)

--- grischka

Re: The window-pub branch

[martin rudalics]

 > Is it possible to have display-buffer-function back?  (Or same
 > functionality with new name if you prefer.)

 From the doc-string of `display-buffer-names':

    Any other symbol with a function definition means to call that
    function to display the buffer.  The function is called with two
    arguments - the buffer to display and a list of specifiers - and
    is supposed to display the buffer and return the window used for
    that purpose.  The function is also responsible for giving the
    variable `display-buffer-window' and the
    `quit-restore' parameter of the window used a meaningful value.

So why do you think it's gone?  You can define

(defun display-buffer-in-other-window-on-same-frame (buffer specifiers)
   (display-buffer
    "*scratch*"
    '(same-frame (reuse-buffer-window . nil) (not-this-window . t))))

and put this into `display-buffer-names' or `display-buffer-regexps' or
write

(display-buffer "*scratch*" 'display-buffer-in-other-window-on-same-frame)

 > Also, is it possible to route any other functions that effect to
 > displaying a buffer (such as switch-to-buffer) through display-buffer
 > exclusively?

With the exception of `switch-to-buffer' all these route now through
`display-buffer'.  I could add an option to have `switch-to-buffer'
route through `display-buffer' as well.  `set-window-buffer' can't be
rewritten, for obvious reasons.

 > Also, is it possible to have same logic to "un-display" (hide) a
 > buffer, such that delete-buffer and bury-buffer are routed through
 > that, also exclusively? And then to have a hook too, such as
 > "hide-buffer-function"?

Hiding a buffer is done by `replace-buffer-in-windows' which is called
by `kill-buffer' (I suppose you mean that by "delete-buffer").  I don't
understand the semantics of `bury-buffer' well enough.  What would you
want to put on that hook?

 > And yes, that would be to bypass all the interesting logic you just
 > designed and to replace it with something completely different. ;)

IIUC only your first issue fits into this remark.  The routing issue you
raised goes into the opposite direction, I presume.  And the "hiding"
logic was redesigned (confer `switch-to-prev-buffer') but it's only
loosely connected to buffer display proper.

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
> So why do you think it's gone?  You can define
> 
> (defun display-buffer-in-other-window-on-same-frame (buffer specifiers)
>   (display-buffer
>    "*scratch*"
>    '(same-frame (reuse-buffer-window . nil) (not-this-window . t))))
> 
> and put this into `display-buffer-names' or `display-buffer-regexps' or
> write
> 
> (display-buffer "*scratch*" 'display-buffer-in-other-window-on-same-frame)

I don't want display "*scratch*".  I want
    (setq display-buffer-regexps '(((".*") my-display-buffer)))
;-)

>  > Also, is it possible to route any other functions that effect to
>  > displaying a buffer (such as switch-to-buffer) through display-buffer
>  > exclusively?
> 
> With the exception of `switch-to-buffer' all these route now through
> `display-buffer'.  I could add an option to have `switch-to-buffer'
 > route through `display-buffer' as well.

One exception is still an exception.  Why do you need it?

Also, what method does your code use to display "*compilation*"?
It doesn't seem to like my-display-buffer.

> `set-window-buffer' can't be rewritten, for obvious reasons.

Why not? You could rename the current low-level one to
"set-window-buffer-internal".

> 
>  > Also, is it possible to have same logic to "un-display" (hide) a
>  > buffer, such that delete-buffer and bury-buffer are routed through
>  > that, also exclusively? And then to have a hook too, such as
>  > "hide-buffer-function"?
> 
> Hiding a buffer is done by `replace-buffer-in-windows' which is called
> by `kill-buffer' (I suppose you mean that by "delete-buffer").  I don't
> understand the semantics of `bury-buffer' well enough.  What would you
> want to put on that hook?

Obviously some code to replace a buffer in its window(s) rsp. delete
the window(s).

>  > And yes, that would be to bypass all the interesting logic you just
>  > designed and to replace it with something completely different. ;)
> 
> IIUC only your first issue fits into this remark.  The routing issue you
> raised goes into the opposite direction, I presume.  

No, same direction.  Obviously only what is routed through the same
function can be catched by a single hook in that function.

> And the "hiding"
> logic was redesigned (confer `switch-to-prev-buffer') but it's only
> loosely connected to buffer display proper.

IMO strongly symmetrically related.

So, is it possible to hook 'switch-to-prev-buffer' in order to catch
buffer "undisplay", with no exception?

Also, while we're at it: I think I want hooks for "select-window",
"set-window-buffer" and finally "split-window", too.

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 > I don't want display "*scratch*".  I want
 >    (setq display-buffer-regexps '(((".*") my-display-buffer)))
 > ;-)

So do that.  But beware of calling `display-buffer' in it.  (I think
I'll have to restore the old `display-buffer-function' as well.)

 > One exception is still an exception.  Why do you need it?

Because `switch-to-buffer' is special.  If you want `display-buffer'
behavior use `display-buffer-same-window'.  I intend to replace all
`switch-to-buffer' calls from Elisp by that.

 > Also, what method does your code use to display "*compilation*"?
 > It doesn't seem to like my-display-buffer.

Try setting the `override' specifier ;-)

 >> `set-window-buffer' can't be rewritten, for obvious reasons.
 >
 > Why not? You could rename the current low-level one to
 > "set-window-buffer-internal".

`set-window-buffer' _is_ low-level.  Emacs needs some mechanism to
bypass whatever people do in `my-display-buffer'.

 >> Hiding a buffer is done by `replace-buffer-in-windows' which is called
 >> by `kill-buffer' (I suppose you mean that by "delete-buffer").  I don't
 >> understand the semantics of `bury-buffer' well enough.  What would you
 >> want to put on that hook?
 >
 > Obviously some code to replace a buffer in its window(s) rsp. delete
 > the window(s).

There's no single entry point for "hiding a buffer".  The nearest
equivalent is probably `switch-to-prev-buffer'.  But sometimes the
window gets deleted before and in the worst case *scratch* must be
recreated to show some buffer in the window.

Note that `display-buffer' and a hypothetical `undisplay-buffer' would
not be not orthogonal.  It's hardly possible to tell whether a buffer
shown in a window was effectively put there by `display-buffer' or by
`set-window-buffer'.

 >> IIUC only your first issue fits into this remark.  The routing issue you
 >> raised goes into the opposite direction, I presume.
 >
 > No, same direction.  Obviously only what is routed through the same
 > function can be catched by a single hook in that function.

I see what you mean.

 >> And the "hiding"
 >> logic was redesigned (confer `switch-to-prev-buffer') but it's only
 >> loosely connected to buffer display proper.
 >
 > IMO strongly symmetrically related.

But difficult to detect in practice.

 > So, is it possible to hook 'switch-to-prev-buffer' in order to catch
 > buffer "undisplay", with no exception?

No.  `set-window-buffer' can do such an "undisplay" and I see no way to
catch that.  (You can hook into `window-configuration-change-hook' but
that wouldn't help you much: At the time it gets called the buffer was
already unhidden.)

 > Also, while we're at it: I think I want hooks for "select-window",
 > "set-window-buffer" and finally "split-window", too.

The latter two call `window-configuration-change-hook'.  The easiest
thing would be to call that for `select-window' too.  The problem is
that all these hooks don't provide much information about the window
configuration before the split, selection, ...

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > One exception is still an exception.  Why do you need it?
> 
> Because `switch-to-buffer' is special.  

Then what about
   (defun switch-to-buffer (b) (display-buffer b 'special))

>  >> `set-window-buffer' can't be rewritten, for obvious reasons.
>  >
>  > Why not? You could rename the current low-level one to
>  > "set-window-buffer-internal".
> 
> `set-window-buffer' _is_ low-level.  Emacs needs some mechanism to
> bypass whatever people do in `my-display-buffer'.

Saying "Emacs" you insist on the absence of architecture.  Maybe
you agree that direct access of application code to functions such
as 'split-window' and 'set-window-buffer' doesn't play well with
any attempts to wrap them into more user-friendly behavior.

Where a "wrapper" is a piece of code with exclusive access to the
functionality that it wraps.  There must be no way to bypass the
wrapper except for the wrapper itself.

> There's no single entry point for "hiding a buffer".  The nearest
> equivalent is probably `switch-to-prev-buffer'.  But sometimes the
> window gets deleted before and in the worst case *scratch* must be
> recreated to show some buffer in the window.

I'm not interested in the details of existing bugs.  I'm only
interested whether your new design is able to get past them.

> Note that `display-buffer' and a hypothetical `undisplay-buffer' would
> not be not orthogonal.  It's hardly possible to tell whether a buffer
> shown in a window was effectively put there by `display-buffer' or by
> `set-window-buffer'.

One more point for not allowing applications to mess with
'set-window-buffer' (and friends).

>  > Also, while we're at it: I think I want hooks for "select-window",
>  > "set-window-buffer" and finally "split-window", too.
> 
> The latter two call `window-configuration-change-hook'.  The easiest
> thing would be to call that for `select-window' too.  The problem is
> that all these hooks don't provide much information about the window
> configuration before the split, selection, ...

Sure, problems ... ;)

However it's not that there aren't ways to solve them.  Such as
from Xlib manual:

  "A feature called substructure redirect allows a window manager to
   intercept any requests to map, move, resize, or change the border
   width of windows. This allows the window manager to modify these
   requests, if necessary, to ensure that they meet its window layout
   policy."

Which in other words means a single hook that is sufficient for
everything a window-manager might want to do.

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 > Then what about
 >   (defun switch-to-buffer (b) (display-buffer b 'special))

This could be done.

 >> `set-window-buffer' _is_ low-level.  Emacs needs some mechanism to
 >> bypass whatever people do in `my-display-buffer'.
 >
 > Saying "Emacs" you insist on the absence of architecture.

Why?

 > Maybe
 > you agree that direct access of application code to functions such
 > as 'split-window' and 'set-window-buffer' doesn't play well with
 > any attempts to wrap them into more user-friendly behavior.

I agree.  Though there are occasions where an application wants to have
full control over the frame layout - gud and ediff, for example.

But why be user-friendly in the first place if users only need hooks for
calling their own functions instead ;-)

 > Where a "wrapper" is a piece of code with exclusive access to the
 > functionality that it wraps.  There must be no way to bypass the
 > wrapper except for the wrapper itself.

It would only take a few seconds before someone asked for a way to
bypass such a wrapper programmatically.

 >> There's no single entry point for "hiding a buffer".  The nearest
 >> equivalent is probably `switch-to-prev-buffer'.  But sometimes the
 >> window gets deleted before and in the worst case *scratch* must be
 >> recreated to show some buffer in the window.
 >
 > I'm not interested in the details of existing bugs.  I'm only
 > interested whether your new design is able to get past them.

This is not about a bug.  It's about what Emacs has to do in order to
prevent crashing.

 >>...  It's hardly possible to tell whether a buffer
 >> shown in a window was effectively put there by `display-buffer' or by
 >> `set-window-buffer'.
 >
 > One more point for not allowing applications to mess with
 > 'set-window-buffer' (and friends).

Demandons l'impossible.

 >  "A feature called substructure redirect allows a window manager to
 >   intercept any requests to map, move, resize, or change the border
 >   width of windows. This allows the window manager to modify these
 >   requests, if necessary, to ensure that they meet its window layout
 >   policy."
 >
 > Which in other words means a single hook that is sufficient for
 > everything a window-manager might want to do.

Doesn't `window-configuration-change-hook' get near to that?  Though it
seems to me that you want to put yourself into the window manager's seat
here.

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > Where a "wrapper" is a piece of code with exclusive access to the
>  > functionality that it wraps.  There must be no way to bypass the
>  > wrapper except for the wrapper itself.
> 
> It would only take a few seconds before someone asked for a way to
> bypass such a wrapper programmatically.

Only if the wrapper doesn't work very well.  And a wrapper cannot
work very well if it can be bypassed.

Anyway all I'm asking for is the OPTION to install such wrapper.
The obvious way to bypass it is simply not to install it.  But as
long as it is installed, there should be no way to bypass it.
Otherwise it wouldn't be an honest option.

>  > I'm not interested in the details of existing bugs.  I'm only
>  > interested whether your new design is able to get past them.
> 
> This is not about a bug.  It's about what Emacs has to do in order to
> prevent crashing.

You speak of "Emacs" as if it were a third party in that game.
There is nothing anywhere outside that would force it to crash
from zero-sized windows or windows with no buffer.

(Then again number "0" was still causing headaches to ancient greek
philosophers who asked: "How can nothing be something?" :)).

>  >  "A feature called substructure redirect allows a window manager to
>  >   intercept any requests to map, move, resize, or change the border
>  >   width of windows. This allows the window manager to modify these
>  >   requests, if necessary, to ensure that they meet its window layout
>  >   policy."
>  >
>  > Which in other words means a single hook that is sufficient for
>  > everything a window-manager might want to do.
> 
> Doesn't `window-configuration-change-hook' get near to that?  Though it
> seems to me that you want to put yourself into the window manager's seat
> here.

Yes.  Well, maybe.  At this point I'm just trying to push you towards
installing such seat and to suggest to use it in your own functions.

Of course in order to prove the fitness of an interface you'd better
have at least two possible clients.  Here is one more, if you want to:
http://lists.gnu.org/archive/html/gnu-emacs-sources/2010-05/msg00026.html

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 > Only if the wrapper doesn't work very well.  And a wrapper cannot
 > work very well if it can be bypassed.

Emacs 23 buffer display is a matryoshka of wrappers.  Look at how
applications set or bind all sort of customizable variables to bypass
the user.

 > Anyway all I'm asking for is the OPTION to install such wrapper.
 > The obvious way to bypass it is simply not to install it.  But as
 > long as it is installed, there should be no way to bypass it.
 > Otherwise it wouldn't be an honest option.

I reinstalled `display-buffer-function' so you have one additional
layer.  And the override specifier should give you a way to override
anything supplied by an application.  Did you try it, by the way?

But there's still the possibility that an application binds
`display-buffer-names' to override the user.  We should at least have
the byte-compiler complain.

 > You speak of "Emacs" as if it were a third party in that game.

Deliberately so.

 > There is nothing anywhere outside that would force it to crash
 > from zero-sized windows or windows with no buffer.

It's only when I write display code that I can remove invariants like
"every window must be at least one line tall" or "every live window must
have a live buffer associated with it".  When I write code for handling
windows I treat the display code as a black box (or a "third party")
with given restrictions and implied invariants.  When I write code for
displaying buffers I treat the code for handling windows as a black box
with given restrictions and implied invariants.

Here I can still crash the trunk by repeatedly trying to kill *scratch*.

 > Yes.  Well, maybe.  At this point I'm just trying to push you towards
 > installing such seat and to suggest to use it in your own functions.

The functions I write at the moment should work without such seat.
Otherwise, giving one seat to the application programmer would have the
user caught between two stools.

 > Of course in order to prove the fitness of an interface you'd better
 > have at least two possible clients.  Here is one more, if you want to:
 > http://lists.gnu.org/archive/html/gnu-emacs-sources/2010-05/msg00026.html

The problem with ewm.el is that it would once more hide an option like
`display-buffer-names' because it imposes its own rules on which window
to use for displaying a buffer.  What would you give a user who asked
for a hook to escape the standard bevhavior of ewm?

BTW, in an earlier version of my code `display-buffer-names' did allow
the user to control reusing the four windows on top, bottom, left and
right of a frame.  When I find the time I'll clean up the code and put
it back.

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
> I reinstalled `display-buffer-function' so you have one additional
> layer.  And the override specifier should give you a way to override
> anything supplied by an application.  Did you try it, by the way?

Actually no. I had already switched to (defadvice display-buffer
which works anyway ;)

Feedback wise I'd note that I was not pleased to see two of three
entries I made to 'display-buffer-names' not work.  As a user if
I write (new-window (root . left)) and then the new window still
opens on bottom, I have better things to do.

Design wise, I think that the idea with the specifiers to tweak
window layout is not that bad actually.

In any case however it seems like a pretty bad idea to scatter
these specifiers all over the elisp code (whether explicitly
passed as parameters or implicitly with all sort of bizarre long
convenience function names.)

Why is it not possible to have one single function that takes no
specifiers and that is used by all applications with no difference,
in combination with pre-configured entries in 'display-buffer-names'
to get the desired behavior for specific applications.

This would be transparent, prove the power of the design, and as a
user I can read the real-use entries and learn from them and alter
them if I wish.

> It's only when I write display code that I can remove invariants like
> "every window must be at least one line tall" or "every live window must
> have a live buffer associated with it".  When I write code for handling
> windows I treat the display code as a black box (or a "third party")
> with given restrictions and implied invariants.  When I write code for
> displaying buffers I treat the code for handling windows as a black box
> with given restrictions and implied invariants.

I'd maybe rather spend 3 days in one box to remove some restrictions
first before I spend 10 months in the other box to work around them.

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 > Feedback wise I'd note that I was not pleased to see two of three
 > entries I made to 'display-buffer-names' not work.  As a user if
 > I write (new-window (root . left)) and then the new window still
 > opens on bottom, I have better things to do.

If this doesn't work there's a bug in the code.  You could have tried to
debug where and how it fails :-(

 > In any case however it seems like a pretty bad idea to scatter
 > these specifiers all over the elisp code (whether explicitly
 > passed as parameters or implicitly with all sort of bizarre long
 > convenience function names.)
 >
 > Why is it not possible to have one single function that takes no
 > specifiers and that is used by all applications with no difference,
 > in combination with pre-configured entries in 'display-buffer-names'
 > to get the desired behavior for specific applications.
 >
 > This would be transparent, prove the power of the design, and as a
 > user I can read the real-use entries and learn from them and alter
 > them if I wish.

I didn't intend to write these "convenience functions" in the first
place.  I wrote them when I found out that people mostly reused code
they found elsehwere because it apparently fitted their needs.  I could
replace these functions by pre-configured entries but how should an
application select such an entry for a specific call?

Note also that the argument in `display-buffer' is already there and I
already ignore the third argument.

Specifiers are powerful because an application can specify where the
window shall appear and how it should look like.  This was not possible
before.  And wasn't it you who wanted to replace `set-window-buffer' and
`split-window' with `display-buffer' calls?  How could an application
encompass the power of the former by choosing among some pre-configured
entries?

 > I'd maybe rather spend 3 days in one box to remove some restrictions
 > first before I spend 10 months in the other box to work around them.

I decided to spend 3 days to work around things in a box I'm familiar
with instead of working 3 months changing things in a box whose
internals I don't know well enough.

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
> If this doesn't work there's a bug in the code.  You could have tried to
> debug where and how it fails :-(

"As a user" I don't debug ;)

> I could replace these functions by pre-configured entries but how 
> should an application select such an entry for a specific call?

Actually I've spend some thoughts on this already for ewm.  I'd
propose indirection:  That is, 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>)
    ...
  ))

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.

> Specifiers are powerful because an application can specify where the
> window shall appear and how it should look like.  This was not possible
> before.  And wasn't it you who wanted to replace `set-window-buffer' and
> `split-window' with `display-buffer' calls?

Indeed, but for the sole reason to completely ignore what the application
wants and instead let ewm show buffers where the user wants ;)

> How could an application
> encompass the power of the former by choosing among some pre-configured
> entries?

Free users!  No power to applications!

>
> martin
>

Re: The window-pub branch

[martin rudalics]

 > ..., 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'.

(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.

(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.

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.

 > 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?

 > 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.

 > Free users!  No power to applications!

Is ewm a user or an application?

martin

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
> 

Re: The window-pub branch

[martin rudalics]

 > However there are some pre-configured entries with specifiers
 > in `display-buffer-names'.
 >
 > You have already pre-configured entries in `display-buffer-regexps'

Yes.  But these are not tied to applications.  They just mimic the old
default values of `pop-up-windows' etc.

I can't put application specific things in `display-buffer-names'.  We
could have done that long ago, for example for info or help, instead of
clobbering options like `same-window-buffer-names' via add-hook.

It doesn't help putting them there for the following simple reason:

(1) The user customizes `display-buffer-names' and saves the
     customizations to his .emacs.

(2) An application wants to change a preconfigured value or introduce a
     new one.

In this case you would have to merge the preconfigured value with the
one on .emacs.  I can neither expect the user to do this manually nor
write a program in reasonable time that solves the possible conflicts in
this area.

Preconfigured, application dependent values must not reside in
`display-buffer-names'.  That's why I'd need a shadow variable to
implement your propsal.

 >> 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))

No matter how safely this is done - it changes the default value and not
the value in the user's .emacs.  And it will make the customization
interface complain about a value changed outside customize (fixing this
was one of the main reason why I started working with specifiers).

martin

Re: The window-pub branch

[Stefan Monnier]

>> 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))

> No matter how safely this is done - it changes the default value and not
> the value in the user's .emacs.  And it will make the customization
> interface complain about a value changed outside customize (fixing this
> was one of the main reason why I started working with specifiers).

To me (as a user) the main problem is that the user needs to be able to
easily override such settings.  So a package changing
display-buffer-names after reading the .emacs is not a good idea.


        Stefan

Re: The window-pub branch

[martin rudalics]

 > To me (as a user) the main problem is that the user needs to be able to
 > easily override such settings.  So a package changing
 > display-buffer-names after reading the .emacs is not a good idea.

With `display-buffer-names' a user can set the `override' specifier so
this is no problem.  What's difficult is how to merge back or dismiss a
value changed by the application.  Consider the following scenario:

(1) The user customizes and saves the value of an option back to her
     .emacs.

(2) The application adds or changes an entry of the option and, assisted
     by some extraordinary magic, manages to merge the new value into the
     option without breaking anything.

(3) The user customizes the option again, changing or removing the
     application's entry.

At this time the magic from step (2) would have to decide how to _not_
merge the entry into the option again.  All this with users switching
back and forth between different .emacs files, refusing to work with the
standard customization interface, testing different Emacs versions ...

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > To me (as a user) the main problem is that the user needs to be able to
>  > easily override such settings.  So a package changing
>  > display-buffer-names after reading the .emacs is not a good idea.
> 
> With `display-buffer-names' a user can set the `override' specifier so
> this is no problem.  What's difficult is how to merge back or dismiss a
> value changed by the application.  Consider the following scenario:
> 
> (1) The user customizes and saves the value of an option back to her
>     .emacs.
> 
> (2) The application adds or changes an entry of the option and, assisted
>     by some extraordinary magic, manages to merge the new value into the
>     option without breaking anything.
> 
> (3) The user customizes the option again, changing or removing the
>     application's entry.
> 
> At this time the magic from step (2) would have to decide how to _not_
> merge the entry into the option again.  All this with users switching
> back and forth between different .emacs files, refusing to work with the
> standard customization interface, testing different Emacs versions ...

Well, nobody wants you to do things that are impossible.

So I'd just go with the two variables as you already proposed.  One
for the user to customize and one for applications to add their
defaults.  User cannot see the defaults then but it works.

Maybe customize has some feature where you can still show the
defaults as a comment or whatever.

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 > So I'd just go with the two variables as you already proposed.  One
 > for the user to customize and one for applications to add their
 > defaults.  User cannot see the defaults then but it works.

I still have to maintain the original concept of passing arbitrary
specifiers with `display-buffer' calls.  An application might, for
example, want to calculate the minimum or desired height of the window
from the current size of the buffer to display.

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
> I still have to maintain the original concept of passing arbitrary
> specifiers with `display-buffer' calls.  An application might, for
> example, want to calculate the minimum or desired height of the window
> from the current size of the buffer to display.

How can the user override specifiers for buffers that don't match
unambiguous naming conventions (ediff, dired, ...)?

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 > How can the user override specifiers for buffers that don't match
 > unambiguous naming conventions (ediff, dired, ...)?

Another user option, say `display-buffer-symbols'?  The application
would pass a symbol in the call and make sure it has an entry in the
`display-buffer-specifiers' list which associates symbols like
'other-window with specifiers.  ediff could add entries like 'ediff-A
and 'ediff-B to `display-buffer-specifiers' and the user, in
`display-buffer-symbols', could provide an entry to override them.

But I'm not sure how to resolve the conflict when a matching entry can
be found in both `display-buffer-names' and `display-buffer-symbols'.

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > How can the user override specifiers for buffers that don't match
>  > unambiguous naming conventions (ediff, dired, ...)?
> 
> Another user option, say `display-buffer-symbols'?  The application
> would pass a symbol in the call and make sure it has an entry in the
> `display-buffer-specifiers' list  which associates symbols like
> 'other-window with specifiers.   ediff could add entries like 'ediff-A
> and 'ediff-B to `display-buffer-specifiers' and the user, in
> `display-buffer-symbols', could provide an entry to override them.
> 
> But I'm not sure how to resolve the conflict when a matching entry can
> be found in both `display-buffer-names' and `display-buffer-symbols'.

A symbol entry is more specific.

However I'd maybe just put names/regexps/symbols in the same
structure.  Such as:

    (setq display-buffer-specifiers '(
       ((a-symbol "*b-name*" (r . "^c-regexp.+"))
	<specifiers>
         )
       ...
     ))

That way the user can express preferences by the order naturally.

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 > A symbol entry is more specific.

More specific than a buffer name?

 > However I'd maybe just put names/regexps/symbols in the same
 > structure.  Such as:
 >
 >    (setq display-buffer-specifiers '(
 >       ((a-symbol "*b-name*" (r . "^c-regexp.+"))
 >     <specifiers>
 >         )
 >       ...
 >     ))
 >
 > That way the user can express preferences by the order naturally.

I had that before with symbols 'name and 'regexp.  It didn't look bad in
the customization interface IIRC but seemed more annoying in the printed
specification.  OTOH it allows to give regexp based specifiers higher
priority than name based ones.  Maybe I'll give it another try.

martin

Re: The window-pub branch

[Stefan Monnier]

> I had that before with symbols 'name and 'regexp.  It didn't look bad in
> the customization interface IIRC but seemed more annoying in the printed
> specification.  OTOH it allows to give regexp based specifiers higher
> priority than name based ones.  Maybe I'll give it another try.

You don't need to tag things with `name' or `regexp' since you can use
`stringp' or `symbolp' to distinguish the two cases.


        Stefan

Re: The window-pub branch

[martin rudalics]

 > You don't need to tag things with `name' or `regexp' since you can use
 > `stringp' or `symbolp' to distinguish the two cases.

A buffer name is a string and a regexp is a string.  What am I missing?

martin

Re: The window-pub branch

[Stefan Monnier]

>> You don't need to tag things with `name' or `regexp' since you can use
>> `stringp' or `symbolp' to distinguish the two cases.
> A buffer name is a string and a regexp is a string.  What am I missing?

We're not talking about the same thing.  IIUC you're talking about
unifying display-buffer-names and display-buffer-regexp (I think this
can be done by obsoleting display-buffer-names), whereas I'm talking
about adding support for symbols like `ediff-A' which would need to be
provided by the caller of display-buffer.


        Stefan

Re: The window-pub branch

[martin rudalics]

 > We're not talking about the same thing.  IIUC you're talking about
 > unifying display-buffer-names and display-buffer-regexp (I think this
 > can be done by obsoleting display-buffer-names),

The only issue I see is that users would have to escape the asterisk in
*info* and *help*.  Probably not a big issue.

 > whereas I'm talking
 > about adding support for symbols like `ediff-A' which would need to be
 > provided by the caller of display-buffer.

martin

Re: The window-pub branch

[Stefan Monnier]

> But I'm not sure how to resolve the conflict when a matching entry can
> be found in both `display-buffer-names' and `display-buffer-symbols'.

If a single var is used, there's no such conflict.


        Stefan "who'd then be tempted to request some partial order on
                the symbols used, so you can set an entry in
                display-buffer-names for `ediff-sources' and have it
                take effect for both `ediff-A' and `ediff-B' buffers."

Re: The window-pub branch

[martin rudalics]

 >> But I'm not sure how to resolve the conflict when a matching entry can
 >> be found in both `display-buffer-names' and `display-buffer-symbols'.
 >
 > If a single var is used, there's no such conflict.

So why did we have two for the same-window- and special-display-
options?


 >         Stefan "who'd then be tempted to request some partial order on
 >                 the symbols used, so you can set an entry in
 >                 display-buffer-names for `ediff-sources' and have it
 >                 take effect for both `ediff-A' and `ediff-B' buffers."

The values of my options currently specify a partial order with all name
based values preceding the regexp based ones.  Do I understand correctly
that you want, for example, show a buffer matching some regexp usually
on a separate frame while ediff can override that and put it in one and
the same frame together with the other buffer(s)?

martin

Re: The window-pub branch

[Stefan Monnier]

>>> But I'm not sure how to resolve the conflict when a matching entry can
>>> be found in both `display-buffer-names' and `display-buffer-symbols'.
>> If a single var is used, there's no such conflict.
> So why did we have two for the same-window- and special-display-
> options?

Beats me.

>> Stefan "who'd then be tempted to request some partial order on
>> the symbols used, so you can set an entry in
>> display-buffer-names for `ediff-sources' and have it
>> take effect for both `ediff-A' and `ediff-B' buffers."

> The values of my options currently specify a partial order with all name
> based values preceding the regexp based ones.  Do I understand correctly
> that you want, for example, show a buffer matching some regexp usually
> on a separate frame while ediff can override that and put it in one and
> the same frame together with the other buffer(s)?

I might want that, indeed, but what I wrote above is not directly
related, it's just that if ediff uses symbols `ediff-A' and `ediff-B',
I might like to be able to have a single entry that covers both (and
covers the ediff-ancestor one as well).  That would naturally extend to
a more general form of classification of buffers (e.g. `ediff' for all
things related to ediff... I'd probably also like to be able to use
a major-mode name as a classification).


        Stefan

Re: The window-pub branch

[martin rudalics]

 > I might want that, indeed, but what I wrote above is not directly
 > related, it's just that if ediff uses symbols `ediff-A' and `ediff-B',
 > I might like to be able to have a single entry that covers both (and
 > covers the ediff-ancestor one as well).  That would naturally extend to
 > a more general form of classification of buffers (e.g. `ediff' for all
 > things related to ediff... I'd probably also like to be able to use
 > a major-mode name as a classification).

So you want to use the lexicographic ordering of the print names of
symbols here?  Like

        ediff < ediff-A < ediff-A-whatever

martin

Re: The window-pub branch

[Stefan Monnier]

>> I might want that, indeed, but what I wrote above is not directly
>> related, it's just that if ediff uses symbols `ediff-A' and `ediff-B',
>> I might like to be able to have a single entry that covers both (and
>> covers the ediff-ancestor one as well).  That would naturally extend to
>> a more general form of classification of buffers (e.g. `ediff' for all
>> things related to ediff... I'd probably also like to be able to use
>> a major-mode name as a classification).
> So you want to use the lexicographic ordering of the print names of
> symbols here?  Like
>        ediff < ediff-A < ediff-A-whatever

Didn't think of it.  It might work surprisingly well, but I don't find
it very attractive.  Instead, I was thinking of something more like an
explicitly specified (partial?) ordering.
E.g. Ediff could have somewhere

  (define-display-buffer-class 'ediff
    'ediff-a 'ediff-b 'ediff-ancestor 'ediff-control)

Or maybe such symbols could simply be predicates (simpler to implement
and more general).


        Stefan

Re: The window-pub branch

[martin rudalics]

 > E.g. Ediff could have somewhere
 >
 >   (define-display-buffer-class 'ediff
 >     'ediff-a 'ediff-b 'ediff-ancestor 'ediff-control)
 >
 > Or maybe such symbols could simply be predicates (simpler to implement
 > and more general).

I'm still too silly to understand how to use that order in
`display-buffer' :-(  Can you enlighten me?

martin

Re: The window-pub branch

[Stefan Monnier]

>> E.g. Ediff could have somewhere
>> 
>> (define-display-buffer-class 'ediff
>> 'ediff-a 'ediff-b 'ediff-ancestor 'ediff-control)
>> 
>> Or maybe such symbols could simply be predicates (simpler to implement
>> and more general).

> I'm still too silly to understand how to use that order in
> `display-buffer' :-(  Can you enlighten me?

Hmm... here I finally realize maybe I'm talking about something
completely different.  I was thinking of special-display-buffer-names
rather than display-buffer-names.  I.e. I was thinking of a setting like

  (setq special-display-buffer-names
        '((ediff (same-frame . t))))
        
Which would make the (same-frame . t) apply to all display-buffer calls
that specify `ediff-a' or `ediff-b' or `ediff-ancestor', ...


        Stefan

Re: The window-pub branch

[martin rudalics]

 > Hmm... here I finally realize maybe I'm talking about something
 > completely different.  I was thinking of special-display-buffer-names
 > rather than display-buffer-names.

`display-buffer-names' is supposed to generalize
`special-display-buffer-names'.

 > I.e. I was thinking of a setting like
 >
 >   (setq special-display-buffer-names
 >         '((ediff (same-frame . t))))

Would that be in .emacs?

 > Which would make the (same-frame . t) apply to all display-buffer calls
 > that specify `ediff-a' or `ediff-b' or `ediff-ancestor', ...

Adding '(("^ediff.*") (same-frame)) to `display-buffer-regexps' should
handle that.

martin

Re: The window-pub branch

[grischka]

I found out that hooking ediff to use just 'display-buffer is
actually easy via 'ediff-window-setup-function'.

Here is some code if you want to test your future version of
'display-buffer'.  It works quite well with a slightly improved
version of EWM for 'ediff-files'.

The wrapper calls two functions that you'd need to have:

     my-display-multi-buffers (list-of-buffers-and-labels)
     ;; display some buffers and return list of their windows

     my-select-window (window)
     ;; select 'window' and frame where it's on:

The stuff in the apply form is from ediff-setup-windows-plain-compare.
Don't ask me what it does.

(setq ediff-window-setup-function
       (lambda (A B C H) ;; buffers
         (apply (lambda (WA WB WC WH) ;; windows
                  (ediff-with-current-buffer control-buffer
                    (setq ediff-window-A WA
                          ediff-window-B WB
                          ediff-window-C WC
                          )
                    (when ediff-windows-job
                      (set-window-start WA
                        (ediff-overlay-start
                          (ediff-get-value-according-to-buffer-type
                            'A ediff-narrow-bounds)))
                      (set-window-start WB
                        (ediff-overlay-start
                          (ediff-get-value-according-to-buffer-type
                            'B ediff-narrow-bounds)))
                      ))
                  (my-select-window WH)
                  (ediff-setup-control-buffer control-buffer)
                  )
                (my-display-multi-buffers
                 `((,A . ediff-A)
                   (,B . ediff-B)
                   (,C . ediff-C)
                   (,H . ediff-H)
                   ))
                )))

Re: The window-pub branch

[martin rudalics]

 > I found out that hooking ediff to use just 'display-buffer is
 > actually easy via 'ediff-window-setup-function'.

For some value of easy ;-)

 > Here is some code if you want to test your future version of
 > 'display-buffer'.  It works quite well with a slightly improved
 > version of EWM for 'ediff-files'.

What does EWM different from the standard setup of ediff?  I suppose
you'd use the primary and secondary edit window for the A and B buffer
and a third one (the compile window maybe) for the H buffer.  Is your
primary aim to keep things like the sidebar and top windows alive - that
is to "embed" the ediff windows in the rest of your frame components?

 > The wrapper calls two functions that you'd

Who is "you"?

 > need to have:
 >
 >     my-display-multi-buffers (list-of-buffers-and-labels)
 >     ;; display some buffers and return list of their windows

I'm currently using the third argument of `display-buffer' as label (I
call it TAG so far).  For `pop-to-buffer' it's the fourth.

 >     my-select-window (window)
 >     ;; select 'window' and frame where it's on:

In what sense is this different from `select-window'?  In some ediff
sense (I didn't look into their code)?

 > (setq ediff-window-setup-function
[...]
 >                (my-display-multi-buffers
 >                 `((,A . ediff-A)
 >                   (,B . ediff-B)
 >                   (,C . ediff-C)
 >                   (,H . ediff-H)

The great problem I see here is that setting up a window for C might
depend on _where_ A and B have been displayed before.  Suppose you want
to write a `display-buffer-function' for ediff-C: How would you know
where A and B are displayed?  If you can put all in one function (like
`ediff-setup-windows-multiframe-merge') things are fairly simple.  But
with separate display functions things get messy.  Or do you mean that
`my-display-multi-buffers' itself should track such window dependencies?

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > I found out that hooking ediff to use just 'display-buffer is
>  > actually easy via 'ediff-window-setup-function'.
>
> For some value of easy ;-)
>
>  > Here is some code if you want to test your future version of
>  > 'display-buffer'.  It works quite well with a slightly improved
>  > version of EWM for 'ediff-files'.
>
> What does EWM different from the standard setup of ediff?  I suppose
> you'd use the primary and secondary edit window for the A and B buffer
> and a third one (the compile window maybe) for the H buffer.  Is your
> primary aim to keep things like the sidebar and top windows alive - that
> is to "embed" the ediff windows in the rest of your frame components?

Well, my primary aim was to make some tests in the first place.
I'v tested with GUD too.  It actually started working after
I advised 'split-window' to do nothing.

Of course new ideas come to mind soon.  For example support for
switching the entire layout descriptions in order to have some
such as an 'ediff-perspective' or 'gud-perspective'. As opposed
to "embedding" the windows in the existing layout if you want to.

>
>  > The wrapper calls two functions that you'd
>
> Who is "you"?
>
>  > need to have:
>  >

I apologize, "you" does NOT have to need this.

>  >     my-display-multi-buffers (list-of-buffers-and-labels)
>  >     ;; display some buffers and return list of their windows
>
> I'm currently using the third argument of `display-buffer' as label (I
> call it TAG so far).  For `pop-to-buffer' it's the fourth.

After all it wouldn't be emacs if there were not at least two ways
to do the same thing just not quite.

>
>  >     my-select-window (window)
>  >     ;; select 'window' and frame where it's on:
>
> In what sense is this different from `select-window'?  In some ediff
> sense (I didn't look into their code)?

No, just different in the sense that it should really work.
(Also for windows on other frames that is).

>
>  > (setq ediff-window-setup-function
> [...]
>  >                (my-display-multi-buffers
>  >                 `((,A . ediff-A)
>  >                   (,B . ediff-B)
>  >                   (,C . ediff-C)
>  >                   (,H . ediff-H)
>
> The great problem I see here is that setting up a window for C might
> depend on _where_ A and B have been displayed before.

I was under the impression that it was exactly this problem that you
wanted to solve.  That is how to show some content such that it's
combined with some other content in some reasonable way UI-wise.

> Suppose you want
> to write a `display-buffer-function' for ediff-C: How would you know
> where A and B are displayed?

I would not want to write such function in the first place.

> If you can put all in one function (like
> `ediff-setup-windows-multiframe-merge') things are fairly simple.

For some value of simple ;-)  See ediff-wind.el ...

> But with separate display functions things get messy.

But the idea is messy:  That the shared resource screen space could
be used without proper synchronization.

> Or do you mean that
> `my-display-multi-buffers' itself should track such window dependencies?

Yes this can be one point to have such interface:  It could consider
dependencies between windows if suitable.  Also it could optimize away
the otherwise very short-lived window configurations.

EWM however neither is trying to optimize nor is it non-deterministic
as to where show what window.  It has a more basic problem that it
cannot currently guarantee the live-p-ness of 4 windows as returned
from distinct calls to ewm-display-buffer.

Other than that my implementation is in fact logically identical to:
   (defun my-display-multi-buffers (alist)
     (mapcar
       (lambda (e) (ewm-display-buffer (car e) (cdr e)))
       alist
       ))
with:
    ewm-display-buffer (buffer &optional label)

--- grischka

>
> martin
>

Re: The window-pub branch

[martin rudalics]

 > Well, my primary aim was to make some tests in the first place.
 > I'v tested with GUD too.  It actually started working after
 > I advised 'split-window' to do nothing.

On the GUD frame only, I suppose.  But in this case you could simply
make that frame unsplittable.

 > Of course new ideas come to mind soon.  For example support for
 > switching the entire layout descriptions in order to have some
 > such as an 'ediff-perspective' or 'gud-perspective'. As opposed
 > to "embedding" the windows in the existing layout if you want to.

Do I understand correctly that a "perspective" is a layout of a frame
which precludes using or splitting any of the window for another
purpose?  Can't this be made with current means by using unsplittable
frames and dedicated windows?  What else do you need?

 >>  >     my-select-window (window)
 >>  >     ;; select 'window' and frame where it's on:
 >>
 >> In what sense is this different from `select-window'?  In some ediff
 >> sense (I didn't look into their code)?
 >
 > No, just different in the sense that it should really work.
 > (Also for windows on other frames that is).

Can you give me an example where `select-window' doesn't do what
`my-select-window' would do?

 > I was under the impression that it was exactly this problem that you
 > wanted to solve.  That is how to show some content such that it's
 > combined with some other content in some reasonable way UI-wise.

`display-buffer' is too low level to do that.  Any such context
awareness must be controlled by an application like ediff or GUD via the
specifiers passed to `display-buffer'.

 >> Suppose you want
 >> to write a `display-buffer-function' for ediff-C: How would you know
 >> where A and B are displayed?
 >
 > I would not want to write such function in the first place.

But you want ediff to use `display-buffer' and you want to intercept
that via your own function.

 >> If you can put all in one function (like
 >> `ediff-setup-windows-multiframe-merge') things are fairly simple.
 >
 > For some value of simple ;-)  See ediff-wind.el ...

"fairly" represents one of these values.

 >> But with separate display functions things get messy.
 >
 > But the idea is messy:  That the shared resource screen space could
 > be used without proper synchronization.

What should be properly synchronized?

 > EWM however neither is trying to optimize nor is it non-deterministic
 > as to where show what window.  It has a more basic problem that it
 > cannot currently guarantee the live-p-ness of 4 windows as returned
 > from distinct calls to ewm-display-buffer.

What exactly is the problem?  Is it that a later call reuses a window
from an earlier call?  Does this happen with window-pub?

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > Well, my primary aim was to make some tests in the first place.
>  > I'v tested with GUD too.  It actually started working after
>  > I advised 'split-window' to do nothing.
> 
> On the GUD frame only, I suppose.  But in this case you could simply
> make that frame unsplittable.

Maybe.  How would EWM then split the unsplittable frame?

> Do I understand correctly that a "perspective" is a layout of a frame
> which precludes using or splitting any of the window for another
> purpose?  Can't this be made with current means by using unsplittable
> frames and dedicated windows?  What else do you need?

I need a language to express what I want, not what I don't want.
"unsplittable" and "dedicated" are means to suppress rather than
to express.

> Can you give me an example where `select-window' doesn't do what
> `my-select-window' would do?

When WINDOW is on another frame, `select-window' does not select
that window for input.

ediff needs input focus on the "control-buffer" window.  Otherwise if
you type 'n' it would not jump to next difference but insert 'n' into
your file text.

> 
>  > I was under the impression that it was exactly this problem that you
>  > wanted to solve.  That is how to show some content such that it's
>  > combined with some other content in some reasonable way UI-wise.
> 
> `display-buffer' is too low level to do that.  Any such context
> awareness must be controlled by an application like ediff or GUD via the
> specifiers passed to `display-buffer'.

Question is not "Must it work like that" but "Can it work like that".
Can it?  Last time you were seeing a "great problem".

>  >> Suppose you want
>  >> to write a `display-buffer-function' for ediff-C: How would you know
>  >> where A and B are displayed?
>  >
>  > I would not want to write such function in the first place.
> 
> But you want ediff to use `display-buffer' and you want to intercept
> that via your own function.

Sure, but for all buffers, not just for ediff-C.  If it's the same
function then it knows of course what windows it has already put
earlier and where.  So also A and B.

>  > But the idea is messy:  That the shared resource screen space could
>  > be used without proper synchronization.
> 
> What should be properly synchronized?

Access from elisp packages to the shared resource screen/frame space.

>  > EWM however neither is trying to optimize nor is it non-deterministic
>  > as to where show what window.  It has a more basic problem that it
>  > cannot currently guarantee the live-p-ness of 4 windows as returned
>  > from distinct calls to ewm-display-buffer.
> 
> What exactly is the problem?  Is it that a later call reuses a window
> from an earlier call?  

No.  It is that any layout change destroys all window objects returned
from earlier calls because the frame is re-split from scratch.

 > Does this happen with window-pub?

As well.

Basically what I'd like to have is window-objects that can exist
regardless whether or not they are part of the currently displayed
window tree.

> 
> martin
> 

Re: The window-pub branch

[martin rudalics]

 >> On the GUD frame only, I suppose.  But in this case you could simply
 >> make that frame unsplittable.
 >
 > Maybe.  How would EWM then split the unsplittable frame?

With the `split-unsplittable-frame' specifier.

 > I need a language to express what I want, not what I don't want.
 > "unsplittable" and "dedicated" are means to suppress rather than
 > to express.

An unsplittable frame is a frame that preserves its integrity and a
dedicated window is one that preserves its buffer.  Would rewriting the
documentation make you happy?

 > When WINDOW is on another frame, `select-window' does not select
 > that window for input.

A bug.  How do you make it happen?

 > ediff needs input focus on the "control-buffer" window.  Otherwise if
 > you type 'n' it would not jump to next difference but insert 'n' into
 > your file text.

Do you want to keep the file text window selected and redirect input to
the control window?

 >> `display-buffer' is too low level to do that.  Any such context
 >> awareness must be controlled by an application like ediff or GUD via the
 >> specifiers passed to `display-buffer'.
 >
 > Question is not "Must it work like that" but "Can it work like that".
 > Can it?  Last time you were seeing a "great problem".

I still do.  That is, keeping the customization interface simple and
providing everything that's need by an application is problematic.

 >> What should be properly synchronized?
 >
 > Access from elisp packages to the shared resource screen/frame space.

So far this has been based on a high-level (`display-buffer') interface
and a low-level (`split-window', `delete-window' and
`set-window-buffer') interface.  The former should be used wherever
possible so a user can customize it.  Whether we can fully get rid of
the latter is not yet clear to me.  It's also a question of backward
compatibility and whether we find the people to write it.  Moreover, I
still don't know whether the normal action of C-x b should be affected
by the `display-buffer' options.

 > No.  It is that any layout change destroys all window objects returned
 > from earlier calls because the frame is re-split from scratch.

A frame is never split.  Splitting a window cannot destroy a window
(object).

 >  > Does this happen with window-pub?
 >
 > As well.

As long as you don't give me a recipe I won't believe you.

 > Basically what I'd like to have is window-objects that can exist
 > regardless whether or not they are part of the currently displayed
 > window tree.

That's a different issue.  Fitting such an object into an existing
window configuration would probably lose most of that object's
properties.  Window configurations are, however, an approximation of
what you want (even if you don't like them).

martin

Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > I need a language to express what I want, not what I don't want.
>  > "unsplittable" and "dedicated" are means to suppress rather than
>  > to express.
> 
> An unsplittable frame is a frame that preserves its integrity and a
> dedicated window is one that preserves its buffer.  Would rewriting the
> documentation make you happy?

What about the "integrity" of GUD when its attempts to split fail
altogether?  Would rewriting the documentation make GUD happy?

>  > When WINDOW is on another frame, `select-window' does not select
>  > that window for input.
> 
> A bug.  How do you make it happen?

Open a second frame, show *scratch*, go to the first frame, show
some file, type
	M-: (select-window (get-buffer-window "*scratch*" t))
type some more chars.

For me, chars go to file (GTK and MS-Windows).

>  > ediff needs input focus on the "control-buffer" window.  Otherwise if
>  > you type 'n' it would not jump to next difference but insert 'n' into
>  > your file text.
> 
> Do you want to keep the file text window selected and redirect input to
> the control window?

I don't use ediff (horrible UI and all).  However if you know how
to improve it you might talk to the ediff people ;)

>  >> `display-buffer' is too low level to do that.  Any such context
>  >> awareness must be controlled by an application like ediff or GUD via 
> the
>  >> specifiers passed to `display-buffer'.
>  >
>  > Question is not "Must it work like that" but "Can it work like that".
>  > Can it?  Last time you were seeing a "great problem".
> 
> I still do.  That is, keeping the customization interface simple and
> providing everything that's need by an application is problematic.

Understandable, since the problem turns out to be difficult, the
assumption is easily made that it must be solved by applications
themselves.

However if anything has only limited awareness of the context then
it's the application.  Except of course when it's the only application
on the entire frame.  In which case there is nothing to solve because
that already works.

>  >> What should be properly synchronized?
>  >
>  > Access from elisp packages to the shared resource screen/frame space.
> 
> So far this has been based on a high-level (`display-buffer') interface
> and a low-level (`split-window', `delete-window' and
> `set-window-buffer') interface.  The former should be used wherever
> possible so a user can customize it.  Whether we can fully get rid of
> the latter is not yet clear to me.  It's also a question of backward
> compatibility and whether we find the people to write it.  Moreover, I
> still don't know whether the normal action of C-x b should be affected
> by the `display-buffer' options.

Sure, I know that.  I was just interested in how far you got.
Maybe you have some snippet that people can try at some point.

>  > No.  It is that any layout change destroys all window objects returned
>  > from earlier calls because the frame is re-split from scratch.
> 
> A frame is never split.  Splitting a window cannot destroy a window
> (object).
> 
>  >  > Does this happen with window-pub?
>  >
>  > As well.
> 
> As long as you don't give me a recipe I won't believe you.

See also "How it works" on top of ewm.el:
http://lists.gnu.org/archive/html/gnu-emacs-sources/2010-05/msg00026.html

Recipe:
- visit ewm.el
- M-x eval-buffer
- M-: (selected-window)
   #<window 15 on ewm.el>
- F9 ;; compilation window opens
- M-: (selected-window)
   #<window 21 on ewm.el>

So well, it's a bit magic.  UI-wise you're still in the same window with
'ewm.el' but in fact it's different and the old one (#15) is not live-p
anymore.

>  > Basically what I'd like to have is window-objects that can exist
>  > regardless whether or not they are part of the currently displayed
>  > window tree.
> 
> That's a different issue.  Fitting such an object into an existing
> window configuration would probably lose most of that object's
> properties.  Window configurations are, however, an approximation of
> what you want (even if you don't like them).

I don't work with approximations.  The less in free software.

> 
> martin
> 

RE: The window-pub branch

[Drew Adams]

> >  > When WINDOW is on another frame, `select-window' does not select
> >  > that window for input.
> > 
> > A bug.  How do you make it happen?
> 
> Open a second frame, show *scratch*, go to the first frame, show
> some file, type
> 	M-: (select-window (get-buffer-window "*scratch*" t))
> type some more chars.
> For me, chars go to file (GTK and MS-Windows).

Selecting a window during `M-:' does not leave its frame with the input focus
after `M-:' is finished.  When you type the chars the file frame again has the
focus.

However, if you eval this in the file frame, the result is as you expected: the
text is inserted in `*scratch*':

M-: (progn (select-window (get-buffer-window "*scratch*" t))
           (insert "ABCDE"))

Re: The window-pub branch

[grischka]

Drew Adams wrote:
> Selecting a window during `M-:' does not leave its frame with the input focus
> after `M-:' is finished.  When you type the chars the file frame again has the
> focus.

Fortunately, emacs has at least to functions to select a frame
also:  One that might select it and one that might not select it.

Re: The window-pub branch

[grischka]

grischka wrote:
> Recipe:
> - visit ewm.el
> - M-x eval-buffer

I think window-pub needs a newer version (ediff stuff included):
http://lists.gnu.org/archive/html/gnu-emacs-sources/2010-12/msg00000.html

Re: The window-pub branch

[martin rudalics]

 > I think window-pub needs a newer version

I finally managed to pull something together.  Please have a look at the
usual place.

martin

Re: The window-pub branch

[martin rudalics]

 >> An unsplittable frame is a frame that preserves its integrity and a
 >> dedicated window is one that preserves its buffer.  Would rewriting the
 >> documentation make you happy?
 >
 > What about the "integrity" of GUD when its attempts to split fail
 > altogether?  Would rewriting the documentation make GUD happy?

Note that you can always tweak specifiers in a way such that displaying
buffers fails iff the current way of splitting would fail as well.  Just
that `display-buffer' is less convenient for the application programmer.

 > Open a second frame, show *scratch*, go to the first frame, show
 > some file, type
 >     M-: (select-window (get-buffer-window "*scratch*" t))
 > type some more chars.
 >
 > For me, chars go to file (GTK and MS-Windows).

A clear bug IMHO.  The command loop must switch focus here.

 > However if anything has only limited awareness of the context then
 > it's the application.

So you _do_ want to embed ediff windows in your frame layout?

 > Sure, I know that.  I was just interested in how far you got.
 > Maybe you have some snippet that people can try at some point.

I'll push my recent changes by the end of the week, hopefully.

 > Recipe:
 > - visit ewm.el
 > - M-x eval-buffer
 > - M-: (selected-window)
 >   #<window 15 on ewm.el>
 > - F9 ;; compilation window opens
 > - M-: (selected-window)
 >   #<window 21 on ewm.el>
 >
 > So well, it's a bit magic.  UI-wise you're still in the same window with
 > 'ewm.el' but in fact it's different and the old one (#15) is not live-p
 > anymore.

I think ECB has the same problem.  It's very annoying when you have
overlays with a window property.  These won't apply any more after the
change.

martin

RE: The window-pub branch

[Drew Adams]

>> Open a second frame, show *scratch*, go to the first frame, show
>> some file, type M-: (select-window (get-buffer-window "*scratch*" t))
>> type some more chars.
>>
>> For me, chars go to file (GTK and MS-Windows).
> 
> A clear bug IMHO.  The command loop must switch focus here.

A clear bug?  Why?  It all depends what the intention (design) of `M-:' is.  It
sounds like you are trying to redesign it.

Yes, Lisp evaluation can have side effects, but AFAIK this behavior for `M-:'
was intentional.  `M-:' was meant to evaluate a sexp in a one-off operation, but
keep the input focus etc. where it was.  I think it has behaved this way since
Day One, and the behavior makes sense, to me at least.

IMO this has nothing to do with your surrounding window discussion; this part is
only about the interactive behavior of command `eval-expression'.

(But I admit that I don't even use `eval-expression' for `M-:' - I use
`pp-eval-expression' instead (or something similar) for `M-:'.)

Re: The window-pub branch

[grischka]

Drew Adams wrote:
>>> Open a second frame, show *scratch*, go to the first frame, show
>>> some file, type M-: (select-window (get-buffer-window "*scratch*" t))
>>> type some more chars.
>>>
>>> For me, chars go to file (GTK and MS-Windows).
>> A clear bug IMHO.  The command loop must switch focus here.
> 
> A clear bug?  Why?  It all depends what the intention (design) of `M-:' is.  It
> sounds like you are trying to redesign it.
> 
> Yes, Lisp evaluation can have side effects, but AFAIK this behavior for `M-:'
> was intentional.  `M-:' was meant to evaluate a sexp in a one-off operation, but
> keep the input focus etc. where it was.  I think it has behaved this way since
> Day One, and the behavior makes sense, to me at least.

Then what about
     M-: (display-buffer "*scratch*" nil t)
which does indeed select the window on the other frame and switch focus.

While it is documented as
     (display-buffer BUFFER-OR-NAME &optional NOT-THIS-WINDOW FRAME)
     Make buffer BUFFER-OR-NAME appear in some window but !!! don't select !!! it.

Whereas 'select-window'
     (select-window WINDOW &optional NORECORD)
     Select WINDOW.  Most editing will apply to WINDOW's buffer.

does NOT select the window to apply my editing.

What are the intentions you see and how do they make sense to you?
Just curious ...

> IMO this has nothing to do with your surrounding window discussion; this part is
> only about the interactive behavior of command `eval-expression'.
> 
> (But I admit that I don't even use `eval-expression' for `M-:' - I use
> `pp-eval-expression' instead (or something similar) for `M-:'.)

RE: The window-pub branch

[Drew Adams]

> Then what about
>      M-: (display-buffer "*scratch*" nil t)
> which does indeed select the window on the other frame and 
> switch focus.

(I guess you mean also, like before, put *scratch* and some other buffer in
separate frames, and do that from the non-*scratch* frame.)

> While it is documented as
>      (display-buffer BUFFER-OR-NAME &optional NOT-THIS-WINDOW FRAME)
>      Make buffer BUFFER-OR-NAME appear in some window but !!! 
> don't select !!! it.

Seems like a `display-buffer' bug to me - independent of `M-:'.

Put that sexp in *scratch*, change the buffer name to that of the other buffer
(in the other frame), use `C-x C-e', and you get the same behavior: the window
in the non-*scratch* frame gets selected and the non-*scratch* frame gets the
input focus.

I agree that this behavior seems to contradict the doc string for
`display-buffer', which says (for FRAME) "If the buffer is already displayed in
some window on one of these frames simply return that window" in addition to
"but don't select it".

And this behavior is the same at least as far back as Emacs 20.  So I don't have
a good answer for you about the intention wrt `display-buffer'.  It seems to me
that this is a (longstanding) behavior bug.  But maybe someone will argue that
the doc is wrong instead (and has been wrong an equally long time).  Or maybe
someone will show us how the behavior actually corresponds perfectly to the doc.
;-)

But again I don't see this as related to M-:.  I especially don't see this as a
good reason to change the behavior of M-:.

> Whereas 'select-window'
>      (select-window WINDOW &optional NORECORD)
>      Select WINDOW.  Most editing will apply to WINDOW's buffer.
> does NOT select the window to apply my editing.

`select-window' _does_ select the window for your editing - see my earlier mail.
It's just that `M-:' returns the window selection to what it was before it was
invoked.

Concentrate on your windows discussion and `display-buffer', not on `M-:', which
is a particular user command.  `M-:' is not the way to test whether
`select-window' (or anything else) does what is expected of it.  You are using
not only `select-window' but also `M-:'.

> What are the intentions you see and how do they make sense to you?
> Just curious ...
> 
> > IMO this has nothing to do with your surrounding window 
> > discussion; this part is only about the interactive behavior
> > of command `eval-expression'.

Re: The window-pub branch

[martin rudalics]

 > A clear bug?  Why?

Because the doc-string of `select-window' says that "Most editing will
apply to WINDOW's buffer" and that of `selected-window' says "The
selected window is the window ... to which many commands apply".

Moreover the modeline of the *scratch* window indicates that the window
is selected (which is completely disconcerting when the two frames do
not overlap) while input goes to the other frame.

Admittedly, the doc-string of `select-frame' says that "If you are using
a window system, the previously selected frame may be restored as the
selected frame when returning to the command loop, because it still may
have the window system's input focus.".  But I cannot give a frame input
focus every time I select a window.  Hence I have to rely on the command
loop to tell the window manager that the selected window's frame should
get focus.

Due to this behavior `display-buffer', when popping up a new frame, has
to select that frame although by design it should not change the
selected window.  Also, due to this bug `display-buffer-other-frame'
never worked as Richard intended.

 > Yes, Lisp evaluation can have side effects, but AFAIK this behavior for `M-:'
 > was intentional.  `M-:' was meant to evaluate a sexp in a one-off operation, but
 > keep the input focus etc. where it was.  I think it has behaved this way since
 > Day One, and the behavior makes sense, to me at least.
 >
 > IMO this has nothing to do with your surrounding window discussion; this part is
 > only about the interactive behavior of command `eval-expression'.
 >
 > (But I admit that I don't even use `eval-expression' for `M-:' - I use
 > `pp-eval-expression' instead (or something similar) for `M-:'.)

The problem is within the interaction between Emacs and the window
manager.  It does not depend on M-:.

martin

RE: The window-pub branch

[Drew Adams]

> > > M-: (select-window (get-buffer-window "*scratch*" t))
...
> > A clear bug?  Why?
> 
> Because the doc-string of `select-window' says that "Most editing will
> apply to WINDOW's buffer" and that of `selected-window' says "The
> selected window is the window ... to which many commands apply".

And all of that is true.  But you are not using only `select-window' here.  You
are using `select-window' in the context of `M-:', that is, in the context of a
command.

Imagine if I told you that there was a bug in `select-window' just because
evaluating this sexp doesn't end up with buffer foo's window being selected:

(save-selected-window (select-window (get-buffer-window "foo")))

You would say I'm nuts: `select-window' does select foo's window, but then the
original window selection gets restored by `save-selected-window'.

M-: is like that.  `select-window' _does_ select the window in your test case.
But M-: then restores the original window selection and frame focus.

And you can see this clearly with the example I gave: just use (progn
(select-window...) (insert "TEXT")).

When you use M-: you are not just evaluating a sexp.  You are using a command
that evaluates a sexp and then restores the window selection.  If you want to
test the behavior of `select-window' then don't bring other stuff into the mix
as well.

> Moreover the modeline of the *scratch* window indicates that 
> the window is selected

Which it is.  This is just further proof of that fact.

> (which is completely disconcerting when the two frames do
> not overlap) while input goes to the other frame.

No, input does not go to the other frame.  Not during the evaluation of the sexp
given to M-:.  It is only _after_ M-: is finished that further input goes to the
window that was originally selected.

Do the text inserting in the sexp passed to M-: and you will see that it goes
where you expect.  Do the text inserting after M-: and it goes in the window
that was selected before (and after) M-:.

> The problem is within the interaction between Emacs and the window
> manager.  It does not depend on M-:.

What problem?  The fact that _after_ M-: the same window is selected as before
it?  That behavior certainly _does_ depend on M-:.

You have not shown any bug in `select-window'.  You've just gotten confused
because M-: does not only evaluate a sexp.  Take M-: out of the equation and
then try to demonstrate the supposed `select-window' bug.

Re: The window-pub branch

[martin rudalics]

 > But M-: then restores the original window selection and frame focus.

No.  The frame focus is never changed so it is not restored.

 > When you use M-: you are not just evaluating a sexp.  You are using a command
 > that evaluates a sexp and then restores the window selection.  If you want to
 > test the behavior of `select-window' then don't bring other stuff into the mix
 > as well.

So what about

C-x 2
M-: (select-window (next-window))

 >> Moreover the modeline of the *scratch* window indicates that
 >> the window is selected
 >
 > Which it is.  This is just further proof of that fact.

That I'm "using a command that evaluates a sexp and then restores the
window selection"?

 > No, input does not go to the other frame.  Not during the evaluation of the sexp
 > given to M-:.  It is only _after_ M-: is finished that further input goes to the
 > window that was originally selected.

Even in the C-x 2 example?

 >> The problem is within the interaction between Emacs and the window
 >> manager.  It does not depend on M-:.
 >
 > What problem?  The fact that _after_ M-: the same window is selected as before
 > it?  That behavior certainly _does_ depend on M-:.
 >
 > You have not shown any bug in `select-window'.

Indeed.

 > You've just gotten confused
 > because M-: does not only evaluate a sexp.  Take M-: out of the equation and
 > then try to demonstrate the supposed `select-window' bug.

It's a bug in the command loop.  I can exhibit the same bug using
`select-window' or `select-frame'.

martin

RE: The window-pub branch

[Drew Adams]

> So what about
> C-x 2
> M-: (select-window (next-window))

Dunno.  Maybe _that_ demonstrates a M-: bug.
Or not (below you indicate that you've found a command-loop bug).

I suggest (again) that you take M-: out of the mix while trying to figure out if
there are `select-window' or `display-buffer' or command-loop bugs.  Jumping off
to "fix" M-: is not the way to _start_.

>  >> Moreover the modeline of the *scratch* window indicates that
>  >> the window is selected
>  >
>  > Which it is.  This is just further proof of that fact.
> 
> That I'm "using a command that evaluates a sexp and then restores the
> window selection"?

No, that the *scratch* window was in fact selected.  That was the question
(remember?).  It was claimed that the window wasn't being selected, as
demonstrated by text insertion not going there.

>  > No, input does not go to the other frame.  Not during the 
>  > evaluation of the sexp given to M-:.  It is only _after_
>  > M-: is finished that further input goes to the
>  > window that was originally selected.
> 
> Even in the C-x 2 example?

There is no other frame in your C-x 2 example.  But yes, the `select-window'
still _does_ select the window.  Again, use (progn (select-window...) (insert
"ABC")) to see that.

Your C-x 2 example shows that M-: does not always _restore_ the window
selection.  But it does not show that `select-window' does not select the window
for insertion.

But again, I think your conversation is not about M-:.  The original M-: example
was supposed to demonstrate a bug in `select-window'.  My point was that it does
not do that.  When you use M-: you introduce additional behavior - you are not
just testing evaluation of a `select-window' sexp.

>  >> The problem is within the interaction between Emacs and the window
>  >> manager.  It does not depend on M-:.
>  >
>  > What problem?  The fact that _after_ M-: the same window 
>  > is selected as before it?  That behavior certainly _does_
>  > depend on M-:.
>  >
>  > You have not shown any bug in `select-window'.
> 
> Indeed.

So I guess we are agreed on that, at least.  A bug in `select-window' should be
demonstrated without recourse to M-:.

It's quite possible that there are bugs in all of M-:, select-window, and
display-buffer, but they should be diagnosed separately.

>  > You've just gotten confused because M-: does not only
>  > evaluate a sexp.  Take M-: out of the equation and
>  > then try to demonstrate the supposed `select-window' bug.
> 
> It's a bug in the command loop.  I can exhibit the same bug using
> `select-window' or `select-frame'.

Great, so you've found your answer.  After fixing that problem you can revisit
the M-: behavior to see if you still think that M-: itself needs fixing.

I'm outta here.  As I said, I don't even bind M-: to `eval-expression'
personally, so I shouldn't really care whether or not you "fix" it to become
something different.

Customizations and diff-list Re: The window-pub branch

[Tom Breton (Tehom)]

> With `display-buffer-names' a user can set the `override' specifier so
> this is no problem.  What's difficult is how to merge back or dismiss a
> value changed by the application.  Consider the following scenario:
>
> (1) The user customizes and saves the value of an option back to her
>      .emacs.
>
> (2) The application adds or changes an entry of the option and, assisted
>      by some extraordinary magic, manages to merge the new value into the
>      option without breaking anything.
>
> (3) The user customizes the option again, changing or removing the
>      application's entry.

Straying slightly from the topic, this is very nearly the problem that
custom-diff-list was meant for
(http://www.emacswiki.org/emacs/CustomDiffList, seems to be by Alex
Schroeder)  I don't know that it's available as a library, though.

	Tom Breton (Tehom)

Re: Customizations and diff-list Re: The window-pub branch

[martin rudalics]

 > Straying slightly from the topic, this is very nearly the problem that
 > custom-diff-list was meant for
 > (http://www.emacswiki.org/emacs/CustomDiffList, seems to be by Alex
 > Schroeder)  I don't know that it's available as a library, though.

Something in the sort of what has been addressed there, yes.

Just that the solution shown there works only for lists of scalar
elements.  It doesn't descend into elements and thus cannot find
elements that have evolved differently in .emacs and the default.

And even if I had a solution for that I would need a strategy for when
and how to apply it and how to revert from earlier applications.  Users
are expected to read NEWS and run `customize-changed-options' whenever
they download a new version of Emacs.  Apart from that they are
completely on their own when dealing with options whose value changed.

martin

bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

Severity: wishlist

The subject line says it all: could we get a `window-selected-hook' or
`window-selected-functions' or something?

Use case: I wanted to make myself a command to select the last selected
window (i.e., repeating the command would toggle between two windows).

After some head-scratching, the best I could come up with is this:

(defun .goto-mru-window ()
  (interactive)
  (select-window (frame-parameter nil '.last-selected-window)))

(defadvice select-window (before .save-selected-window activate)
  (set-frame-parameter nil '.last-selected-window (selected-window)))

...which seems to work most of the time, but using an advice doesn't
feel that great, esp. with C functions.

  Štěpán

bug#7381: 24.0.50; Provide a hook run when a window is selected

[martin rudalics]

 > Use case: I wanted to make myself a command to select the last selected
 > window (i.e., repeating the command would toggle between two windows).
 >
 > After some head-scratching, the best I could come up with is this:
 >
 > (defun .goto-mru-window ()
 >   (interactive)
 >   (select-window (frame-parameter nil '.last-selected-window)))
 >
 > (defadvice select-window (before .save-selected-window activate)
 >   (set-frame-parameter nil '.last-selected-window (selected-window)))
 >
 > ...which seems to work most of the time, but using an advice doesn't
 > feel that great, esp. with C functions.

You might want to have a look at my window-pub branch.  It has

window-use-time is a built-in function in `window.c'.

(window-use-time &optional WINDOW)

Return WINDOW's use time.
WINDOW defaults to the selected window.  The window with the highest use
time is the most recently selected one.  The window with the lowest use
time is the least recently selected one.

and

get-mru-window is a compiled Lisp function in `window.el'.

(get-mru-window &optional ALL-FRAMES)

Return the most recently used window on frames specified by ALL-FRAMES.
Do not return a minibuffer window.

The following non-nil values of the optional argument ALL-FRAMES
have special meanings:

- t means consider all windows on all existing frames.

- `visible' means consider all windows on all visible frames.

- 0 (the number zero) means consider all windows on all visible
     and iconified frames.

- A frame means consider all windows on that frame only.

Any other value of ALL-FRAMES means consider all windows on the
selected frame and no others.

martin

bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> Use case: I wanted to make myself a command to select the last selected
>> window (i.e., repeating the command would toggle between two windows).
>>
>> After some head-scratching, the best I could come up with is this:
>>
>> (defun .goto-mru-window ()
>>   (interactive)
>>   (select-window (frame-parameter nil '.last-selected-window)))
>>
>> (defadvice select-window (before .save-selected-window activate)
>>   (set-frame-parameter nil '.last-selected-window (selected-window)))
>>
>> ...which seems to work most of the time, but using an advice doesn't
>> feel that great, esp. with C functions.
>
> You might want to have a look at my window-pub branch.  It has
>
> window-use-time is a built-in function in `window.c'.
>
> (window-use-time &optional WINDOW)
>
> Return WINDOW's use time.
> WINDOW defaults to the selected window.  The window with the highest use
> time is the most recently selected one.  The window with the lowest use
> time is the least recently selected one.
>
> and
>
> get-mru-window is a compiled Lisp function in `window.el'.
>
> (get-mru-window &optional ALL-FRAMES)
>
> Return the most recently used window on frames specified by ALL-FRAMES.
> Do not return a minibuffer window.
>
> The following non-nil values of the optional argument ALL-FRAMES
> have special meanings:
>
> - t means consider all windows on all existing frames.
>
> - `visible' means consider all windows on all visible frames.
>
> - 0 (the number zero) means consider all windows on all visible
>     and iconified frames.
>
> - A frame means consider all windows on that frame only.
>
> Any other value of ALL-FRAMES means consider all windows on the
> selected frame and no others.

This is great, thank you! I'll have a look.

Any reason not to have `get-mru-window' in the trunk (I actually
searched for exactly that before resorting to the advice hack)?

(And I guess the hook proposal still stands as well, or are there any
arguments against that? One might want to do other things triggered by
window selection.)

  Štěpán

bug#7381: 24.0.50; Provide a hook run when a window is selected

[martin rudalics]

 > Any reason not to have `get-mru-window' in the trunk (I actually
 > searched for exactly that before resorting to the advice hack)?

In general it's not very useful because the mru-window is usually the
selected one (unless it was selected with NORECORD non-nil).  I use it
only in `delete-other-windows' when the selected window gets deleted.

 > (And I guess the hook proposal still stands as well, or are there any
 > arguments against that? One might want to do other things triggered by
 > window selection.)

Can't you use `window-configuration-change-hook'?

martin

bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> Any reason not to have `get-mru-window' in the trunk (I actually
>> searched for exactly that before resorting to the advice hack)?
>
> In general it's not very useful because the mru-window is usually the
> selected one (unless it was selected with NORECORD non-nil).  I use it
> only in `delete-other-windows' when the selected window gets deleted.

Oh! I misunderstood -- I expected it to return the most recently used
window other than the selected one... Well, as it is now it's not very
useful at all, indeed. :-|

>> (And I guess the hook proposal still stands as well, or are there any
>> arguments against that? One might want to do other things triggered by
>> window selection.)
>
> Can't you use `window-configuration-change-hook'?

I don't see how that would help, as the hook is not run when a window is
selected.

So I'm still stuck with the advice... I guess I could at least use your
`window-use-time' to manually sort the windows and select the one with
the next-to-highest value.

  Štěpán

bug#7381: 24.0.50; Provide a hook run when a window is selected

[martin rudalics]

 >> Can't you use `window-configuration-change-hook'?
 >
 > I don't see how that would help, as the hook is not run when a window is
 > selected.

Well, we _could_ run it when another window gets selected.  But at the
time we'd run it the identity of the old selected window would not be
available anywhere.  So this wouldn't help you much either.

Basically, we could keep the old window configuration around from one
"change" to the next but it's not clear whether we want to save the
configuration before the last command or before the last configuration
change.  In the latter case, your code would hardly know whether it runs
within one and the same command or within different commands.

Note in this context that a single command like setting up a GDB frame
may entail a couple of configuration changes and you would have to keep
track of all of them.  And the hook would trigger within each and every
instance of `with-selected-window' or `save-window-excursion' no matter
how silly these macros are occasionally used.

martin

bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>>> Can't you use `window-configuration-change-hook'?
>>
>> I don't see how that would help, as the hook is not run when a window is
>> selected.
>
> Well, we _could_ run it when another window gets selected.  But at the
> time we'd run it the identity of the old selected window would not be
> available anywhere. [...]

Right, but I don't consider that too much of a problem -- I could always
save the last two windows instead of just the last one, for instance.

But I really don't think extending `w-c-c-hook' is the right
solution. I don't see why just selecting another window should be
considered a window configuration change... 

> Basically, we could keep the old window configuration around from one
> "change" to the next but it's not clear whether we want to save the
> configuration before the last command or before the last configuration
> change.  In the latter case, your code would hardly know whether it runs
> within one and the same command or within different commands.
>
> Note in this context that a single command like setting up a GDB frame
> may entail a couple of configuration changes and you would have to keep
> track of all of them.  And the hook would trigger within each and every
> instance of `with-selected-window' or `save-window-excursion' no matter
> how silly these macros are occasionally used.

...and these caveats seem only to confirm such doubts (although some of
them would apply to lesser extent to the hypothetical
`select-window'-specific hook as well).

What's wrong with a separate `window-selected-hook' or perhaps
`select-window-hook'?

[On a related note, it would be nice if there were some clean and simple
way to define custom hooks attached to arbitrary functions; that would
solve problems similar to this one, preventing discussions whether adding
yet another hook is worth it or not. Something like:

  (define-function-hook 'select-window)
  => select-window-hook

  (add-hook 'select-window-hook ...)

Dream on...]

  Štěpán

bug#7381: 24.0.50; Provide a hook run when a window is selected

[martin rudalics]

 > But I really don't think extending `w-c-c-hook' is the right
 > solution. I don't see why just selecting another window should be
 > considered a window configuration change...

Agreed.

 >> Basically, we could keep the old window configuration around from one
 >> "change" to the next but it's not clear whether we want to save the
 >> configuration before the last command or before the last configuration
 >> change.  In the latter case, your code would hardly know whether it runs
 >> within one and the same command or within different commands.
 >>
 >> Note in this context that a single command like setting up a GDB frame
 >> may entail a couple of configuration changes and you would have to keep
 >> track of all of them.  And the hook would trigger within each and every
 >> instance of `with-selected-window' or `save-window-excursion' no matter
 >> how silly these macros are occasionally used.
 >
 > ...and these caveats seem only to confirm such doubts (although some of
 > them would apply to lesser extent to the hypothetical
 > `select-window'-specific hook as well).

I'm afraid they would apply to the same extent.

 > What's wrong with a separate `window-selected-hook' or perhaps
 > `select-window-hook'?

Nothing but the fact that it might not help you very much.  Your use
case was formulated in terms of commands

 > ... repeating the command would toggle between two windows ...

and not in terms of window selections.  So I don't think that Lennart's
proposal of using a `post-command-hook' here is unreasonable ;-)

 > [On a related note, it would be nice if there were some clean and simple
 > way to define custom hooks attached to arbitrary functions; that would
 > solve problems similar to this one, preventing discussions whether adding
 > yet another hook is worth it or not. Something like:
 >
 >   (define-function-hook 'select-window)
 >   => select-window-hook
 >
 >   (add-hook 'select-window-hook ...)
 >
 > Dream on...]

Hooks can be dangerous.  It's very easy to crash Emacs by putting some
innocuously looking function on `window-configuration-change-hook'.

BTW, I could give `get-mru-window' an additional argument like

(defun get-mru-window (&optional all-frames avoid-selected)
    (let (best-window best-time time)
     (dolist (window (window-list-1 nil nil all-frames))
       (setq time (window-use-time window))
       (unless (and avoid-selected
		   (eq (window (selected-window))))
	(when (or (not best-time) (> time best-time))
	  (setq best-time time)
	  (setq best-window window))))
     best-window))

which would return nil if the selected window is the only one on
ALL-FRAMES.

martin

bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>>> Basically, we could keep the old window configuration around from one
>>> "change" to the next but it's not clear whether we want to save the
>>> configuration before the last command or before the last configuration
>>> change.  In the latter case, your code would hardly know whether it runs
>>> within one and the same command or within different commands.
>>>
>>> Note in this context that a single command like setting up a GDB frame
>>> may entail a couple of configuration changes and you would have to keep
>>> track of all of them.  And the hook would trigger within each and every
>>> instance of `with-selected-window' or `save-window-excursion' no matter
>>> how silly these macros are occasionally used.
>>
>> ...and these caveats seem only to confirm such doubts (although some of
>> them would apply to lesser extent to the hypothetical
>> `select-window'-specific hook as well).
>
> I'm afraid they would apply to the same extent.

Hm. Would they? A lot of window configuration changes don't involve
changing the selected window.

>> What's wrong with a separate `window-selected-hook' or perhaps
>> `select-window-hook'?
>
> Nothing but the fact that it might not help you very much.  Your use
> case was formulated in terms of commands
>
>> ... repeating the command would toggle between two windows ...
>
> and not in terms of window selections.  So I don't think that Lennart's
> proposal of using a `post-command-hook' here is unreasonable ;-)

No, my use case is really about the previous selected window (on a given
frame), not specific commands. `select-window' is not even a command.
Checking after each and every command if by any chance we changed the
selected window does seem rather unreasonable to me. I'd much rather
have a `select-window-hook' and keep track of the two last selected
windows.

>> [On a related note, it would be nice if there were some clean and simple
>> way to define custom hooks attached to arbitrary functions; that would
>> solve problems similar to this one, preventing discussions whether adding
>> yet another hook is worth it or not. Something like:
>>
>>   (define-function-hook 'select-window)
>>   => select-window-hook
>>
>>   (add-hook 'select-window-hook ...)
>>
>> Dream on...]
>
> Hooks can be dangerous.  It's very easy to crash Emacs by putting some
> innocuously looking function on `window-configuration-change-hook'.

Well, I don't find that very persuasive. It's not like Emacs lacks other
ways to shoot yourself in the foot, and you can already achieve about
the same (minus the "clean and simple" part) using advice.

> BTW, I could give `get-mru-window' an additional argument like
>
> (defun get-mru-window (&optional all-frames avoid-selected)
>    (let (best-window best-time time)
>     (dolist (window (window-list-1 nil nil all-frames))
>       (setq time (window-use-time window))
>       (unless (and avoid-selected
> 		   (eq (window (selected-window))))
> 	(when (or (not best-time) (> time best-time))
> 	  (setq best-time time)
> 	  (setq best-window window))))
>     best-window))
>
> which would return nil if the selected window is the only one on
> ALL-FRAMES.

That'd be great, yeah (and including it in the trunk).

  Štěpán

bug#7381: 24.0.50; Provide a hook run when a window is selected

[martin rudalics]

 > Hm. Would they? A lot of window configuration changes don't involve
 > changing the selected window.

I suppose you want to use a variable, say old-window, where your
remember the previously selected window.  Now if
`window-configuration-change-hook' does not change the selected window,
the selected window and old-window are the same and you don't even care.

Your problem is with things like `save-window-excursion' where the
selected window changes temporarily.

 >> Hooks can be dangerous.  It's very easy to crash Emacs by putting some
 >> innocuously looking function on `window-configuration-change-hook'.
 >
 > Well, I don't find that very persuasive. It's not like Emacs lacks other
 > ways to shoot yourself in the foot, and you can already achieve about
 > the same (minus the "clean and simple" part) using advice.

Using advice is deprecated in the Emacs sources but functions running on
hooks are used.  That's why the latter have to be more robust by design.

 > That'd be great, yeah (and including it in the trunk).

Meanwhile you can simply try out for yourself by adding

DEFUN ("window-use-time", Fwindow_use_time, Swindow_use_time, 0, 1, 0,
        doc: /* Return WINDOW's use time.
WINDOW defaults to the selected window.  The window with the highest use
time is the most recently selected one.  The window with the lowest use
time is the least recently selected one.  */)
      (window)
      Lisp_Object window;
{
   return decode_window (window)->use_time;
}

...

   defsubr (&Swindow_use_time);

to your window.c ;-)

martin

bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

> Meanwhile you can simply try out for yourself by adding
>
> DEFUN ("window-use-time", Fwindow_use_time, Swindow_use_time, 0, 1, 0,
>        doc: /* Return WINDOW's use time.
> WINDOW defaults to the selected window.  The window with the highest use
> time is the most recently selected one.  The window with the lowest use
> time is the least recently selected one.  */)
>      (window)
>      Lisp_Object window;
> {
>   return decode_window (window)->use_time;
> }
>
> ...
>
>   defsubr (&Swindow_use_time);
>
> to your window.c ;-)

That, together with a slightly modified `get-mru-window' definition
(there is no `window-list-1' in the trunk), seems to work just fine for
my purpose.

Thank you very much.

Could `window-use-time' and `get-mru-window' (or at least the former) be
included in the trunk?

  Štěpán

bug#7381: 24.0.50; Provide a hook run when a window is selected

[martin rudalics]

 > Could `window-use-time' and `get-mru-window' (or at least the former) be
 > included in the trunk?

Could you submit the trivial patch for `window-use-time'?  I hardly ever
use the trunk these days, so I'm a bit reluctant to install anything for
it at the moment.

If you have enough space on your disk, testing window-pub would be
obviously a perfect alternative.

martin

bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> Could `window-use-time' and `get-mru-window' (or at least the former) be
>> included in the trunk?
>
> Could you submit the trivial patch for `window-use-time'?  I hardly ever
> use the trunk these days, so I'm a bit reluctant to install anything for
> it at the moment.

Sure. At the end of this mail is what I have in my local trunk copy
now.

> If you have enough space on your disk, testing window-pub would be
> obviously a perfect alternative.

Well, I did checkout that branch (I'm using the Git mirror), but it
seems to include much more changes than `window-use-time' and
`get-mru-window', and the last merge from trunk is from 30. October. You
mean you'd like to merge it into the trunk as a whole in the near
future, so you're looking for more testers?

-- 8< --
Subject: Add a `window-use-time' function.
From: Martin Rudalics <rudalics@gmx.at>

diff --git a/src/window.c b/src/window.c
index 7591401..414354c 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2420,6 +2420,17 @@ check_all_windows (void)
   window_loop (CHECK_ALL_WINDOWS, Qnil, 1, Qt);
 }

+DEFUN ("window-use-time", Fwindow_use_time, Swindow_use_time, 0, 1, 0,
+       doc: /* Return WINDOW's use time.
+WINDOW defaults to the selected window.  The window with the highest use
+time is the most recently selected one.  The window with the lowest use
+time is the least recently selected one.  */)
+     (window)
+     Lisp_Object window;
+{
+  return decode_window (window)->use_time;
+}
+
 DEFUN ("get-lru-window", Fget_lru_window, Sget_lru_window, 0, 2, 0,
        doc: /* Return the window least recently selected or used for display.
 \(LRU means Least Recently Used.)
@@ -7216,6 +7227,7 @@ frame to be redrawn only if it is a tty frame.  */);
   defsubr (&Snext_window);
   defsubr (&Sprevious_window);
   defsubr (&Sother_window);
+  defsubr (&Swindow_use_time);
   defsubr (&Sget_lru_window);
   defsubr (&Sget_largest_window);
   defsubr (&Sget_buffer_window);

--
Štěpán

bug#7381: 24.0.50; Provide a hook run when a window is selected

[martin rudalics]

 > Well, I did checkout that branch (I'm using the Git mirror), but it
 > seems to include much more changes than `window-use-time' and
 > `get-mru-window', and the last merge from trunk is from 30. October.

The last time I merged from trunk and pushed back was yesterday so maybe
the Git mirror hasn't been updated yet.

 > You
 > mean you'd like to merge it into the trunk as a whole in the near
 > future, so you're looking for more testers?

I need people who confim that it doesn't break their daily workflow
before merging anything into the trunk.

martin

The window-pub branch (was Re: bug#7381: 24.0.50; Provide a hook run when a window is selected)

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

[moving this to emacs-devel]

>> Well, I did checkout that branch (I'm using the Git mirror), but it
>> seems to include much more changes than `window-use-time' and
>> `get-mru-window', and the last merge from trunk is from 30. October.
>
> The last time I merged from trunk and pushed back was yesterday so maybe
> the Git mirror hasn't been updated yet.
>
>> You
>> mean you'd like to merge it into the trunk as a whole in the near
>> future, so you're looking for more testers?
>
> I need people who confim that it doesn't break their daily workflow
> before merging anything into the trunk.

Alright... I built it and was going to use it, but I hit one
show-stopper immediately: the `split-{height,width}-threshold' variables
seem to be ignored: I have the former set to 80, the latter to 150 and
`pop-up-windows' to t, but with window-pub a 59x158 window is
split vertically, making Emacs pretty much unusable for me.

The docstrings state that the above variables are obsolete and one
should use `display-buffer-names' etc., but I have no idea how to get
the previous correct behaviour (I assume messing with `min-width' and
similar inside `display-buffer-names' might be the way to go, but I
don't see why the obsolete variables should not be respected when the
new ones are nil by default anyway).

  Štěpán

Re: The window-pub branch (was Re: bug#7381: 24.0.50; Provide a hook run when a window is selected)

[martin rudalics]

 > Alright... I built it and was going to use it, but I hit one
 > show-stopper immediately: the `split-{height,width}-threshold' variables
 > seem to be ignored: I have the former set to 80, the latter to 150 and
 > `pop-up-windows' to t, but with window-pub a 59x158 window is
 > split vertically, making Emacs pretty much unusable for me.

Thanks for testing.  I expected you to find a show-stopper earlier.  Do
you mean that 24 lines is to small for a new window (many popped up
windows here are only a few lines tall).

 > The docstrings state that the above variables are obsolete and one
 > should use `display-buffer-names' etc., but I have no idea how to get
 > the previous correct behaviour (I assume messing with `min-width' and
 > similar inside `display-buffer-names' might be the way to go, but I
 > don't see why the obsolete variables should not be respected when the
 > new ones are nil by default anyway).

The new ones are not nil.  `display-buffer-regexps' specifies them as 24
lines and 60 columns for the new window which obviously don't match the
defaults of the trunk.  So please change the default values of the
min-height and min-width specifiers in `display-buffer-regexps'

   '(((".*")
      same-frame
      (reuse-buffer-window . nil)
      (new-window (largest . nil) (lru . nil))
      (min-height . 24) (min-width . 60)
      (even-window-sizes . t)
      other-frame
      (reuse-buffer-window . visible)
      (graphic-only . t)
      (popup-frame-alist
       (height . 24) (width . 80) (unsplittable . t))))

to something more reasonable and tell me about the next show-stopper you
encounter.

Thanks, martin

Re: The window-pub branch

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> Alright... I built it and was going to use it, but I hit one
>> show-stopper immediately: the `split-{height,width}-threshold' variables
>> seem to be ignored: I have the former set to 80, the latter to 150 and
>> `pop-up-windows' to t, but with window-pub a 59x158 window is
>> split vertically, making Emacs pretty much unusable for me.
>
> Thanks for testing.  I expected you to find a show-stopper earlier.  Do
> you mean that 24 lines is to small for a new window (many popped up
> windows here are only a few lines tall).

Well, kind of (more below).

>> The docstrings state that the above variables are obsolete and one
>> should use `display-buffer-names' etc., but I have no idea how to get
>> the previous correct behaviour (I assume messing with `min-width' and
>> similar inside `display-buffer-names' might be the way to go, but I
>> don't see why the obsolete variables should not be respected when the
>> new ones are nil by default anyway).
>
> The new ones are not nil.

Oh... I only checked `display-buffer-names', which is nil by default.

> `display-buffer-regexps' specifies them as 24
> lines and 60 columns for the new window which obviously don't match the
> defaults of the trunk.  So please change the default values of the
> min-height and min-width specifiers in `display-buffer-regexps'
>
>   '(((".*")
>      same-frame
>      (reuse-buffer-window . nil)
>      (new-window (largest . nil) (lru . nil))
>      (min-height . 24) (min-width . 60)
>      (even-window-sizes . t)
>      other-frame
>      (reuse-buffer-window . visible)
>      (graphic-only . t)
>      (popup-frame-alist
>       (height . 24) (width . 80) (unsplittable . t))))
>
> to something more reasonable and tell me about the next show-stopper you
> encounter.

Well, I'm sorry but I'll obviously need some assistance. As I explained,
what I'm used to is this:

            split-height-threshold = 80
            split-width-threshold = 150
            pop-up-windows = t
            fullscreen window width => 158
            fullscreen window height => 59

... meaning that the first new window is automatically split
_horizontally_ (resulting in two windows side by side).

With Emacs from window-pub, even when I change `min-height' in the
default value of `display-buffer-regexps' to 1000 and `min-width' to 10,
I still get a vertical split!

So as I said, I have no idea what "something more reasonable" should
actually look like... :-|

Could you provide a value for `display-buffer-regexps' that should
produce the behaviour I expect (or at least some other kind of sensible
behaviour -- I don't consider preferring vertical splits of a
much-wider-than-high window sensible at all)?

Thank you,

  Štěpán

Re: The window-pub branch

[martin rudalics]

 > With Emacs from window-pub, even when I change `min-height' in the
 > default value of `display-buffer-regexps' to 1000 and `min-width' to 10,
 > I still get a vertical split!
 >
 > So as I said, I have no idea what "something more reasonable" should
 > actually look like... :-|
 >
 > Could you provide a value for `display-buffer-regexps' that should
 > produce the behaviour I expect (or at least some other kind of sensible
 > behaviour -- I don't consider preferring vertical splits of a
 > much-wider-than-high window sensible at all)?

Sorry.  I didn't understand immediately that you wanted to split windows
horizontally.  This is part of code I changed recently and didn't test
yet with non-standard settings :-(

The obvious bug is in the _last_ line of the function
`display-buffer-split-window'.  Please replace

	      window (or side 'below) min-width max-width)))))

by

	      window (or side 'right) min-width max-width)))))

which means "if you didn't specify explicitly where the new window
should go, put it on the right".

martin

Re: The window-pub branch

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

> Sorry.  I didn't understand immediately that you wanted to split windows
> horizontally.  This is part of code I changed recently and didn't test
> yet with non-standard settings :-(
>
> The obvious bug is in the _last_ line of the function
> `display-buffer-split-window'.  Please replace
>
> 	      window (or side 'below) min-width max-width)))))
>
> by
>
> 	      window (or side 'right) min-width max-width)))))
>
> which means "if you didn't specify explicitly where the new window
> should go, put it on the right".

That seems to work, thanks!

Another two glitches I noticed (still just testing with emacs -Q):

1. Automatic vertical window splitting is uneven -- whereas in trunk
Emacs (even with tool- and menu- bars on) one gets evenly (vertically)
split windows, in window-pub the new window is noticeably higher; could
it be that it tries to match height of the new window to the old one
_plus_ the GUI bars and mode line?. Somewhat interestingly, doing a
vertical split manually with `C-x 2' does produce evenly split windows.

2. *Completions* display:
E.g.: C-h f so TAB ; *Completions* window is displayed
      l TAB ; `solitaire' is chosen, *Completions* buffer disappears,
      _but_ the *scratch* buffer takes its place instead of deleting the
      split
      (If you press C-g at this point, the window will be deleted, but
      that still doesn't feel right -- it should be deleted as soon as
      the *Completions* buffer is buried)

  Štěpán

Re: The window-pub branch

[martin rudalics]

 > 1. Automatic vertical window splitting is uneven -- whereas in trunk
 > Emacs (even with tool- and menu- bars on) one gets evenly (vertically)
 > split windows, in window-pub the new window is noticeably higher; could
 > it be that it tries to match height of the new window to the old one
 > _plus_ the GUI bars and mode line?. Somewhat interestingly, doing a
 > vertical split manually with `C-x 2' does produce evenly split windows.

Currently this is by design.  The minimum height of a new window (and
its width) are specified by the min-height (min-width) specifiers and
`display-buffer' tries to make it at least as high (wide) as this at the
expense of the window that was split.  That is, there are two cases:

(1) If the height of the old window is at least as large as two times
     min-height, splitting is done evenly.

(2) If the size of the old window is at least as large as min-height
     plus window-min-height, the new window gets min-height lines and the
     old window the rest.

The purpose of (2) was that applications sometimes want a window with a
specific height and I wanted to accomodate that somehow.

If people think it's not useful or bad, I can easily rewrite that part.
Meanwhile I added an `adjust-height' specifier that allows to directly
specify the desired height so the min-height specifier is probably not
so useful any more.

 > 2. *Completions* display:
 > E.g.: C-h f so TAB ; *Completions* window is displayed
 >       l TAB ; `solitaire' is chosen, *Completions* buffer disappears,
 >       _but_ the *scratch* buffer takes its place instead of deleting the
 >       split
 >       (If you press C-g at this point, the window will be deleted, but
 >       that still doesn't feel right -- it should be deleted as soon as
 >       the *Completions* buffer is buried)

This has been changed recently and I have not yet caught up with that
change.  There's also the problem related by Andrej in another thread.
I'll notify you as soon as I understand what's going on.  Thanks for the
precise test case though, this will make things easier for me.

martin

Re: The window-pub branch

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> 1. Automatic vertical window splitting is uneven -- whereas in trunk
>> Emacs (even with tool- and menu- bars on) one gets evenly (vertically)
>> split windows, in window-pub the new window is noticeably higher; could
>> it be that it tries to match height of the new window to the old one
>> _plus_ the GUI bars and mode line?. Somewhat interestingly, doing a
>> vertical split manually with `C-x 2' does produce evenly split windows.
>
> Currently this is by design.  The minimum height of a new window (and
> its width) are specified by the min-height (min-width) specifiers and
> `display-buffer' tries to make it at least as high (wide) as this at the
> expense of the window that was split.  That is, there are two cases:
>
> (1) If the height of the old window is at least as large as two times
>     min-height, splitting is done evenly.
>
> (2) If the size of the old window is at least as large as min-height
>     plus window-min-height, the new window gets min-height lines and the
>     old window the rest.
>
> The purpose of (2) was that applications sometimes want a window with a
> specific height and I wanted to accomodate that somehow.
>
> If people think it's not useful or bad, I can easily rewrite that part.

Well, it definitely feels very disruptive to me, and from what you write
I don't see a simple way to get rid of that behaviour. I believe at
least `even-window-sizes' should take precedence over the
min-{height-width} settings (or perhaps we could use (even-window-sizes
. force) or something?).

  Štěpán

Re: The window-pub branch

[martin rudalics]

 > Well, it definitely feels very disruptive to me, and from what you write
 > I don't see a simple way to get rid of that behaviour.

The trunk would have refused to split the window in this case (assuming
split-height-threshold = 2 * window-min-height).  I can do the same
here.  Try with

(defun display-buffer-split-window-1 (window side min-size)
   "Subroutine of `display-buffer-split-window'."
   (let* ((horflag (memq side '(left right)))
	 (parent (window-parent window))
	 (resize (and (eq window-splits 'resize)
		      (window-iso-combined-p window horflag)))
	 (old-size
	  ;; We either resize WINDOW or its parent.
	  (window-total-size (if resize parent window) horflag))
	 (new-size
	  (if resize
	      (min (- old-size (window-min-size parent horflag))
		   (/ old-size
		      (1+ (window-iso-combinations parent horflag))))
	    (/ old-size 2))))
     ;; Don't make any of the windows smaller than MIN-SIZE.
     (when (and (> new-size min-size)
	       ;; Check the sizes.
	       (if resize
		   (window-sizable-p parent (- new-size) horflag)
		 (window-sizable-p window (- new-size) horflag)))
       ;; We don't call `split-window-vertically' any more here. If for
       ;; some reason it seems appropriate we can always do so (provided
       ;; we give it an optional SIDE argument).
       (split-window window (- new-size) side))))

 > I believe at
 > least `even-window-sizes' should take precedence over the
 > min-{height-width} settings (or perhaps we could use (even-window-sizes
 > . force) or something?).

In an earlier version I did apply `even-window-sizes' to split windows.
But if I do so, I deliberately ignore the `window-min-height' specifier
(or `split-height-threshold', whatever you prefer to call it) in the
case you mention.  Also, evening out heights is done iff the new window
is smaller than the selected one so it would not apply by default here.

(BTW I hopefully fixed the minibuffer problem in the meantime.  Please
try it when the fix makes it to the git mirror.)

martin

Re: The window-pub branch

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> Well, it definitely feels very disruptive to me, and from what you write
>> I don't see a simple way to get rid of that behaviour.
>
> The trunk would have refused to split the window in this case (assuming
> split-height-threshold = 2 * window-min-height).  I can do the same
> here.  Try with

We're apparently miscommunicating again. I _do_ want the window to be
split, but I also want it to be split _evenly_.

Although the new customization system is definitely more powerful, I'm
still at a loss as to how to use it to preserve even the basic behaviour
I'm used to. That's a serious problem in itself IMHO.[1]

(I don't know if you consider the system advertising-ready as it is now,
but I think in that case there should be either a way to get it to
preserve the old behaviour (i.e. respect the split-*-threshold variables
etc.), or an explanation on how to migrate the old settings to the new
system. Otherwise I can't imagine how even people less dense and more
patient than me are going to be happy with it.)

>> I believe at
>> least `even-window-sizes' should take precedence over the
>> min-{height-width} settings (or perhaps we could use (even-window-sizes
>> . force) or something?).
>
> In an earlier version I did apply `even-window-sizes' to split windows.
> But if I do so, I deliberately ignore the `window-min-height' specifier
> (or `split-height-threshold', whatever you prefer to call it) in the
> case you mention.  Also, evening out heights is done iff the new window
> is smaller than the selected one so it would not apply by default here.

Hm. I won't pretend I really understand what you're saying here. :-)

> (BTW I hopefully fixed the minibuffer problem in the meantime.  Please
> try it when the fix makes it to the git mirror.)

Yes, it's fixed now, thank you!

  Štěpán

[1] To reiterate and put my it more concretely: in the old system I
simply set the `split-*-threshold' variables to specify conditions under
which a window can be split. Then whenever such conditions are satisfied
the windows are split _evenly_. How on Earth do I get this simple
behaviour with window-pub?

Re: The window-pub branch

[martin rudalics]

 > We're apparently miscommunicating again. I _do_ want the window to be
 > split, but I also want it to be split _evenly_.

Sure.  I didn't correctly handle the part where a window can be split
when it's the only window on a frame, regardless of height restrictions.
I checked in a solution, please try whether it works now.

 > Although the new customization system is definitely more powerful, I'm
 > still at a loss as to how to use it to preserve even the basic behaviour
 > I'm used to. That's a serious problem in itself IMHO.[1]

The `display-buffer' part is the last one I added.  It's still partly
under construction.

 > (I don't know if you consider the system advertising-ready as it is now,
 > but I think in that case there should be either a way to get it to
 > preserve the old behaviour (i.e. respect the split-*-threshold variables
 > etc.), or an explanation on how to migrate the old settings to the new
 > system. Otherwise I can't imagine how even people less dense and more
 > patient than me are going to be happy with it.)

Did you read the corresponding section in the Elisp manual?  I tried to
tell there how this can be done.

 >> In an earlier version I did apply `even-window-sizes' to split windows.
 >> But if I do so, I deliberately ignore the `window-min-height' specifier
 >> (or `split-height-threshold', whatever you prefer to call it) in the
 >> case you mention.  Also, evening out heights is done iff the new window
 >> is smaller than the selected one so it would not apply by default here.
 >
 > Hm. I won't pretend I really understand what you're saying here. :-)

The variable `even-window-sizes' applies if and only if (1) a window is
reused for showing the new buffer, (2) the window and the selected
window appear above each other, and (3) both windows are full-width.  (I
removed restriction (3) in window-pub.)  `even-window-sizes' doesn't
apply when a window is split because the trunk always splits a window
into two equally sized halves.

 > [1] To reiterate and put my it more concretely: in the old system I
 > simply set the `split-*-threshold' variables to specify conditions under
 > which a window can be split. Then whenever such conditions are satisfied
 > the windows are split _evenly_. How on Earth do I get this simple
 > behaviour with window-pub?

The case that hit you was not necessarily subject to restrictions
imposed by `split-height-threshold'.  It might have hit in a place where
that variable was bound to zero.  Try to debug `split-window-sensibly'
in the trunk.

I did away with `split-height-threshold' for a number of reasons.  First
of all it makes programmers think in terms of the height of an existing
window and not in terms of the window they need for their buffer.

Moreover, I now allow to split internal windows like a frame's root
window too, so the new window can appear at an arbitrary side of the
frame.  In that case, talking about a `split-height-threshold' hardly
makes sense.

Finally, I currently experiment with a mode where `display-buffer' can
steal the space needed to pop up a new window from several other
windows.  In that case, the new window's size is proportional to the
size of these other windows.  Since I'm using that mode on a daily basis
I didn't see the problem you encountered.

martin

Re: The window-pub branch

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> We're apparently miscommunicating again. I _do_ want the window to be
>> split, but I also want it to be split _evenly_.
>
> Sure.  I didn't correctly handle the part where a window can be split
> when it's the only window on a frame, regardless of height restrictions.
> I checked in a solution, please try whether it works now.

Yes, seems to work fine now, thank you.

>> (I don't know if you consider the system advertising-ready as it is now,
>> but I think in that case there should be either a way to get it to
>> preserve the old behaviour (i.e. respect the split-*-threshold variables
>> etc.), or an explanation on how to migrate the old settings to the new
>> system. Otherwise I can't imagine how even people less dense and more
>> patient than me are going to be happy with it.)
>
> Did you read the corresponding section in the Elisp manual?  I tried to
> tell there how this can be done.

I did now, thank you. (it's in (info "(elisp)Displaying Buffers") for
anyone interested.)

>>> In an earlier version I did apply `even-window-sizes' to split windows.
>>> But if I do so, I deliberately ignore the `window-min-height' specifier
>>> (or `split-height-threshold', whatever you prefer to call it) in the
>>> case you mention.  Also, evening out heights is done iff the new window
>>> is smaller than the selected one so it would not apply by default here.
>>
>> Hm. I won't pretend I really understand what you're saying here. :-)
>
> The variable `even-window-sizes' applies if and only if (1) a window is
> reused for showing the new buffer, (2) the window and the selected
> window appear above each other, and (3) both windows are full-width.  (I
> removed restriction (3) in window-pub.)  `even-window-sizes' doesn't
> apply when a window is split because the trunk always splits a window
> into two equally sized halves.

Now I'm confused even more: we're talking about window-pub here, what
does trunk have to do with it? There's no `even-window-sizes' in trunk
Emacs.

Nevertheless, after reading some more documentation I think I've gained
a better picture of what the variable is supposed to do.

>> [1] To reiterate and put my it more concretely: in the old system I
>> simply set the `split-*-threshold' variables to specify conditions under
>> which a window can be split. Then whenever such conditions are satisfied
>> the windows are split _evenly_. How on Earth do I get this simple
>> behaviour with window-pub?
>
> The case that hit you was not necessarily subject to restrictions
> imposed by `split-height-threshold'.  It might have hit in a place where
> that variable was bound to zero.  Try to debug `split-window-sensibly'
> in the trunk.

Again, I don't understand -- I was complaining about the window-pub
behaviour, so what will I gain by edebugging the trunk Emacs'
`split-window-sensibly'? Anyway, you've now apparently fixed the
problem.

> I did away with `split-height-threshold' for a number of reasons.  First
> of all it makes programmers think in terms of the height of an existing
> window and not in terms of the window they need for their buffer.

Well, as I see it the threshold variables were primarily intended to
provide a simple way for _users_ to customize window splitting, and for
the simple behaviour I describe (i.e. "only split windows if they're at
least this wide or that high") I think their semantics is optimal, and I
still don't see any equivalent in the new system. I guess setting
`min-height' to (/ split-height-threshold 2) with ".*" as a fallback
rule in `display-buffer-regexps' and overriding it in more specific
rules when necessary is as close as it gets?

> Moreover, I now allow to split internal windows like a frame's root
> window too, so the new window can appear at an arbitrary side of the
> frame.  In that case, talking about a `split-height-threshold' hardly
> makes sense.

Um, I don't understand. AIUI you can only split a live window, and the
only internal window that can be live is the root window as the only
window on a frame, right? So what does "arbitrary side of the frame"
mean? When you have a single window, you can split it horizontally or
vertically, but that's about it. What am I missing?

  Štěpán

Re: The window-pub branch

[martin rudalics]

 >> The variable `even-window-sizes' applies if and only if (1) a window is
 >> reused for showing the new buffer, (2) the window and the selected
 >> window appear above each other, and (3) both windows are full-width.  (I
 >> removed restriction (3) in window-pub.)  `even-window-sizes' doesn't
 >> apply when a window is split because the trunk always splits a window
 >> into two equally sized halves.
 >
 > Now I'm confused even more: we're talking about window-pub here, what
 > does trunk have to do with it? There's no `even-window-sizes' in trunk
 > Emacs.

I meant `even-window-heights'.  I use an even-window-sizes specifier
because it applies to the horizontal case as well.

 > Again, I don't understand -- I was complaining about the window-pub
 > behaviour, so what will I gain by edebugging the trunk Emacs'
 > `split-window-sensibly'?

It would have permitted to deduce in which case the window-pub branch
failed to mimic the behavior of the trunk.

 > Well, as I see it the threshold variables were primarily intended to
 > provide a simple way for _users_ to customize window splitting, and for
 > the simple behaviour I describe (i.e. "only split windows if they're at
 > least this wide or that high") I think their semantics is optimal, and I
 > still don't see any equivalent in the new system. I guess setting
 > `min-height' to (/ split-height-threshold 2) with ".*" as a fallback
 > rule in `display-buffer-regexps' and overriding it in more specific
 > rules when necessary is as close as it gets?

Yes.

 >> Moreover, I now allow to split internal windows like a frame's root
 >> window too, so the new window can appear at an arbitrary side of the
 >> frame.  In that case, talking about a `split-height-threshold' hardly
 >> makes sense.
 >
 > Um, I don't understand. AIUI you can only split a live window, and the
 > only internal window that can be live is the root window as the only
 > window on a frame, right? So what does "arbitrary side of the frame"
 > mean? When you have a single window, you can split it horizontally or
 > vertically, but that's about it. What am I missing?

`split-window' can split an arbitrary window.  My
`display-buffer-regexps', for example, contains the entry

(("ChangeLog.*")
   same-frame
   (reuse-buffer-window)
   (new-window
    (root . below))
   (min-height . 6)
   (min-width . 60)
   (adjust-height . 8))

so I can run ediff in side-by-side windows and edit a ChangeLog within
one and the same frame without disrupting the ediff setup.

Or, you can make sure that your completions always appear in a window on
the right of the frame by adding something like

(("*Completions*")
   same-frame
   (reuse-buffer-window)
   (new-window
    (root . right)))

to `display-buffer-names'.  And, since I'm able to display a buffer on
an arbitrary side of a window I can write

(("*Choices*")
   same-frame
   (reuse-buffer-window)
   (new-window
    (selected . above)))

and have ispell use `display-buffer' for the *Choices* buffer.  This
means that people who want to see the *Choices* buffer on a separate	
frame can do so by simply customizing `display-buffer-names'.

martin

Re: The window-pub branch

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>>> Moreover, I now allow to split internal windows like a frame's root
>>> window too, so the new window can appear at an arbitrary side of the
>>> frame.  In that case, talking about a `split-height-threshold' hardly
>>> makes sense.
>>
>> Um, I don't understand. AIUI you can only split a live window, and the
>> only internal window that can be live is the root window as the only
>> window on a frame, right? So what does "arbitrary side of the frame"
>> mean? When you have a single window, you can split it horizontally or
>> vertically, but that's about it. What am I missing?
>
> `split-window' can split an arbitrary window.  My
> `display-buffer-regexps', for example, contains the entry
>
> (("ChangeLog.*")
>   same-frame
>   (reuse-buffer-window)
>   (new-window
>    (root . below))
>   (min-height . 6)
>   (min-width . 60)
>   (adjust-height . 8))
>
> so I can run ediff in side-by-side windows and edit a ChangeLog within
> one and the same frame without disrupting the ediff setup.

Ah! Although the `root' parameter is mentioned in the documentation, I
didn't really understand its effects. I think adding something like the
example and comment above would help (the section is already long, but
it's loaded with information and only includes one simple example;
actually, adding a new section to the Emacs manual on customizing buffer
display with some more examples (or at least expanding the current
section and referring to it from a prominent place in the user manual)
would probably be even better, as this is really of at least as much
interest to users as it is to developers/Elisp authors.)

> Or, you can make sure that your completions always appear in a window on
> the right of the frame by adding something like
>
> (("*Completions*")
>   same-frame
>   (reuse-buffer-window)
>   (new-window
>    (root . right)))
>
> to `display-buffer-names'.  And, since I'm able to display a buffer on
> an arbitrary side of a window I can write
>
> (("*Choices*")
>   same-frame
>   (reuse-buffer-window)
>   (new-window
>    (selected . above)))
>
> and have ispell use `display-buffer' for the *Choices* buffer.  This
> means that people who want to see the *Choices* buffer on a separate	
> frame can do so by simply customizing `display-buffer-names'.

Thank you for the explanation!

  Štěpán