From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lynbech Christian Newsgroups: gmane.emacs.devel Subject: Re: request: make-frame-visible hook Date: Thu, 19 Feb 2009 14:07:56 +0100 Message-ID: References: <87fxidj8gt.fsf@earthlink.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1235049002 2277 80.91.229.12 (19 Feb 2009 13:10:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Feb 2009 13:10:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 19 14:11:18 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1La8ej-00074R-80 for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2009 14:09:33 +0100 Original-Received: from localhost ([127.0.0.1]:53679 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1La8dO-0005mK-NV for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2009 08:08:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1La8dH-0005m8-HY for emacs-devel@gnu.org; Thu, 19 Feb 2009 08:08:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1La8dG-0005lo-A0 for emacs-devel@gnu.org; Thu, 19 Feb 2009 08:08:02 -0500 Original-Received: from [199.232.76.173] (port=50061 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1La8dG-0005ll-5T for emacs-devel@gnu.org; Thu, 19 Feb 2009 08:08:02 -0500 Original-Received: from ebb06.tieto.com ([131.207.168.38]:40949 helo=ebb06.tietoenator.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1La8dF-0000Vt-F3 for emacs-devel@gnu.org; Thu, 19 Feb 2009 08:08:01 -0500 X-AuditID: 83cfa826-a334dbb000000814-fe-499d59ae2983 Original-Received: from camaro.eu.tieto.com (unknown [192.176.143.43]) by ebb06.tietoenator.com (SMTP Mailer) with ESMTP id 5C97336A4A4; Thu, 19 Feb 2009 15:07:58 +0200 (EET) Original-Received: from ul000205.eu.tieto.com ([10.48.99.12]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 14:07:57 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 18 Feb 2009 11:54:16 -0500") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) X-OriginalArrivalTime: 19 Feb 2009 13:07:57.0979 (UTC) FILETIME=[15C416B0:01C99293] X-Brightmail-Tracker: AAAAAQ2ublk= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:109217 Archived-At: >>>>> "Stefan" == Stefan Monnier 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)