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

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

[Lennart Borgman]

2010/11/12 Štěpán Němec <stepnem@gmail.com>:
> 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).


Can't you use post-command-hook?

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

[Štěpán Němec]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> 2010/11/12 Štěpán Němec <stepnem@gmail.com>:
>> 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).
>
>
> Can't you use post-command-hook?

That sounds like an even less appropriate way to handle this than the
advice.

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

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

[martin rudalics]

Stefan, Chong - please consider installing the patch below.

martin

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

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

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> Stefan, Chong - please consider installing the patch below.
>>
>> +DEFUN ("window-use-time", Fwindow_use_time, Swindow_use_time, 0, 1, 0,
>> +       doc: /* Return WINDOW's use time.

Installed.

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

[Štěpán Němec]

Chong Yidong <cyd@stupidchicken.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>> Stefan, Chong - please consider installing the patch below.
>>>
>>> +DEFUN ("window-use-time", Fwindow_use_time, Swindow_use_time, 0, 1, 0,
>>> +       doc: /* Return WINDOW's use time.
>
> Installed.

Thanks, but we also need a defsubr for it to be useful... :-)

diff --git a/src/window.c b/src/window.c
index e66fde9..f8031dc 100644
--- a/src/window.c
+++ b/src/window.c
@@ -7198,6 +7198,7 @@ frame to be redrawn only if it is a tty frame.  */);
   defsubr (&Sprevious_window);
   defsubr (&Sother_window);
   defsubr (&Sget_lru_window);
+  defsubr (&Swindow_use_time);
   defsubr (&Sget_largest_window);
   defsubr (&Sget_buffer_window);
   defsubr (&Sdelete_other_windows);


  Štěpán

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

[martin rudalics]

> Thanks, but we also need a defsubr for it to be useful... :-)

Indeed.  Chong, please.

martin

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

[Chong Yidong]

Štěpán Němec <stepnem@gmail.com> writes:

> Thanks, but we also need a defsubr for it to be useful... :-)

Installed, thanks.

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

[Richard Stallman]

I think it not good design to run Lisp code due to switching windows.
The existence of the possibility will make debugging much harder.

What was the motive for this request?  If a window is set up properly,
switching away and back won't change it.  It will be exactly as you
left it.

If there is a specific practical problem, let's look for a clean
solution rather than add this hook.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

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

[Stefan Monnier]

severity 7381 wishlist
thanks

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

We could add a select-window-hook, indeed.  We'd probably only want to
run it when the norecord argument is nil, but other than that I don't
see any good reason not to have such a thing (tho I don't see any
particularly strong reason to have such a thing either: your use case
makes sense, but it's not extremely important/useful since you can get
somewhat comparable results in many different ways, and I haven't seen
many other use cases yet).

It may come down to just adding the appropriate run_hooks call in
Fselect_window, but someone will first have to check all calls to
Fselect_window and make sure they can withstand running arbitrary Elisp
code (currently Fselect_window cannot cause Elisp code to be run, AFAICT).


        Stefan

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

[martin rudalics]

;; fixed 7381 27.1
;; quit

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

Current master now provides a hook run when redisplay detects that the
selected window has changed wrt last redisplay.  The hook is called
'window-selection-change-functions' and is described in detail in the
Elisp manual.  Below I sketch how that hook could be used to provide
the behavior you asked for.

martin


(defvar .old-selected-window (selected-window))

(defun .update-old-selected-window (frame)
   (unless (eq .update-old-selected-window old-selected-window)
     (setq .old-selected-window (old-selected-window))))

(add-hook 'window-selection-change-functions '.update-old-selected-window)

(defun .goto-mru-window ()
   (interactive)
   (select-window .old-selected-window))

(global-set-key [(control .)] '.goto-mru-window)

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

[Štěpán Němec]

On Sat, 12 Jan 2019 10:15:24 +0100
martin rudalics wrote:

> Current master now provides a hook run when redisplay detects that the
> selected window has changed wrt last redisplay.  The hook is called
> 'window-selection-change-functions' and is described in detail in the
> Elisp manual.

Thank you very much. Despite still using GNU Emacs daily, I currently
don't follow the development version so I can't test the changes, but I
really appreciate your getting back to this after so many years.

> Below I sketch how that hook could be used to provide
> the behavior you asked for.

> (defvar .old-selected-window (selected-window))
>
> (defun .update-old-selected-window (frame)
>    (unless (eq .update-old-selected-window old-selected-window)
>      (setq .old-selected-window (old-selected-window))))

It seems to me this was meant to read

 (defun .update-old-selected-window (frame)
    (unless (eq .old-selected-window (old-selected-window))
      (setq .old-selected-window (old-selected-window))))

  Thanks,

  Štěpán

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

[martin rudalics]

 >> (defun .update-old-selected-window (frame)
 >>     (unless (eq .update-old-selected-window old-selected-window)
 >>       (setq .old-selected-window (old-selected-window))))
 >
 > It seems to me this was meant to read
 >
 >   (defun .update-old-selected-window (frame)
 >      (unless (eq .old-selected-window (old-selected-window))
 >        (setq .old-selected-window (old-selected-window))))

Indeed.  I posted the example to make the point that

(defun .update-old-selected-window (frame)
   (setq .old-selected-window (old-selected-window)))

is a bad idea since it would overwrite the last selected window that
was different from the currently selected one.

BTW, did you ever try something like

(defun .goto-mru-window ()
   (interactive)
   (select-window (get-mru-window nil nil t)))

(global-set-key [(control .)] '.goto-mru-window)

It should provide the same service for older Emacsen.

martin

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

[Štěpán Němec]

On Sat, 12 Jan 2019 15:12:13 +0100
martin rudalics wrote:

>  >> (defun .update-old-selected-window (frame)
>  >>     (unless (eq .update-old-selected-window old-selected-window)
>  >>       (setq .old-selected-window (old-selected-window))))
>  >
>  > It seems to me this was meant to read
>  >
>  >   (defun .update-old-selected-window (frame)
>  >      (unless (eq .old-selected-window (old-selected-window))
>  >        (setq .old-selected-window (old-selected-window))))
>
> Indeed.  I posted the example to make the point that
>
> (defun .update-old-selected-window (frame)
>    (setq .old-selected-window (old-selected-window)))
>
> is a bad idea since it would overwrite the last selected window that
> was different from the currently selected one.

Of course.

> BTW, did you ever try something like
>
> (defun .goto-mru-window ()
>    (interactive)
>    (select-window (get-mru-window nil nil t)))

I don't remember, but given that I do have a `.get-mru-window' function
of my own, as well as the fact that e.g. evil-mode's `evil-window-mru'
definition doesn't use `get-mru-window' either, makes me think that it
either wasn't available at the time or doesn't do what I or evil authors
wanted.

  Thanks again,

  Štěpán