bug#15029: 24.3; feature-request: add window-focus-lost-hook

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Ivan Baidakou]

Hello!

Please, add very useful feature: window-focus-lost-hook,
which will give the possibility to save all unsaved buffers
and no need of typing "C-x C-s", and, for example, the locally
loaded html will be automatically refreshed in by browser, just
as I switch to it via "ALT-tab" key.

That feature is requested by other people too:
http://batsov.com/articles/2012/03/08/emacs-tip-number-5-save-buffers-automatically-on-buffer-or-window-switch/
http://stackoverflow.com/questions/1230245/how-to-automatically-save-files-on-lose-focus-in-emacs

but neither works for me.

Thanks!

Best Regards,
Ivan Baidakou

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Glenn Morris]

Ivan Baidakou wrote:

> Please, add very useful feature: window-focus-lost-hook,

Maybe you can do this now in Emacs trunk?
But the feature is not documented anywhere (even in NEWS), and it's not
clear how to use it:

http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00555.html

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

I think it is a very bad idea to run Lisp code because the user
switches windows.  I intentionally did not create such hooks, because
their use would lead to confusing behavior which is impossible to
debug.

The user should be able to switch around between windows without
disturbing them at all.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Glenn Morris]

Richard Stallman wrote:

> I think it is a very bad idea to run Lisp code because the user
> switches windows.  I intentionally did not create such hooks, because
> their use would lead to confusing behavior which is impossible to
> debug.
>
> The user should be able to switch around between windows without
> disturbing them at all.

We are not talking about what you think we are talking about (at least,
I think so).

We are talking about when the input focus enters and leaves Emacs in a
GUI environment.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    We are talking about when the input focus enters and leaves Emacs in a
    GUI environment.

It's the same kind of issue.  I don't think Emacs should run any Lisp
code when that happens -- it would make things hard to predict.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Glenn Morris]

Richard Stallman wrote:

>     We are talking about when the input focus enters and leaves Emacs in a
>     GUI environment.
>
> It's the same kind of issue.  I don't think Emacs should run any Lisp
> code when that happens -- it would make things hard to predict.

To me, It seems a perfectly reasonable request to want Emacs do certain
things (eg save all files) when it loses input focus.

As for debugging, same procedure as always: does it happen with emacs -Q?
If not, it's something in your config, so bisect .emacs until you find
the line that causes it.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    To me, It seems a perfectly reasonable request to want Emacs do certain
    things (eg save all files) when it loses input focus.

That is a bizarre thing to do.  The right way to handle this is auto-save,
which operates whether you change focus or not, and doesn't alter the
files someone else will really look at.

There is no accounting for tastes, but I don't think a questionable
feature should be installed so people can do something so strange.

    As for debugging, same procedure as always: does it happen with emacs -Q?
    If not, it's something in your config, so bisect .emacs until you find
    the line that causes it.

I don't think you understand the problem.  The problem is how to debug
a program when switching windows to the debugger triggers it to do
something.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Glenn Morris]

Richard Stallman wrote:

> I don't think you understand the problem.  The problem is how to debug
> a program when switching windows to the debugger triggers it to do
> something.

I don't go around clicking other parts of my desktop while in the middle
of debugging an Emacs problem (nor do I use focus-follows-mouse), so
that is not a problem I expect to have.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    I don't go around clicking other parts of my desktop while in the middle
    of debugging an Emacs problem

Anyone can accidentally knock the mouse aside.

     (nor do I use focus-follows-mouse)

If the problem is limited to that sort of window management, it will
happen to fewer users -- but it is still asking for trouble.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Glenn Morris]

See patch at
http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00524.html

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Glenn Morris]

Version: 24.4

New hooks focus-in-hook, focus-out-hook have been added.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Stefan Monnier]

>     We are talking about when the input focus enters and leaves Emacs in a
>     GUI environment.
> It's the same kind of issue.  I don't think Emacs should run any Lisp
> code when that happens -- it would make things hard to predict.

Following that same reasoning, we shouldn't have jit-lock.
And post-command-hook.  And mouse-autoselect-window.  And timers.  Etc...
These all make debugging at times difficult.

Yes, these things should be used with care, but that doesn't mean we
shouldn't provide them, because they can be very useful.


        Stefan

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    > It's the same kind of issue.  I don't think Emacs should run any Lisp
    > code when that happens -- it would make things hard to predict.

    Following that same reasoning, we shouldn't have jit-lock.
    And post-command-hook.

jit-lock is tolerable because it is used in a very narrow way, for
updating text properties.  If it were used more broadly, it would
be a disaster.

post-command-hook is also used in narrow ways, and it doesn't
cause anything strange to happen just because you move the mouse.

Timers need to be used in a clean way if they are not to
cause trouble.  In any case, switching windows does not cause
timers to do anything.

If I understand what mouse-autoselect-window does, it only causes
switching windows -- it does not run Lisp code.

    Yes, these things should be used with care, but that doesn't mean we
    shouldn't provide them, because they can be very useful.

What is a very useful application for running code when the mouse
moves out of the Emacs frame?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Eli Zaretskii]

> Date: Thu, 08 Aug 2013 22:38:15 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: 15029@debbugs.gnu.org, dmol@gmx.com
> 
> jit-lock is tolerable because it is used in a very narrow way, for
> updating text properties.  If it were used more broadly, it would
> be a disaster.

jit-lock is indeed used more broadly, although in a small number of
features for now.  So if this is a disaster, it is already here.

> post-command-hook is also used in narrow ways, and it doesn't
> cause anything strange to happen just because you move the mouse.

post-command-hook is used for so many optional features in Emacs that
I cannot begin to understand how can you call that "narrow ways".

> If I understand what mouse-autoselect-window does, it only causes
> switching windows -- it does not run Lisp code.

mouse-autoselect-window starts a timer that will run Lisp when it
expires.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Stefan Monnier]

> post-command-hook is also used in narrow ways, and it doesn't
> cause anything strange to happen just because you move the mouse.

When I move the mouse from one frame to another, it generates
a `switch-frame' event, which is run by the perfectly normal command
handle-switch-frame, including running pre/post-command-hook.

> If I understand what mouse-autoselect-window does, it only causes
> switching windows -- it does not run Lisp code.

Same as above: runs pre/post-command-hook etc...

> What is a very useful application for running code when the mouse
> moves out of the Emacs frame?

Currently used to turn off the blink-cursor timer.
Other users want it to (auto-)save a file when its buffer/frame
loses focus.
Yet others want to change the frame's background color to indicate that
it has focus.


        Stefan

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    When I move the mouse from one frame to another, it generates
    a `switch-frame' event, which is run by the perfectly normal command
    handle-switch-frame, including running pre/post-command-hook.

I just made two frames and verified that moving the mouse from one
frame into the other did not switch frames.  The selected frame
remains selected even when the mouse is in the other.  You have to
click to switch frames.

Notwithstanding that, it is true that use of post-command-hook can
cause very confusing and painful behavior of you make a mistake.

I think you've gone down a tangent by trying to show that some
features in Emacs can be dangerous.  So what?  Each additional one is
still asking for trouble.  Especially when they create new kinds of
interactions that didn't exist before.  These interactions can combine
to be even worse than a single one.

    Currently used to turn off the blink-cursor timer.

That seems incorrect.  As long as the frame is selected
to receive X input events, its cursor should blink.

    Other users want it to (auto-)save a file when its buffer/frame
    loses focus.
    Yet others want to change the frame's background color to indicate that
    it has focus.

They don't seem terribly important.  If the solution had no downside,
I'd say, "Why not?"  But this one has a downside.

My judgment about what is likely to cause trouble in Emacs is based on
many years of experience maintaining versions of Emacs.  It is not
mathematically proven, but you shouldn't be so quick to dismiss it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Jan Djärv]

Hello.

9 aug 2013 kl. 18:56 skrev Richard Stallman <rms@gnu.org>:

>    Currently used to turn off the blink-cursor timer.
> 
> That seems incorrect.  As long as the frame is selected
> to receive X input events, its cursor should blink.

This is not the same thing.  Emacs does blink as long as it can receive X events.  When focus is lost it stops blinking, but before implementing stopping of timers, the timers kept on running for no purpose at all, except burning CPU cycles and battery time.

	Jan D.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    This is not the same thing.  Emacs does blink as long as it can
    receive X events.  When focus is lost it stops blinking, but
    before implementing stopping of timers, the timers kept on running
    for no purpose at all, except burning CPU cycles and battery time.

It should be easy enough for those timers to stop themselves
when they find out Emacs doesn't have the focus.

Doing this at the level of Lisp code might seem more general.
In many situations it is good to be general.  In a situation like
this, I think specific C code is safer.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Stefan Monnier]

> The selected frame remains selected even when the mouse is in the
> other.  You have to click to switch frames.

That's a property of your window-manager.  Mine uses the principle that
the focus follows the mouse, so just moving the mouse is enough to
select the other frame.

> My judgment about what is likely to cause trouble in Emacs is based on
> many years of experience maintaining versions of Emacs.  It is not
> mathematically proven, but you shouldn't be so quick to dismiss it.

While you do have more years of experience, I also have a respectable
number of years under my belt ;-)


        Stefan

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Eli Zaretskii]

> Date: Thu, 08 Aug 2013 11:46:15 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: 15029@debbugs.gnu.org, dmol@gmx.com
> 
>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
> 
>     We are talking about when the input focus enters and leaves Emacs in a
>     GUI environment.
> 
> It's the same kind of issue.  I don't think Emacs should run any Lisp
> code when that happens -- it would make things hard to predict.

I think that ship sailed a long time ago.  E.g., moving the mouse
pointer from one frame to another erases the echo area on the former
and displays the same message in the latter.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    I think that ship sailed a long time ago.  E.g., moving the mouse
    pointer from one frame to another erases the echo area on the former
    and displays the same message in the latter.

That happens at a level below Lisp code, so it should not interact
with anything.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Eli Zaretskii]

> Date: Thu, 08 Aug 2013 22:38:17 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: rgm@gnu.org, 15029@debbugs.gnu.org, dmol@gmx.com
> 
>         [ To any NSA and FBI agents reading my email: please consider
>         [ whether defending the US Constitution against all enemies,
>         [ foreign or domestic, requires you to follow Snowden's example.
> 
>     I think that ship sailed a long time ago.  E.g., moving the mouse
>     pointer from one frame to another erases the echo area on the former
>     and displays the same message in the latter.
> 
> That happens at a level below Lisp code, so it should not interact
> with anything.

It certainly interacts with the display engine, so it does belong to
the broad class of problems that you are worried about: it makes it
harder to debug Emacs.

In addition, redisplay can potentially run Lisp.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    >     I think that ship sailed a long time ago.  E.g., moving the mouse
    >     pointer from one frame to another erases the echo area on the former
    >     and displays the same message in the latter.
    > 
    > That happens at a level below Lisp code, so it should not interact
    > with anything.

    It certainly interacts with the display engine, so it does belong to
    the broad class of problems that you are worried about: it makes it
    harder to debug Emacs.

It could make it harder to debug Emacs, but won't make it harder
to debug your own programs.

    In addition, redisplay can potentially run Lisp.

I don't think displaying a message can run Lisp.

However, the main point is that you're making an argument that it's ok
to create a nasty problem because there are other such nasty problems.
I don't think that argument is valid, even aside from whether those
other nasty problems really exist.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Eli Zaretskii]

> Date: Fri, 09 Aug 2013 12:54:58 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: rgm@gnu.org, 15029@debbugs.gnu.org, dmol@gmx.com
> 
> However, the main point is that you're making an argument that it's ok
> to create a nasty problem because there are other such nasty problems.

No, I'm arguing that the problem is not as nasty as you seem to imply,
and that we have dealt with such problems successfully for a long
time.

bug#15029: 24.3; feature-request: add window-focus-lost-hook

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    No, I'm arguing that the problem is not as nasty as you seem to imply,
    and that we have dealt with such problems successfully for a long
    time.

If the feature is used in a very limited way, it may not become a
problem.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.