GNU bug report logs - #7381
24.0.50; Provide a hook run when a window is selected

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Štěpán Němec <stepnem <at> gmail.com>
Cc: 7381 <at> debbugs.gnu.org
Subject: bug#7381: 24.0.50; Provide a hook run when a window is selected
Date: Fri, 12 Nov 2010 19:09:38 +0100

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.