unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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)




  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).