[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: request: make-frame-visible hook

From: Lynbech Christian
Subject: Re: request: make-frame-visible hook
Date: Thu, 19 Feb 2009 14:07:56 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

>>>>> "Stefan" == Stefan Monnier <address@hidden> 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.
                                        - address@hidden (Michael A. Petonic)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]