[PATCH] frame.c: focus hooks

[PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1.1: Type: text/plain, Size: 446 bytes --]

Hello.

I'd like to contribute the attached patch, which adds hooks into gain and
loss of focus events.

This allows saving all buffers on loss of focus.  (Alt-tabbing between
an editor and browser is a popular workflow for web programmers.)

It also allows reversion of buffers on regain of focus, convenient if
one is switching between Emacs and another editor.

People will probably find other handy uses for these hooks.

Best,
Brian Jenkins

[-- Attachment #1.2: Type: text/html, Size: 651 bytes --]

[-- Attachment #2: focus-hooks.patch --]
[-- Type: application/octet-stream, Size: 1629 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 4494edda..6c89b7e 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -109,6 +109,8 @@ Lisp_Object Qalpha;
 
 Lisp_Object Qface_set_after_frame_default;
 
+static Lisp_Object Qfocus_in_hook;
+static Lisp_Object Qfocus_out_hook;
 static Lisp_Object Qdelete_frame_functions;
 
 static Lisp_Object Qgeometry, Qworkarea, Qmm_size, Qframes, Qsource;
@@ -893,6 +895,7 @@ is not generated.
 This function checks if blink-cursor timers should be turned on again.  */)
   (Lisp_Object event)
 {
+  Frun_hooks (1, &Qfocus_in_hook);
   return call0 (intern ("blink-cursor-check"));
 }
 
@@ -903,6 +906,7 @@ Focus out events occur when no frame has focus.
 This function checks if blink-cursor timers should be turned off.  */)
   (Lisp_Object event)
 {
+  Frun_hooks (1, &Qfocus_out_hook);
   return call0 (intern ("blink-cursor-suspend"));
 }
 
@@ -4465,6 +4469,16 @@ when the mouse is over clickable text.  */);
 The pointer becomes visible again when the mouse is moved.  */);
   Vmake_pointer_invisible = Qt;
 
+  DEFVAR_LISP ("focus-in-hook", Vfocus_in_hook,
+               doc: /* Normal hook run when a frame gains input focus.*/);
+  Vfocus_in_hook = Qnil;
+  DEFSYM (Qfocus_in_hook, "focus-in-hook");
+
+  DEFVAR_LISP ("focus-out-hook", Vfocus_out_hook,
+               doc: /* Normal hook run when a frame loses input focus.*/);
+  Vfocus_out_hook = Qnil;
+  DEFSYM (Qfocus_out_hook, "focus-out-hook");
+
   DEFVAR_LISP ("delete-frame-functions", Vdelete_frame_functions,
 	       doc: /* Functions run before deleting a frame.
 The functions are run with one arg, the frame to be deleted.

Re: [PATCH] frame.c: focus hooks

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

I welcome your idea! In fact I've been thinking for quite some time we
needed something like this. I don't like the names of the hooks, however,
since they don't seem particularly standard - usually the terminology used
with focus is "focus gained" and "focus lost" (or "on focus" and "on lose
focus").


On 17 November 2013 19:50, Brian Jenkins <brian@brianjenkins.org> wrote:

> Hello.
>
> I'd like to contribute the attached patch, which adds hooks into gain and
> loss of focus events.
>
> This allows saving all buffers on loss of focus.  (Alt-tabbing between
> an editor and browser is a popular workflow for web programmers.)
>
> It also allows reversion of buffers on regain of focus, convenient if
> one is switching between Emacs and another editor.
>
> People will probably find other handy uses for these hooks.
>
> Best,
> Brian Jenkins
>

[-- Attachment #2: Type: text/html, Size: 1391 bytes --]

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

Thanks for the encouragement and feedback, Bozhidar.

I'm not married to the names.  I noticed that terms for focus gain/loss
seem to vary between platforms, so I used the event names used elsewhere in
the Emacs source.

Perhaps "focus-gain-hook" and "focus-loss-hook" would be more intuitive?

Brian


On Sun, Nov 17, 2013 at 1:29 PM, Bozhidar Batsov <bozhidar@batsov.com>wrote:

> I welcome your idea! In fact I've been thinking for quite some time we
> needed something like this. I don't like the names of the hooks, however,
> since they don't seem particularly standard - usually the terminology used
> with focus is "focus gained" and "focus lost" (or "on focus" and "on lose
> focus").
>
>
> On 17 November 2013 19:50, Brian Jenkins <brian@brianjenkins.org> wrote:
>
>> Hello.
>>
>> I'd like to contribute the attached patch, which adds hooks into gain and
>> loss of focus events.
>>
>> This allows saving all buffers on loss of focus.  (Alt-tabbing between
>> an editor and browser is a popular workflow for web programmers.)
>>
>> It also allows reversion of buffers on regain of focus, convenient if
>> one is switching between Emacs and another editor.
>>
>> People will probably find other handy uses for these hooks.
>>
>> Best,
>> Brian Jenkins
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2241 bytes --]

RE: [PATCH] frame.c: focus hooks

[Drew Adams]

> I'd like to contribute the attached patch, which adds hooks into
> gain and loss of focus events.
> 
> This allows saving all buffers on loss of focus.  (Alt-tabbing
> between an editor and browser is a popular workflow for web
> programmers.)
> 
> It also allows reversion of buffers on regain of focus, convenient
> if one is switching between Emacs and another editor.
>
> People will probably find other handy uses for these hooks.

Sounds useful.

Is this only for a focus switch between Emacs (any frame) and some
other application?  Or is it also for a focus switch from one Emacs
frame to another.

(I hope it is the former, which is what you describe in your example
use cases.)

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

Hi, Drew.

Thanks for the feedback.

Unfortunately, no.  The "focus in" and "focus out" events in Emacs fire
per frame.  So alt-tabbing between Emacs frames will trigger a focus loss
event for the origin frame and focus gain for the destination frame

Initially I tried hacking in at the terminal level (nsterm.c, xterm.c,
and w32term.c) but I had difficulty figuring out how application
(opposed to frame) focus works under X.  It's not clear to me that X
itself even *has* a concept of "active application" distinct from "frame
that has input focus".  (Perhaps this concept exists at the window
manager level, but there are a lot of window managers...) I'm not even a
beginner at X programming, though, so maybe someone could point me in
the right direction?

The convenient thing about patching into the "focus in" and "focus out"
events is that they live up in frame.c, which appears to be
cross-platform.

Best,
Brian


On Sun, Nov 17, 2013 at 5:33 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > I'd like to contribute the attached patch, which adds hooks into
> > gain and loss of focus events.
> >
> > This allows saving all buffers on loss of focus.  (Alt-tabbing
> > between an editor and browser is a popular workflow for web
> > programmers.)
> >
> > It also allows reversion of buffers on regain of focus, convenient
> > if one is switching between Emacs and another editor.
> >
> > People will probably find other handy uses for these hooks.
>
> Sounds useful.
>
> Is this only for a focus switch between Emacs (any frame) and some
> other application?  Or is it also for a focus switch from one Emacs
> frame to another.
>
> (I hope it is the former, which is what you describe in your example
> use cases.)
>

[-- Attachment #2: Type: text/html, Size: 2497 bytes --]

RE: [PATCH] frame.c: focus hooks

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]

Hi Brian,

 

Hm. That's too bad. I was hoping for Emacs vs outside focus changes, especially since the use case examples given suggested that. I wouldn't want a buffer to get saved just because I switched Emacs frames, for instance (but I recognize that someone else might).

 

Let's please make this crystal clear in the doc and names of functions etc. And in the use-case examples we provide in the doc, if any.

 

Anyway, I'm in favor of adding such hooks.

 

Thx - Drew

 

Hi, Drew.

 

Thanks for the feedback.

 

Unfortunately, no.  The "focus in" and "focus out" events in Emacs fire

per frame.  So alt-tabbing between Emacs frames will trigger a focus loss

event for the origin frame and focus gain for the destination frame

 

Initially I tried hacking in at the terminal level (nsterm.c, xterm.c,

and w32term.c) but I had difficulty figuring out how application

(opposed to frame) focus works under X.  It's not clear to me that X

itself even *has* a concept of "active application" distinct from "frame

that has input focus".  (Perhaps this concept exists at the window

manager level, but there are a lot of window managers...) I'm not even a

beginner at X programming, though, so maybe someone could point me in

the right direction?

 

The convenient thing about patching into the "focus in" and "focus out"

events is that they live up in frame.c, which appears to be

cross-platform.

 

Best,

Brian

 

On Sun, Nov 17, 2013 at 5:33 PM, Drew Adams <HYPERLINK "mailto:drew.adams@oracle.com" \ndrew.adams@oracle.com> wrote:

> I'd like to contribute the attached patch, which adds hooks into
> gain and loss of focus events.
>
> This allows saving all buffers on loss of focus.  (Alt-tabbing
> between an editor and browser is a popular workflow for web
> programmers.)
>
> It also allows reversion of buffers on regain of focus, convenient
> if one is switching between Emacs and another editor.
>
> People will probably find other handy uses for these hooks.

Sounds useful.

Is this only for a focus switch between Emacs (any frame) and some
other application?  Or is it also for a focus switch from one Emacs
frame to another.

(I hope it is the former, which is what you describe in your example
use cases.)

 

[-- Attachment #2: Type: text/html, Size: 6816 bytes --]

Re: [PATCH] frame.c: focus hooks

[Stefan Monnier]

> Unfortunately, no.  The "focus in" and "focus out" events in Emacs fire
> per frame.  So alt-tabbing between Emacs frames will trigger a focus loss
> event for the origin frame and focus gain for the destination frame

Indeed, that's a problem in the current implementation, but that's not
the fault of your patch (your patch only makes the existing `focus-in'
and `focus-out' special events available via hooks, which is indeed more
convenient).

> It's not clear to me that X itself even *has* a concept of "active
> application" distinct from "frame that has input focus".

That's right: X11 has no such concept, AFAIK.  So we can't avoid
receiving a FocusOut/FocusIn pair of X11 events.  Hopefully, someone
will figure out how to cancel out such pairs in the C code so they don't
result in a `focus-in' and `focus-out' pair of Lisp-level events.


        Stefan

Re: [PATCH] frame.c: focus hooks

[Stephen J. Turnbull]

Brian Jenkins writes:

 > It's not clear to me that X itself even *has* a concept of "active
 > application" distinct from "frame that has input focus".

No, it doesn't, and it can't.

Multiple applications can select events in the same X window at the same
time.  For example, the classic debugging tool xev(1) selects events on
a window you select (say, an Emacs frame), and outputs a trace of those
events.  Which is active: xev, or Emacs (which also receives those input
events and acts on them as if xev didn't exist)?

The only sane answer is "both of them".

Re: [PATCH] frame.c: focus hooks

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

Btw, it would be good if this change was mentioned in the NEWS, since I'm
pretty sure I'm not the only Emacs user that will find it useful :-)


On 19 November 2013 10:26, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Brian Jenkins writes:
>
>  > It's not clear to me that X itself even *has* a concept of "active
>  > application" distinct from "frame that has input focus".
>
> No, it doesn't, and it can't.
>
> Multiple applications can select events in the same X window at the same
> time.  For example, the classic debugging tool xev(1) selects events on
> a window you select (say, an Emacs frame), and outputs a trace of those
> events.  Which is active: xev, or Emacs (which also receives those input
> events and acts on them as if xev didn't exist)?
>
> The only sane answer is "both of them".
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1260 bytes --]

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

On Tue, Nov 19, 2013 at 9:10 AM, Bozhidar Batsov <bozhidar@batsov.com>wrote:

> Btw, it would be good if this change was mentioned in the NEWS, since I'm
> pretty sure I'm not the only Emacs user that will find it useful :-)
>
>
Thanks, will do.  (I'm still learning this project's documentation
conventions.)

I'll also add these hooks to the appropriate info pages (with stern warnings
not to mess with other peoples' focus settings).

Best,
Brian

[-- Attachment #2: Type: text/html, Size: 969 bytes --]

Re: [PATCH] frame.c: focus hooks

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

These names are fine by me.


On 18 November 2013 00:25, Brian Jenkins <brian@brianjenkins.org> wrote:

> Thanks for the encouragement and feedback, Bozhidar.
>
> I'm not married to the names.  I noticed that terms for focus gain/loss
> seem to vary between platforms, so I used the event names used elsewhere in
> the Emacs source.
>
> Perhaps "focus-gain-hook" and "focus-loss-hook" would be more intuitive?
>
> Brian
>
>
> On Sun, Nov 17, 2013 at 1:29 PM, Bozhidar Batsov <bozhidar@batsov.com>wrote:
>
>> I welcome your idea! In fact I've been thinking for quite some time we
>> needed something like this. I don't like the names of the hooks, however,
>> since they don't seem particularly standard - usually the terminology used
>> with focus is "focus gained" and "focus lost" (or "on focus" and "on lose
>> focus").
>>
>>
>> On 17 November 2013 19:50, Brian Jenkins <brian@brianjenkins.org> wrote:
>>
>>> Hello.
>>>
>>> I'd like to contribute the attached patch, which adds hooks into gain and
>>> loss of focus events.
>>>
>>> This allows saving all buffers on loss of focus.  (Alt-tabbing between
>>> an editor and browser is a popular workflow for web programmers.)
>>>
>>> It also allows reversion of buffers on regain of focus, convenient if
>>> one is switching between Emacs and another editor.
>>>
>>> People will probably find other handy uses for these hooks.
>>>
>>> Best,
>>> Brian Jenkins
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2742 bytes --]

Re: [PATCH] frame.c: focus hooks

[Stefan Monnier]

> I welcome your idea! In fact I've been thinking for quite some time we
> needed something like this. I don't like the names of the hooks, however,
> since they don't seem particularly standard - usually the terminology used
> with focus is "focus gained" and "focus lost" (or "on focus" and "on lose
> focus").

I've never heard "gain focus".  I think focus-in-hook and focus-out-hook
look fine to me.  At least, "FocusIn" and "FocusOut" are the terms used
by the X library, and so far Emacs has followed this naming convention.


        Stefan

Fwd: [PATCH] frame.c: focus hooks

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

That's the terminology used in several GUI libraries (and in client-side
web) when you want to listen for focus events. Anyways, the name is not
particularly important - if X is using "FocusIn" and "FocusOut" and Emacs
uses the X terminology that's fine.


On 18 November 2013 15:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > I welcome your idea! In fact I've been thinking for quite some time we
> > needed something like this. I don't like the names of the hooks, however,
> > since they don't seem particularly standard - usually the terminology
> used
> > with focus is "focus gained" and "focus lost" (or "on focus" and "on lose
> > focus").
>
> I've never heard "gain focus".  I think focus-in-hook and focus-out-hook
> look fine to me.  At least, "FocusIn" and "FocusOut" are the terms used
> by the X library, and so far Emacs has followed this naming convention.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 1529 bytes --]

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

>
> I've never heard "gain focus".  I think focus-in-hook and focus-out-hook
> look fine to me.  At least, "FocusIn" and "FocusOut" are the terms used
> by the X library, and so far Emacs has followed this naming convention.
>


Yes, it seems that everyone has different names for these events!

When in doubt, we should probably favor GNU/Linux conventions over those
of nonfree platforms.

Brian

[-- Attachment #2: Type: text/html, Size: 885 bytes --]

Re: [PATCH] frame.c: focus hooks

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

If you don't use click-to-focus, Emacs can gain and lose focus every time
you move the mouse, even inadvertently.  It would be very bad for this to
have any lasting effect.  I think such hooks should not exist.

    This allows saving all buffers on loss of focus.  (Alt-tabbing between
    an editor and browser is a popular workflow for web programmers.)

I think it is better to have Emacs control the change of focus
and define a command that saves buffers and switches focus
(if that's what you like to do).

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

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

>
> If you don't use click-to-focus, Emacs can gain and lose focus every time
> you move the mouse, even inadvertently.  It would be very bad for this to
> have any lasting effect.  I think such hooks should not exist.



Hello, Dr. Stallman.

Thank you for your thoughtful feedback.

I agree that it may not make sense for users in focus-follows-mouse
environments to use these hooks.  I don't think it follows that these
hooks should not exist.  They default to nil -- people who don't want
them don't have to use them.

There is a large class of programmers (web developers) who expect their
editor to *be able* to behave this way.  True, they will need to take
responsibility not to break their environments by abusing these hooks,
but Emacs already requires a degree of responsibility from those
configuring it.

Perhaps I am misunderstanding how hooks are run?  I have assumed that
running a nil hook is a no-op.  If not, perhaps we can add a check to
the C event handler and call Frun_hooks only if the hook has been set?

I'm not trying to force anyone to run lisp on focus change.  I'm hoping
to encourage wider use of Emacs in the web development communities.

Best,
Brian Jenkins

[-- Attachment #2: Type: text/html, Size: 1825 bytes --]

Re: [PATCH] frame.c: focus hooks

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

    There is a large class of programmers (web developers) who expect their
    editor to *be able* to behave this way.  True, they will need to take
    responsibility not to break their environments by abusing these hooks,
    but Emacs already requires a degree of responsibility from those
    configuring it.

Are you assuming that these hooks won't be used by any Lisp packages?

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

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

>
>
> Are you assuming that these hooks won't be used by any Lisp packages?
>
>
Yes, I am expecting that they will be left for the user to specify in
his or her local Emacs configuration.

That is, I expect that they won't be assigned by *polite* Lisp packages.
It would be rude to set these hooks in a package published for
widespread use.

Package authors aren't perfect, but they care enough about Emacs culture
to learn Lisp and contribute work.  We should assume good faith.  When
people write impolite packages, we should teach them Emacs etiquette and
help them observe social norms.

Further, ill-mannered Lisp packages are not forced on the user.  They
are deliberately downloaded in source form and installed.  If a package
inappropriately assigns hooks, we are free to uninstall it, to clear the
hooks after load, to modify the package for local use, to contact the
authors and suggest that they not over-specify our environment, or even
to distribute a better-behaved fork of the package.

Inappropriate hook assignment is also easier to detect than many
possible package misbehaviors -- just evaluate the hook variables.

It's probably not a bad idea to document the intent of these hooks -- that
they are meant for the end user and that it is inappropriate to set them
in public packages, but I don't see that adding them opens a huge can of
worms.

Best,
Brian Jenkins

[-- Attachment #2: Type: text/html, Size: 2107 bytes --]

RE: [PATCH] frame.c: focus hooks

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]

Hm. I see nothing in either the Emacs manual or the Elisp manual that suggests that Lisp code should not use `add-hook' or `remove-hook'.

 

Where do you find a convention saying that *polite* Lisp packages do not modify hook values and that to do so in a package published for widespread use is "rude" and "ill-mannered"? Or that package authors who do not respect such a presumed convention are impolite or do not act in good faith?

 

Where are the "Emacs etiquette" and "social norms" in this regard put forth?

 

Just wondering.

 

The only thing I see that is related to this is in (elisp) `Coding Conventions', where it says:

 

     If loading the file adds functions to hooks, define a function

     `FEATURE-unload-hook', where FEATURE is the name of the feature

     the package provides, and make it undo any such changes.  Using

     `unload-feature' to unload the file will run this function.  *Note

     Unloading::.

 

You say:

 

It's probably not a bad idea to document the intent of these hooks -- that they are meant for the end user and that it is inappropriate to set them in public packages, but I don't see that adding them opens a huge can of worms.

 

Then please do that. If it is inappropriate for Lisp code to use these hooks, then document that, of course. And perhaps document the reason. I don't think you can assume that people (users or package authors) are aware of the convention that you presume.

 

Are you assuming that these hooks won't be used by any Lisp packages?

 

Yes, I am expecting that they will be left for the user to specify in

his or her local Emacs configuration.

 

That is, I expect that they won't be assigned by *polite* Lisp packages.

It would be rude to set these hooks in a package published for

widespread use.

 

Package authors aren't perfect, but they care enough about Emacs culture

to learn Lisp and contribute work.  We should assume good faith.  When

people write impolite packages, we should teach them Emacs etiquette and

help them observe social norms.

 

Further, ill-mannered Lisp packages are not forced on the user.  They

are deliberately downloaded in source form and installed.  If a package

inappropriately assigns hooks, we are free to uninstall it, to clear the

hooks after load, to modify the package for local use, to contact the

authors and suggest that they not over-specify our environment, or even

to distribute a better-behaved fork of the package.

 

Inappropriate hook assignment is also easier to detect than many

possible package misbehaviors -- just evaluate the hook variables.

 

It's probably not a bad idea to document the intent of these hooks -- that

they are meant for the end user and that it is inappropriate to set them

in public packages, but I don't see that adding them opens a huge can of

worms.

 

Best,

Brian Jenkins 

[-- Attachment #2: Type: text/html, Size: 9622 bytes --]

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

On Tue, Nov 19, 2013 at 1:53 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Hm. I see nothing in either the Emacs manual or the Elisp manual that
> suggests that Lisp code should not use `add-hook' or `remove-hook'.
>
>
>
> Where do you find a convention saying that *polite* Lisp packages do not
> modify hook values and that to do so in a package published for widespread
> use is "rude" and "ill-mannered"? Or that package authors who do not
> respect such a presumed convention are impolite or do not act in good faith?
>
>

I'm sorry if I was unclear.  Of course it is appropriate for package
authors to use hooks in general.

I believe that it would in inappropriate to set *these hooks in
particular*, because behavior on focus-in & focus-out is a matter of
taste.

As for good faith, I explicitly said we should assume good faith.

If someone writes an otherwise great package that has weird global side
effects, we shouldn't assume that he or she is a jerk.

We should say "Hey, this is a great package, but you're assuming that
everyone will want to to save all their files when they alt-tab away
from Emacs.  Many people might not want that.  Why not leave this hook
to the user to configure so that more people can benefit from your
work?"

We should assume that disruptive side effects are due to inattention,
not malice.


> Where are the "Emacs etiquette" and "social norms" in this regard put
> forth?
>
>
>
> Just wondering.
>
>

Well, nowhere.  No one is saying that package authors shouldn't use any
hooks.  I'm sorry that I sounded like I was saying that -- it's not what I
meant.

But there *are* social norms being communicated in this forum.  I don't
think I'm imagining a consensus of fairly strong disapproval for package
authors globally imposing behaviors that are a matter of taste or that
work well on one platform, but not on others.

If this convention is not communicated in, for instance, the ELisp info
pages, maybe it should be.


> You say:
>
>
>
> It's probably not a bad idea to document the intent of these hooks -- that
> they are meant for the end user and that it is inappropriate to set them in
> public packages, but I don't see that adding them opens a huge can of worms.
>
>
>
> Then please do that. If it is inappropriate for Lisp code to use *these*hooks, then document that, of course. And perhaps document the reason. I
> don't think you can assume that people (users or package authors) are aware
> of the convention that you presume.
>
>
>

Thanks for the feedback. You make a good point -- I will do this.

Best,
Brian Jenkins

[-- Attachment #2: Type: text/html, Size: 6094 bytes --]

Re: [PATCH] frame.c: focus hooks

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

    That is, I expect that they won't be assigned by *polite* Lisp packages.
    It would be rude to set these hooks in a package published for
    widespread use.

Then at least they should be documented so as to tell people
not to do this.

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

Re: [PATCH] frame.c: focus hooks

[Josh]

On Tue, Nov 19, 2013 at 3:42 PM, Richard Stallman <rms@gnu.org> wrote:
>     That is, I expect that they won't be assigned by *polite* Lisp packages.
>     It would be rude to set these hooks in a package published for
>     widespread use.
>
> Then at least they should be documented so as to tell people
> not to do this.

These frame focus hooks are closely related to the select-window-hook
that was proposed and ultimately rejected a few years back[0].  Would
such a hook be accepted now if its documentation were to contain a
similar warning?

[0] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7381#59

Josh

Re: [PATCH] frame.c: focus hooks

[Stefan Monnier]

> These frame focus hooks are closely related to the select-window-hook
> that was proposed and ultimately rejected a few years back[0].  Would
> such a hook be accepted now if its documentation were to contain a
> similar warning?

Personally, I think such a hook is not in itself a problem.  But I also
think it's ill-advised.  The main reason is that select-window is an
operation used internally, so it can be called many times within
a single command, even if the command might end up "staying in the same
window".

A pre/post-command-hook that compares selected-window with the previous one
will provide a behavior closer to what users want, I think.
Of course, it could still be called select-window-hook, tho that name
would be a bit misleading.


        Stefan

Re: [PATCH] frame.c: focus hooks

[Josh]

On Tue, Nov 19, 2013 at 7:16 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> These frame focus hooks are closely related to the select-window-hook
>> that was proposed and ultimately rejected a few years back[0].  Would
>> such a hook be accepted now if its documentation were to contain a
>> similar warning?
>
> Personally, I think such a hook is not in itself a problem.  But I also
> think it's ill-advised.  The main reason is that select-window is an
> operation used internally, so it can be called many times within
> a single command, even if the command might end up "staying in the same
> window".

Yes, that's a fair point.  Is there some way we could distinguish
between such ephemeral selected-window changes and transitions from
one steady state to another?

> A pre/post-command-hook that compares selected-window with the previous one
> will provide a behavior closer to what users want, I think.
> Of course, it could still be called select-window-hook, tho that name
> would be a bit misleading.

Such a hook would be an improvement but not ideal, since some
selected-window changes of interest may not result from a user
command, e.g. those due to a non-nil compilation-auto-jump-to-first-error.

Re: [PATCH] frame.c: focus hooks

[martin rudalics]

 > Yes, that's a fair point.  Is there some way we could distinguish
 > between such ephemeral selected-window changes and transitions from
 > one steady state to another?

If the NORECORD argument is non-nil as in `with-selected-window', the
call is usually an ephemeral one.  `buffer-list-update-hook' is called
only when NORECORD is nil.

martin

Re: [PATCH] frame.c: focus hooks

[Josh]

On Tue, Nov 19, 2013 at 11:34 PM, martin rudalics <rudalics@gmx.at> wrote:
>> Yes, that's a fair point.  Is there some way we could distinguish
>> between such ephemeral selected-window changes and transitions from
>> one steady state to another?
>
> If the NORECORD argument is non-nil as in `with-selected-window', the
> call is usually an ephemeral one.  `buffer-list-update-hook' is called
> only when NORECORD is nil.

Sorry I failed to follow up on this earlier.  Stefan, do I understand
correctly that you'd be amenable to a new `select-window-hook'
provided that it did not come into play for the ephemeral changes of
selected-window that can occur within a single command?  If so, I'd
like to take a stab at implementing this (I realize that any such hook
could not be checked in until the feature thaw).  Unless anything has
changed since your earlier comment[0], I'd start with your suggestion
of adding the new run_hooks call to Fselect_window after verifying
that all of its current callers can tolerate running arbitrary Elisp.

[0] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7381#59

Thanks,
Josh

Re: [PATCH] frame.c: focus hooks

[martin rudalics]

 >> If the NORECORD argument is non-nil as in `with-selected-window', the
 >> call is usually an ephemeral one.  `buffer-list-update-hook' is called
 >> only when NORECORD is nil.
 >
 > Sorry I failed to follow up on this earlier.  Stefan, do I understand
 > correctly that you'd be amenable to a new `select-window-hook'
 > provided that it did not come into play for the ephemeral changes of
 > selected-window that can occur within a single command?  If so, I'd
 > like to take a stab at implementing this (I realize that any such hook
 > could not be checked in until the feature thaw).  Unless anything has
 > changed since your earlier comment[0], I'd start with your suggestion
 > of adding the new run_hooks call to Fselect_window after verifying
 > that all of its current callers can tolerate running arbitrary Elisp.

Can you telll me whether/why `buffer-list-update-hook' doesn't work for
you?

martin

Re: [PATCH] frame.c: focus hooks

[Josh]

On Sat, Jan 11, 2014 at 2:25 AM, martin rudalics <rudalics@gmx.at> wrote:
>>> If the NORECORD argument is non-nil as in `with-selected-window', the
>>> call is usually an ephemeral one.  `buffer-list-update-hook' is called
>>> only when NORECORD is nil.
>>
>> Sorry I failed to follow up on this earlier.  Stefan, do I understand
>> correctly that you'd be amenable to a new `select-window-hook'
>> provided that it did not come into play for the ephemeral changes of
>> selected-window that can occur within a single command?  If so, I'd
>> like to take a stab at implementing this (I realize that any such hook
>> could not be checked in until the feature thaw).  Unless anything has
>> changed since your earlier comment[0], I'd start with your suggestion
>> of adding the new run_hooks call to Fselect_window after verifying
>> that all of its current callers can tolerate running arbitrary Elisp.
>
> Can you telll me whether/why `buffer-list-update-hook' doesn't work for
> you?

I originally interpreted your mention of it as additional evidence that
deciding whether or not to call a new select-window-hook from
Fselect_window based on its NORECORD argument would be a
reasonable approach.  It sounds like I misunderstood, and that you
were suggesting simply using the existing b-l-u-h for code that should
run when the selected window changes non-ephemerally.  Is that right?

As an experiment, I just evaluated this form with `eval-expression':

  (progn
    (setq bluh-hist nil)
    (add-hook 'buffer-list-update-hook
              (lambda (&rest args)
                (push (format "%s: %s" (buffer-name) args)
                      bluh-hist))))

A few seconds later bluh-hist had grown to contain several hundred
elements, even though I did not interact with Emacs at all during the
interim.  All of my open buffers appear to be represented in that list,
including ERC buffers, source code buffers, *scratch*, *Backtrace*,
etc.  I have not yet tried this experiment with -q/-Q so it's possible
this behavior is being caused by some of my own code or a library,
but if this expected behavior then b-l-u-h doesn't seem well-suited
to the problem I'd like to solve.

Thanks,
Josh

Re: [PATCH] frame.c: focus hooks

[martin rudalics]

 > I originally interpreted your mention of it as additional evidence that
 > deciding whether or not to call a new select-window-hook from
 > Fselect_window based on its NORECORD argument would be a
 > reasonable approach.  It sounds like I misunderstood, and that you
 > were suggesting simply using the existing b-l-u-h for code that should
 > run when the selected window changes non-ephemerally.  Is that right?

Both interpretations are valid:

(1) The first interpretation means (implicitly) that we could replace
     the call to `buffer-list-update-hook' by calling instead something
     we could name `record-buffer-hook'.

(2) The second interpretation means that your function would have to
     filter the calls of `buffer-list-update-hook' appropriately.

 > As an experiment, I just evaluated this form with `eval-expression':
 >
 >   (progn
 >     (setq bluh-hist nil)
 >     (add-hook 'buffer-list-update-hook
 >               (lambda (&rest args)
 >                 (push (format "%s: %s" (buffer-name) args)
 >                       bluh-hist))))
 >
 > A few seconds later bluh-hist had grown to contain several hundred
 > elements, even though I did not interact with Emacs at all during the
 > interim.  All of my open buffers appear to be represented in that list,
 > including ERC buffers, source code buffers, *scratch*, *Backtrace*,
 > etc.  I have not yet tried this experiment with -q/-Q so it's possible
 > this behavior is being caused by some of my own code or a library,
 > but if this expected behavior then b-l-u-h doesn't seem well-suited
 > to the problem I'd like to solve.

You didn't explain _what_ you want to solve.  Adding the name of the
current buffer whenever a hook is run doesn't sound very reasonable to
me.

Consider the following construct:

(defvar my-window nil)

(defun foo ()
   (unless (eq (selected-window) my-window)
     (setq my-window (selected-window))
     (ding)))

(add-hook 'buffer-list-update-hook 'foo)

Here it beeps whenever the selected window visibly changes.  What
more/less do you want/need?  If you give me an example where you cannot
apply (2), that is, filter the changes of which window is selected from
the `buffer-list-update-hook'-run function we can always add a new hook
as sketched in (1) above.  But obviously not adding a new hook would be
the cheaper solution.

martin

Re: [PATCH] frame.c: focus hooks

[Josh]

On Sun, Jan 12, 2014 at 1:54 AM, martin rudalics <rudalics@gmx.at> wrote:
>> I originally interpreted your mention of it as additional evidence that
>> deciding whether or not to call a new select-window-hook from
>> Fselect_window based on its NORECORD argument would be a
>> reasonable approach.  It sounds like I misunderstood, and that you
>> were suggesting simply using the existing b-l-u-h for code that should
>> run when the selected window changes non-ephemerally.  Is that right?
>
> Both interpretations are valid:
>
> (1) The first interpretation means (implicitly) that we could replace
>     the call to `buffer-list-update-hook' by calling instead something
>     we could name `record-buffer-hook'.

I'm not sure I understand.  I see that near the end of select_window
we now call record_buffer, which in turn runs `buffer-list-update-hook';
are you suggesting that if we went down this path then record_buffer
would run a new `record-buffer-hook' (and no longer run
`buffer-list-update-hook')?

>> As an experiment, I just evaluated this form with `eval-expression':
>>
>>   (progn
>>     (setq bluh-hist nil)
>>     (add-hook 'buffer-list-update-hook
>>               (lambda (&rest args)
>>                 (push (format "%s: %s" (buffer-name) args)
>>                       bluh-hist))))
>>
>> A few seconds later bluh-hist had grown to contain several hundred
>> elements, even though I did not interact with Emacs at all during the
>> interim.  All of my open buffers appear to be represented in that list,
>> including ERC buffers, source code buffers, *scratch*, *Backtrace*,
>> etc.  I have not yet tried this experiment with -q/-Q so it's possible
>> this behavior is being caused by some of my own code or a library,
>> but if this expected behavior then b-l-u-h doesn't seem well-suited
>> to the problem I'd like to solve.
>
> You didn't explain _what_ you want to solve.  Adding the name of the
> current buffer whenever a hook is run doesn't sound very reasonable to
> me.

Sure, it was just an experiment intended to help me understand how
often that hook is run and under what conditions.

> Consider the following construct:
>
> (defvar my-window nil)
>
> (defun foo ()
>   (unless (eq (selected-window) my-window)
>     (setq my-window (selected-window))
>     (ding)))
>
> (add-hook 'buffer-list-update-hook 'foo)
>
> Here it beeps whenever the selected window visibly changes.  What
> more/less do you want/need?  If you give me an example where you cannot
> apply (2), that is, filter the changes of which window is selected from
> the `buffer-list-update-hook'-run function we can always add a new hook
> as sketched in (1) above.  But obviously not adding a new hook would be
> the cheaper solution.

Thanks for explanation and suggestion.  I'll experiment some more
to see if there's a reasonable way to obtain the desired behavior
with the existing machinery, which I agree would be better than
introducing a new hook.

Incidentally, I just noticed that though record_buffer runs
`buffer-list-update-hook' it's not mentioned in the docstring:

    Functions running this hook are `get-buffer-create',
    `make-indirect-buffer', `rename-buffer', `kill-buffer',
    and `bury-buffer-internal'.

Perhaps this is intentional because record_buffer is not exposed at
the Lisp level, though?

Thanks,
Josh

>
> martin

Re: [PATCH] frame.c: focus hooks

[martin rudalics]

 >> (1) The first interpretation means (implicitly) that we could replace
 >>     the call to `buffer-list-update-hook' by calling instead something
 >>     we could name `record-buffer-hook'.
 >
 > I'm not sure I understand.  I see that near the end of select_window
 > we now call record_buffer, which in turn runs `buffer-list-update-hook';
 > are you suggesting that if we went down this path then record_buffer
 > would run a new `record-buffer-hook' (and no longer run
 > `buffer-list-update-hook')?

Yes.  All callers of `buffer-list-update-hook' would then have to call
`record-buffer-hook' too.

 >> You didn't explain _what_ you want to solve.  Adding the name of the
 >> current buffer whenever a hook is run doesn't sound very reasonable to
 >> me.
 >
 > Sure, it was just an experiment intended to help me understand how
 > often that hook is run and under what conditions.

Aha.  You now know that it's run too often for your needs.  But doesn't
`select-window' also run too often for you, for example, when selecting
the minibuffer window?

 > Thanks for explanation and suggestion.  I'll experiment some more
 > to see if there's a reasonable way to obtain the desired behavior
 > with the existing machinery, which I agree would be better than
 > introducing a new hook.

If you told me a bit what you the "desired behavior" is, I might provide
suggestions.

 > Incidentally, I just noticed that though record_buffer runs
 > `buffer-list-update-hook' it's not mentioned in the docstring:
 >
 >     Functions running this hook are `get-buffer-create',
 >     `make-indirect-buffer', `rename-buffer', `kill-buffer',
 >     and `bury-buffer-internal'.
 >
 > Perhaps this is intentional because record_buffer is not exposed at
 > the Lisp level, though?

Hmm...  Actually it's not there because I have added it only recently.
Stefan soon detected some bug in the initial change so it's not safe yet
either.  That is, if you do something silly there, you might easily
infloop or crash Emacs.  But the same would obviously hold for a
`select-window-hook'.

martin

Re: [PATCH] frame.c: focus hooks

[Stefan Monnier]

> Such a hook would be an improvement but not ideal, since some
> selected-window changes of interest may not result from a user
> command, e.g. those due to a non-nil compilation-auto-jump-to-first-error.

Agreed.  And I think this is a fairly general problem.
We should provide a new hook that is run whenever we begin waiting for
a command.

The new pre-redisplay-function provides something pretty close.
Maybe you could try using this instead.


        Stefan

Re: [PATCH] frame.c: focus hooks

[Josh]

On Fri, Jan 10, 2014 at 9:31 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Such a hook would be an improvement but not ideal, since some
>> selected-window changes of interest may not result from a user
>> command, e.g. those due to a non-nil compilation-auto-jump-to-first-error.
>
> Agreed.  And I think this is a fairly general problem.
> We should provide a new hook that is run whenever we begin waiting for
> a command.
>
> The new pre-redisplay-function provides something pretty close.
> Maybe you could try using this instead.


I will do so.  Thanks for the suggestion!

Re: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

>
>     That is, I expect that they won't be assigned by *polite* Lisp
> packages.
>     It would be rude to set these hooks in a package published for
>     widespread use.
>
> Then at least they should be documented so as to tell people
> not to do this.


Good point.  I will add such documentation.

Best,
Brian Jenkins

[-- Attachment #2: Type: text/html, Size: 621 bytes --]

Re: [PATCH] frame.c: focus hooks

[Jarek Czekalski]

If it's clearly logical, as you pointed out, that using such a hook in a 
package may be harmful, documenting it makes no point. If one wants to 
release a package whose main goal is to do something on focus-in, why 
shouldn't they use the hook? If a package has an option "do ... on focus 
lost" and it may be activated or not, why shouldn't it use the hook?

I think you had just a misunderstanding and no documentation changes are 
needed.

Every hook may be used in a wrong or malicious matter. Why to put 
special warnings in these 2 only?

Crowding the documentation with warnings that are obvious to an average 
developer is not a good idea.

Jarek

Re: [PATCH] frame.c: focus hooks

[Glenn Morris]

Brian Jenkins wrote:

> I'd like to contribute the attached patch, which adds hooks into gain and
> loss of focus events.

Thanks. This surprisingly controversial issue is
http://debbugs.gnu.org/15029

Re: [PATCH] frame.c: focus hooks

[Stefan Monnier]

> I'd like to contribute the attached patch, which adds hooks into gain and
> loss of focus events.

That looks good to me.  Can someone install it?


        Stefan

Re: [PATCH] frame.c: focus hooks

[Leo Liu]

On 2013-11-18 01:50 +0800, Brian Jenkins wrote:
> People will probably find other handy uses for these hooks.

How about name it frame-focus-hook? and pass `t' to hook functions when
gained focus and `nil' when lost focus?

Leo

Fwd: [PATCH] frame.c: focus hooks

[Brian Jenkins]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

Hi, Leo.

Thanks for the suggestion.

It's my understanding that the convention for hooks to receive no
arguments and for more complicated functions to be used only when
necessary.

From the Emacs info page 48.2.2

    Most hooks are "normal hooks".  This means that when Emacs runs the
    hook, it calls each hook function in turn, with no arguments.  We
    have made an effort to keep most hooks normal, so that you can use
    them in a uniform way.  Every variable whose name ends in `-hook' is
    a normal hook.

    A few hooks are "abnormal hooks".  Their names end in `-functions',
    instead of `-hook' (some old code may also use the deprecated suffix
    `-hooks').  What makes these hooks abnormal is the way its functions
    are called--perhaps they are given arguments, or perhaps the values
    they return are used in some way.  For example,
    `find-file-not-found-functions' is abnormal because as soon as one
    hook function returns a non-`nil' value, the rest are not called at
    all (*note Visiting::).  The documentation of each abnormal hook
    variable explains how its functions are used.

I'd like to keep things as simple as possible.  I think two normal hooks
are simpler than one abnormal hook.

Brian


On Sun, Nov 17, 2013 at 11:11 PM, Leo Liu <sdl.web@gmail.com> wrote:

> On 2013-11-18 01:50 +0800, Brian Jenkins wrote:
> > People will probably find other handy uses for these hooks.
>
> How about name it frame-focus-hook? and pass `t' to hook functions when
> gained focus and `nil' when lost focus?
>
> Leo
>

[-- Attachment #2: Type: text/html, Size: 2522 bytes --]