From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: replacing process sentinels and filters with hooks Date: Wed, 03 Oct 2012 09:37:33 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349271492 30659 80.91.229.3 (3 Oct 2012 13:38:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2012 13:38:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Christopher Monsanto Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 03 15:38:17 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TJP94-0005CV-S9 for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 15:37:51 +0200 Original-Received: from localhost ([::1]:44597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJP8z-0000yz-7r for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 09:37:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJP8v-0000yW-MI for emacs-devel@gnu.org; Wed, 03 Oct 2012 09:37:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJP8p-0002DU-MZ for emacs-devel@gnu.org; Wed, 03 Oct 2012 09:37:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:32949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJP8p-0002DM-I9 for emacs-devel@gnu.org; Wed, 03 Oct 2012 09:37:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxLQG/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLDiYSFBgNJC6HbgW6CZBEA6MzgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="200551075" Original-Received: from 69-196-180-6.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 03 Oct 2012 09:37:34 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A9B5D594E8; Wed, 3 Oct 2012 09:37:33 -0400 (EDT) In-Reply-To: (Christopher Monsanto's message of "Wed, 3 Oct 2012 06:59:58 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154004 Archived-At: > way of doing things?", I'm referring to the fact that add-function and > add-hook do similar things and it would be ideal (in my opinion) to > not have two general purpose APIs that (almost?) do the same thing. I agree that having both add-hook and add-function is not ideal. But I think the ideal solution doesn't exist because of constraints imposed by backward compatibility. > Hooks could use an interface similar to defadvice to change their > arguments: (hook-set-arg ) would modify the argument > being passed to the next hook. Hmm... that sounds ugly. Because we also want to let a function prevent the subsequent functions from being run. IOW we want to be able to have the equivalent of an `around' advice. I think something along the lines of what with-wrapper-hook does is a good model (i.e. (add-function (process-filter proc) fun) would take a `fun' which expects 3 args: the proc, the string, and a "keep-running-the-hook" function which expects 2 args (the proc and the string)). Then we can also define (defmacro add-function-before (place fun) `(add-function ,place (lambda (fallback-fun &rest args) (apply ,fun args) (apply fallback-fun args)))) Which is more like `add-hook'; and (defmacro add-function-after (place fun) `(add-function ,place (lambda (fallback-fun &rest args) (apply fallback-fun args) (apply ,fun args)))) which is a bit like "add-hook with the append arg set". > Yes, there seems to be a bit of ugliness in this case with > process-callbacks needing to return a symbol. Yes, that's one ugliness. The other problem with it is that it means that it doesn't solve the problem for other "objects holding a function" such as symbol-function, or syntax-propertize-function. > In this case, I just think of a symbol as acting as a reference type > in ML, so it doesn't bother me too much I guess. As a functional programmer, that's very much the way I think about it, indeed. But the advantage of add-function (assuming we can write it) is that it can work for anything that holds a function. E.g. we wouldn't even need to change process-filter (I'd still consider changing process-sentinel to clean up its string argument). I.e. not only we can preserve backward compatibility, but we don't even need to obsolete anything. > I've copied the rest of your message below, as it wasn't sent to the > list. My apologies if it was meant to be private. Thank you for that (I actually did send it to the list "by hand" via `resend' after noticing, IIRC). Stefan