4

I've set up ert test results to display in a separate frame, if one exists, and in a bottom side-window otherwise:

(add-to-list 'display-buffer-alist
             '("\\`\\*ert\\*\\'"
               (display-buffer-reuse-window
                display-buffer-in-side-window)
               (reusable-frames      . visible)
               (inhibit-switch-frame . t)
               (side                 . bottom)))

In either case, I don't want the results window to gain focus, as I'd rather keep focus on the window I was editing in. So far, I can't find a way to do that.

Even when I've broken off a separate frame for the results, and despite specifying (inhibit-switch-frame . t), the results frame+window steals focus every time I trigger tests.

I even tried implementing a wrapper function to reselect the original window & frame, but even that isn't working:

(defun my-ert ()
  (let ((original-frame  (selected-frame))
        (original-window (selected-window)))
    (ert-run-tests-interactively t)
    (select-frame  original-frame)
    (select-window original-window)))

What am I missing?

  • I can see that, like most Emacs users, you have bent over backwards so as not to touch the function(s) responsible for the behavior you wish to change. However, that is still an option you may wish to consider. I.e., M-x find-function RET ert-run-tests-interactively RET and start tracing it -- find where the bad behavior is and consider changing it by making a new function or redefining the existing function. In the ert.el library, I see only one usage of switch-to-buffer-other-window and five usages of pop-to-buffer -- those functions are the most likely suspects. – lawlist Jan 9 '17 at 5:19
  • You have to escape the asterisks. – mutbuerger Jan 9 '17 at 5:36
  • @mutbuerger That's my bad, I miscopied the code into my question (I'm actually using the rx function to generate the regexp, but wanted to simplify things for the purposes of posting. – ivan Jan 9 '17 at 5:48
  • @Drew I'm on macOS Sierra, but what you suggested (select-frame-set-input-focus) worked. Thank you! – ivan Jan 9 '17 at 5:52
  • OK, good. I changed the comment to an answer (comments can be deleted anytime, in hopes it can help someone else too. – Drew Jan 9 '17 at 15:42
3

Some window managers, such as MS Windows, automatically give a new frame the focus after they create it.

If you need to focus another frame at that point then you will likely need to use function select-frame-set-input-focus.

  • 1
    For those users of OSX, select-frame-set-input-focus will cause Emacs to acquire focus over other applications/windows. If a user has a long running function that will utilize select-frame-set-input-focus at some point in the future and the user wishes to utilize the free-time/down-time to surf the internet with another browser (e.g., Firefox), Emacs will take the user away from what he/she was doing. An alternative to avoid this problem is using a combination of select-frame followed by raise-frame, which does not take the user away from another application. – lawlist Jan 9 '17 at 16:48
  • 1
    @lawlist: FWIW (just some more info): select-frame + raise-frame is not equivalent to select-frame-set-input-focus, at least on MS Windows. That combination will not set the focus (on MS Windows). – Drew Jan 9 '17 at 18:47
  • @Drew I found the same to be true on macOS – ivan Jan 10 '17 at 2:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.