request: make-frame-visible hook

request: make-frame-visible hook

[John J Foerch]

Hello,

   I make use of the [make-frame-visible] event in special-event-map in
order to update some emacs-related satus messages in my window manager.
However, with recent CVS emacs, another library called dframe has
registered a handler on this event.  My feature request is that there be
a hook for the make-frame-visible event, so that multiple handlers can
peacefully coexist.

  Thank you.

-- 
John Foerch

Re: request: make-frame-visible hook

[John J Foerch]

> Hello,
>
>    I make use of the [make-frame-visible] event in special-event-map in
> order to update some emacs-related satus messages in my window manager.
> However, with recent CVS emacs, another library called dframe has
> registered a handler on this event.  My feature request is that there be
> a hook for the make-frame-visible event, so that multiple handlers can
> peacefully coexist.
>
>   Thank you.

Hello,

  I just wanted to follow up to hopefully find out the likelihood of a
make-frame-visible-hook in emacs in the future.  The make-frame-visible
event is very useful for, e.g. updating buffer-tracking notification in
modules like erc-track (in erc) or tracking (in circe) when a frame is
made visible because of changing desktops/workspaces in a window
manager.

Thank you.

-- 
John Foerch

Re: request: make-frame-visible hook

[Richard M Stallman]

      The make-frame-visible
    event is very useful for, e.g. updating buffer-tracking notification in
    modules like erc-track (in erc)

Could you explain why it is useful to keep track of which frames
are visible?

				    or tracking (in circe) when a frame is
    made visible because of changing desktops/workspaces in a window
    manager.

Could you explain what that means?  Why does changing desktops affect
frame visibility?  The window manager I use (a common one) offers 4
desktops in parallel, but I don't think switching between them has any
effect on Emacs frame visibility, because the frames on other desktops
are nonetheless visible.

Re: request: make-frame-visible hook

[Lynbech Christian]

>>>>> "RMS" == Richard M Stallman <rms@gnu.org> writes:

RMS> The window manager I use (a common one) offers 4 desktops in
RMS> parallel, but I don't think switching between them has any effect
RMS> on Emacs frame visibility, because the frames on other desktops are
RMS> nonetheless visible.

That depends, I guess, a bit on how the window manager has implemented the
parallel desktops. One trick under X11 is to actually unmap and map windows
as you change from desktop to desktop. At least that is how the Eclipse
window manager does it (although that admittedly is not a common WM, even
if written in Common Lisp :-)

This way of doing things will generate a slew of (Un)MapNotify X11 events
which could be noticed by emacs.

Whether or not visibility tracking could be construed as useful, the
problem still stands that there are multiple applications that wants to
install stuff into special-event-map so perhaps a more generic solution
should be sought such that multiple handlers can be present or registered
for any event in that map?


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: request: make-frame-visible hook

[Stefan Monnier]

> Whether or not visibility tracking could be construed as useful, the
> problem still stands that there are multiple applications that wants to
> install stuff into special-event-map so perhaps a more generic solution
> should be sought such that multiple handlers can be present or registered
> for any event in that map?

We could easily setup a default handler that defers to a frame-local
make-frame-visible hook, indeed.  But before doing that I think we'd
need to see what those things are used for.  E.g. why does dframe mess
with the make-frame-visible events?  What do you concretely do with
those events?


        Stefan

Re: request: make-frame-visible hook

[John J Foerch]

Richard M Stallman <rms@gnu.org> writes:
>       The make-frame-visible
>     event is very useful for, e.g. updating buffer-tracking notification in
>     modules like erc-track (in erc)
>
> Could you explain why it is useful to keep track of which frames
> are visible?
>
> 				    or tracking (in circe) when a frame is
>     made visible because of changing desktops/workspaces in a window
>     manager.
>
> Could you explain what that means?  Why does changing desktops affect
> frame visibility?  The window manager I use (a common one) offers 4
> desktops in parallel, but I don't think switching between them has any
> effect on Emacs frame visibility, because the frames on other desktops
> are nonetheless visible.


Hi Richard,

  Certainly.  Let me answer your second question first.  I'm using the
window manager XMonad, and when I switch to a workspace containing some
emacs frame, the make-frame-visible event is fired for that frame.  I
did not realize other WMs did not necessarily work the same way.

  I have used the emacs irc clients Circe and Erc, which both provide
modes to track activity in hidden irc buffers.  "Hidden" may mean a
buffer that is not visible in any frame, or a buffer shown in a
non-visible frame.  The irc channels with new activity are indicated in
the mode-line.  Switching to a tracked buffer removes that buffer's
indicator from the mode-line.

  What I would like to achieve is to have the make-frame-visible event
trigger an update of the tracking indicator, so that when I switch to a
workspace which contains an emacs frame in which a tracked buffer is
visible, the indicator for that buffer will be removed from the
mode-line tracking indicator.

  I have been able to get this effect in the past by registering a
handler in special-event-map, but that method is not good, because other
modules (like dframe) put their own handlers on the same event.

Thank you.

-- 
John Foerch

Re: request: make-frame-visible hook

[Richard M Stallman]

      I have used the emacs irc clients Circe and Erc, which both provide
    modes to track activity in hidden irc buffers.  "Hidden" may mean a
    buffer that is not visible in any frame, or a buffer shown in a
    non-visible frame.  The irc channels with new activity are indicated in
    the mode-line.  Switching to a tracked buffer removes that buffer's
    indicator from the mode-line.

I don't think I would add an Emacs feature for the sake of this.
However, you might be able to get more or less the same result
by triggering off the arrival of output from a process or connection
and seeing which IRC buffers are currently displayed.

Re: request: make-frame-visible hook

[Stefan Monnier]

>       I have used the emacs irc clients Circe and Erc, which both provide
>     modes to track activity in hidden irc buffers.  "Hidden" may mean a
>     buffer that is not visible in any frame, or a buffer shown in a
>     non-visible frame.  The irc channels with new activity are indicated in
>     the mode-line.  Switching to a tracked buffer removes that buffer's
>     indicator from the mode-line.

> I don't think I would add an Emacs feature for the sake of this.
> However, you might be able to get more or less the same result
> by triggering off the arrival of output from a process or connection
> and seeing which IRC buffers are currently displayed.

Or using fontification-functions: when process output comes along, check
the visibility of the buffer: if it's not currently visible, remove the
`fontified' property on the inserted text, such that when the buffer
gets displayed in the future, fontification-functions will get called,
so you know that the text has now been displayed.  You can even then
highlight the text especially to grab the user's attention.


        Stefan

Re: request: make-frame-visible hook

[John J Foerch]

Richard M Stallman <rms@gnu.org> writes:
>       I have used the emacs irc clients Circe and Erc, which both provide
>     modes to track activity in hidden irc buffers.  "Hidden" may mean a
>     buffer that is not visible in any frame, or a buffer shown in a
>     non-visible frame.  The irc channels with new activity are indicated in
>     the mode-line.  Switching to a tracked buffer removes that buffer's
>     indicator from the mode-line.
>
> I don't think I would add an Emacs feature for the sake of this.
> However, you might be able to get more or less the same result
> by triggering off the arrival of output from a process or connection
> and seeing which IRC buffers are currently displayed.


  What you describe is implemented in both of the irc clients I
mentioned.  They update the mode-line tracking indicator when new data
arrives from the process, but this is not often enough, and it is the
situation I would like to improve upon.  A typical case for the new
feature would be as follows:

  I have an emacs frame open on workspace 1, and my mode-line indicates
that there is activity in an irc channel.  I switch to workspace 2,
where I have a frame showing the active irc channel.  Without the
ability to use the make-frame-visible event, the mode-line tracking
indicator will continue to show that buffer, possibly for minutes until
more data comes from the process.  If I switch back to workspace 1, and
the tracking indicator still has not been updated, I cannot then know
when the next new data arrives from the process, because the indicator
is now falsely on, though I have already read the buffer.

  I guess I am not sure what the point of having a make-frame-visible
event is, if there can only be one handler on it.

  Thank you for your time.  I hope you will reconsider.

-- 
John Foerch

Re: request: make-frame-visible hook

[Lynbech Christian]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> We could easily setup a default handler that defers to a frame-local
Stefan> make-frame-visible hook, indeed.  

Yes, that would certainly by a solution. However, we can get the same
problem for any binding in special-event-map. Currently it contains 3
entries from dframe, two ignored entries and the two more so surely will
get into this again, which is why I suggest doing a generic solution,
not just one particular hook for make-frame-visible.

I can think of the following two basic solutions:

  - Keep special-event-map as is and document how to have multiple
    handlers for a particular event. This requires, IMHO, that there is
    a deign rule for all libraries supplied with emacs that they can
    only install stuff in special-event-map if they follow the
    documented procedure for multi handlers (for instance, to make sure
    that there are hook variables for the user).

  - Allow entries in special-event-map to be either a symbol or a list
    of symbols, the latter case effectively being a hook allowing
    multiple instances, possibly combined with an access function in the
    spirit of add-hook that makes sure nothing is overwritten. Here the
    design rule should be that no library function can mess with
    special-event-map withoput using the access function.

One could of course also have a design rule that says that library
function should leave special-event-map alone, reserving it entirely for
users but it will not really solve the situation where external
libraries start fighting for control over an event.

------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: request: make-frame-visible hook

[Lynbech Christian]

I do not know if you caught this, just want to make sure that you do,
but as Stefan hinted you can fix the problem yourself. Just make sure
dframe is loaded, overwrite the entry with your own function which runs
a hook where you then stores anything that was in special-event-map
before you put your own little function there.

Alternatively you can consider using post-command-hook, this is run all
the time and this particular problem should not pose a performance
problem.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: request: make-frame-visible hook

[Stefan Monnier]

> Yes, that would certainly by a solution. However, we can get the same
> problem for any binding in special-event-map. Currently it contains 3
> entries from dframe, two ignored entries and the two more so surely will
> get into this again, which is why I suggest doing a generic solution,
> not just one particular hook for make-frame-visible.

The dframe entries are the problem, I think: special-event-map is
usually only used for internal purposes.  It's not designed for
packages, nor for users.

I'm not sure what dframe does with those things: AFAICT it binds them to
functions that introduce just the kind of hook you asked for (but oddly
using buffer-local hooks rather than frame-local hooks).  Of the three
such hooks it installs, only the delete-frame one is used (by
speedbar).  And it turns out that speedbar could/should use
delete-frame-functions instead anyway.

So I see two solutions to your problem:
1- declare dframe's code as a bug.
2- use (require 'dframe) and then use dframe-make-frame-visible-function.


        Stefan

Re: request: make-frame-visible hook

[John J Foerch]

Lynbech Christian <christian.lynbech@tieto.com> writes:
> I do not know if you caught this, just want to make sure that you do,
> but as Stefan hinted you can fix the problem yourself. Just make sure
> dframe is loaded, overwrite the entry with your own function which runs
> a hook where you then stores anything that was in special-event-map
> before you put your own little function there.
>
> Alternatively you can consider using post-command-hook, this is run all
> the time and this particular problem should not pose a performance
> problem.


  Thank you for the ideas.  I am still hoping that at some point in the
future emacs will have a general solution to the problem, because
letting users and modes use special-event-map without conflicts and
hacks seems simple, logical, and useful.  (Why does special-event-map
exist if we can't use it safely?)  I can implement
make-frame-visible-hook in my .emacs, and require dframe, etc, and I
will do that if it is the only way, but unfortunately this prevents me
from submitting my improvement to tracking-mode or erc-track for others
to use.

  As a side-note, post-command-hook will not help in this situation
because tracking-mode already uses window-configuration-change-hook, but
the need to call an arbitrary command to force an update is precisely
what I am trying to avoid.

Thank you.

-- 
John Foerch

Re: request: make-frame-visible hook

[Miles Bader]

Lynbech Christian <christian.lynbech@tieto.com> writes:
> Alternatively you can consider using post-command-hook, this is run all
> the time and this particular problem should not pose a performance
> problem.

Using post-command-hook _will_ pose a performance problem if everybody
and their dog gets in the habit of using it... unfortunately, this seems
to be happening already.

Please do not use post-command-hook if you can help it.  We don't want
to encourage its use.

-Miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: request: make-frame-visible hook

[Richard M Stallman]

    Please do not use post-command-hook if you can help it.  We don't want
    to encourage its use.

Would you like to look for the packages that use it and try to change
them not to, or ask other relevant developers to do so?

Re: request: make-frame-visible hook

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Lynbech Christian <christian.lynbech@tieto.com> writes:
>> Alternatively you can consider using post-command-hook, this is run all
>> the time and this particular problem should not pose a performance
>> problem.
>
> Using post-command-hook _will_ pose a performance problem if everybody
> and their dog gets in the habit of using it... 

I know people are repeating this claim again and again as "gospel truth".

However, I strongly doubt this is really true in practice.
The amount of lisp code executed in the post-command-hook is not nearly
comparable to the amount of work done in redisplay for every (non-trivial)
keypress...  

E.g. just hitting RET performs - I would guess - 1000 times the code anybody
has every put into the post-command-hook...

IMO, the real problem using post-command-hook is that there is no way to
control the sequence of things that is done via that hook - so if you have
two packages putting stuff on the hook - and they both do something which
modifies either buffer contents or visual appearence - then users may see
different results depending on which package is loaded first.

So I agree that using post-command-hook is not a good thing
.. unfortunately there are not many hooks in Emacs which can do global
things - and there seem to be a reluctance to adding "necessary" hooks
(in the sense that the alternative is to use post-commmand-hook).

E.g. where is:
 before-modify-buffer-hook  (run before changing buffer)
 after-modify-buffer-hook  (run after changing buffer)
 before-cursor-move-hook
 after-cursor-move-hook
 before-window-buffer-change-hook
 after-window-buffer-change-hook
 focus-window-hook
 unfocus-window-hook
 enter-buffer-hook
 exit-buffer-hook
etc. etc. etc.

I'm not going to discuss semantics of those hooks here, but these things
are typically used for stuff that would currently involve pre-command-hook and
post-command-hook code to notice and react to specific state changes.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: request: make-frame-visible hook

[Stefan Monnier]

> IMO, the real problem using post-command-hook is that there is no way to
> control the sequence of things that is done via that hook - so if you have
> two packages putting stuff on the hook - and they both do something which
> modifies either buffer contents or visual appearence - then users may see
> different results depending on which package is loaded first.

Another problem with it is that it is not always sufficient: stuff can
happen in Emacs without post-command-hook being run (e.g. process
filters, sentinels, ...).  Sometimes per/post-redisplay-hook would be
closer to what is needed.


        Stefan

Re: request: make-frame-visible hook

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Sat, 21 Feb 2009 03:11:36 +0100
> Cc: emacs-devel@gnu.org
> 
> Miles Bader <miles@gnu.org> writes:
> 
> > Lynbech Christian <christian.lynbech@tieto.com> writes:
> >> Alternatively you can consider using post-command-hook, this is run all
> >> the time and this particular problem should not pose a performance
> >> problem.
> >
> > Using post-command-hook _will_ pose a performance problem if everybody
> > and their dog gets in the habit of using it... 
> 
> I know people are repeating this claim again and again as "gospel truth".
> 
> However, I strongly doubt this is really true in practice.
> The amount of lisp code executed in the post-command-hook is not nearly
> comparable to the amount of work done in redisplay for every (non-trivial)
> keypress...  
> 
> E.g. just hitting RET performs - I would guess - 1000 times the code anybody
> has every put into the post-command-hook...

Of course, this depends on what is put into post-command-hook.  For
example, doing spell-check there, which involves interaction with a
subprocess, _does_ give you a performance hit that is quite
noticeable.

Re: request: make-frame-visible hook

[martin rudalics]

 > Of course, this depends on what is put into post-command-hook.  For
 > example, doing spell-check there, which involves interaction with a
 > subprocess, _does_ give you a performance hit that is quite
 > noticeable.

That's why on-the-fly spell-checking has to be done with a timer.  Even
the people who wrote Microsoft Word knew that ...

martin

Re: request: make-frame-visible hook

[Richard M Stallman]

     before-modify-buffer-hook  (run before changing buffer)
     after-modify-buffer-hook  (run after changing buffer)

Modification hooks already do exist.
Are they somehow inadequate?

     before-cursor-move-hook
     after-cursor-move-hook

Text properties exist to do this.
Are they somehow inadequate?

     before-window-buffer-change-hook
     after-window-buffer-change-hook
     focus-window-hook
     unfocus-window-hook
     enter-buffer-hook
     exit-buffer-hook

What packages would want these, and what are they trying to do?

Re: request: make-frame-visible hook

[Stefan Monnier]

> E.g. where is:
>  before-modify-buffer-hook  (run before changing buffer)
>  after-modify-buffer-hook  (run after changing buffer)

How would they differ from (before|after)-change-functions?

>  focus-window-hook

I played with something similar for frames, but in that case thw frame
had a single window, so it would work as well (the frame was
a minibuffer-only frame, and the purpose of the hook was to slide the
window back into view in an "auto-hide" mode similar to what
taskbars/docks can do).


        Stefan

Re: request: make-frame-visible hook

[Kim F. Storm]

Richard M Stallman <rms@gnu.org> writes:

>      before-modify-buffer-hook  (run before changing buffer)
>      after-modify-buffer-hook  (run after changing buffer)
>
> Modification hooks already do exist.
> Are they somehow inadequate?

Can't remember offhand - maybe.

>
>      before-cursor-move-hook
>      after-cursor-move-hook
>
> Text properties exist to do this.
> Are they somehow inadequate?

It is not appropriate for "global modes" to add text properties
everywhere - that's even worse than using post-command-hook IMO.

>
>      before-window-buffer-change-hook
>      after-window-buffer-change-hook
>      focus-window-hook
>      unfocus-window-hook
>      enter-buffer-hook
>      exit-buffer-hook
>
> What packages would want these, and what are they trying to do?

I cannot say for sure.

I have had various ideas over the years, but did not pursue them
of lack of a simple way to hook this into existing framework.

One example I recall is to properly restore window buffers 
after displaying the *Help* buffer - the current "suggested
restore previous buffer command" falls flat on its face if
you have two windows showing different portions of the same buffer - 
and one of the windows is taken by the *Help* buffer.

Focus/unfocus window would be used to change the background
color of active/inactive window.

enter-buffer / exit-buffer I know I needed at some point, but
I don't recall right now.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: request: make-frame-visible hook

[Bo Lin]

Richard M Stallman <rms@gnu.org> writes:
>
>      before-window-buffer-change-hook
>      after-window-buffer-change-hook
>      focus-window-hook
>      unfocus-window-hook
>      enter-buffer-hook
>      exit-buffer-hook
>
> What packages would want these, and what are they trying to do?

winner-mode (included in Emacs) uses a `post-command-hook' to save old
window configurations due to a lack of
`before-window-configuration-change-hook'. It tries to automatically
keep track of window configuration changes so the user can "go back" to
a previous window configuration without having to have manually "saved"
the old configuration beforehand. It is analogous to how web browsers
keep a history of pages visited in a browsing session. In order to do
that it needs to be notified when the window configuration is about to
change but before the change has actually occurred, so
`window-configuration-change-hook' is not sufficient.

Re: request: make-frame-visible hook

[Richard M Stallman]

    In order to do
    that it needs to be notified when the window configuration is about to
    change but before the change has actually occurred, so
    `window-configuration-change-hook' is not sufficient.

If `window-configuration-change-hook' is ok, then
`before-window-buffer-change-hook' is ok.