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

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