From: Lynbech Christian <christian.lynbech@tieto.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: request: make-frame-visible hook
Date: Thu, 19 Feb 2009 14:07:56 +0100 [thread overview]
Message-ID: <ytqpljs24lsj.fsf@ul000205.eu.tieto.com> (raw)
In-Reply-To: <jwvfxibwuue.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 18 Feb 2009 11:54:16 -0500")
>>>>> "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)
next prev parent reply other threads:[~2009-02-19 13:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-09 20:14 request: make-frame-visible hook John J Foerch
2009-02-17 17:09 ` John J Foerch
2009-02-18 12:09 ` Richard M Stallman
2009-02-18 14:59 ` Lynbech Christian
2009-02-18 16:54 ` Stefan Monnier
2009-02-19 13:07 ` Lynbech Christian [this message]
2009-02-19 17:13 ` Stefan Monnier
2009-02-18 17:14 ` John J Foerch
2009-02-18 23:05 ` Richard M Stallman
2009-02-18 23:44 ` Stefan Monnier
2009-02-19 1:27 ` John J Foerch
2009-02-19 13:24 ` Lynbech Christian
2009-02-20 0:01 ` John J Foerch
2009-02-20 1:28 ` Miles Bader
2009-02-20 13:31 ` Richard M Stallman
2009-02-21 2:11 ` Kim F. Storm
2009-02-21 2:23 ` Stefan Monnier
2009-02-21 9:11 ` Eli Zaretskii
2009-02-21 14:10 ` martin rudalics
2009-02-21 17:41 ` Richard M Stallman
2009-02-21 20:59 ` Kim F. Storm
2009-02-22 3:31 ` Bo Lin
2009-02-22 14:35 ` Richard M Stallman
2009-02-21 20:43 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ytqpljs24lsj.fsf@ul000205.eu.tieto.com \
--to=christian.lynbech@tieto.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.