From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christopher Monsanto Newsgroups: gmane.emacs.devel Subject: Re: replacing process sentinels and filters with hooks Date: Wed, 3 Oct 2012 06:59:58 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1349262113 13033 80.91.229.3 (3 Oct 2012 11:01:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2012 11:01:53 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 03 13:01:57 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 1TJMhH-0004eM-IE for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 13:00:59 +0200 Original-Received: from localhost ([::1]:48511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJMhC-0007M1-2t for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 07:00:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJMh4-0007LV-My for emacs-devel@gnu.org; Wed, 03 Oct 2012 07:00:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJMgz-0006ef-2V for emacs-devel@gnu.org; Wed, 03 Oct 2012 07:00:46 -0400 Original-Received: from mail-vc0-f169.google.com ([209.85.220.169]:62114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJMgy-0006eX-TX for emacs-devel@gnu.org; Wed, 03 Oct 2012 07:00:40 -0400 Original-Received: by vcbfl17 with SMTP id fl17so9151177vcb.0 for ; Wed, 03 Oct 2012 04:00:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=R7j+xfMXnbNH6M5ha0SllQVIppMIMjADeTiQ5/djdpM=; b=c674HSSODFubUYEkrnuSEBG7RpQhoyiR3H7RY42iZB7FKgDJA1NeZZpYwZccsuRHUb NMAvtnZYrTfhbU5D544SQ893ISKviEGMPPNabBMylHCRm3RuoOdiMoKy2oWP7M3wvCL5 WVhiRD4GREeKPpEQGxGxiJJf+tzkUCmY2PuiHu6WoqU9LW0Djwrd66ZojPfht1CkBy9q 71kcCDo7ZEccUgHQALLujyhhtsVkLnZ9bDzld9VhwNvdN7J3HkkvjYC9za2Yha1C5S8s ugYmlcxBg5hT2jFPsT0uX7hvBeFzqiMF+VtTeJ5gqF7b02r82oHLRkF3mPNUm6Z/4tH3 YtUQ== Original-Received: by 10.220.157.65 with SMTP id a1mr891358vcx.39.1349262040085; Wed, 03 Oct 2012 04:00:40 -0700 (PDT) Original-Received: by 10.220.235.132 with HTTP; Wed, 3 Oct 2012 03:59:58 -0700 (PDT) In-Reply-To: X-Gm-Message-State: ALoCoQnLqWIaVdzL697pPuRg3kbyAqW2sb4tHuqTnpRyuO/40+WUebtiB8Sc3T75VHfKOW6ZKn83 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.220.169 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:153997 Archived-At: Hi Stefan, I think we are mostly on the same page now. When I say that "I don't want to treat process callbacks specially" and "do we need a different 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'm not necessarily calling for merging implementations, but if we end up having both I think it would be nice to 1) point out the similarity in the documentation and 2) have clear recommendations on which API to use given the circumstances. For instance, would add-hook be (very lightly-)deprecated in favor of add-function, since add-function is more general than hooks? Or do we recommend the use of add-function only when the callbacks take arguments? Or recommend add-function only when we expect callbacks to modify arguments? > How do you expect add-hook to work. E.g. give an example would be an app= ropriate add-hook call to add a function on your process-callback? 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. Assuming for brevity that the argument to a process callback is simply a string representing process-input: (defun my-callback (input) (message "Saw input: %s" input) (hook-set-arg 0 (concat "Seen: " input))) ;; process-callbacks defaults to current buffer's process (add-hook (process-callbacks) 'my-callback) Yes, there seems to be a bit of ugliness in this case with process-callbacks needing to return a symbol. 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. My personal preference would be for hook-set-arg, because we wouldn't have two different APIs for callbacks that take arguments, one being more powerful than the other. I can imagine having different APIs might be a problem: consider the case where a library author doesn't know about add-function so they use the hook API. A user complains that they need the ability to modify the arguments passed to the next hook, and now the library author has to switch APIs (breaks backward compat) or support two different APIs (breaks maintainer's spirit). But you probably know better than I on this one, so use your judgment :) > Note that comint-input-filter-functions is a hook on process-send-string = rather than on the process-filter, whereas comint-preoutput-filter-function= s (which is the hook on the process-filter) does allow modifying the string= passed to the next function on the hook. Argh, I was thinking of comint-preoutput-filter-functions in my head. Sorry for the confusion! 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. On Mon, Oct 1, 2012 at 10:25 PM, Stefan Monnier wrote: >> shell is lucky that comint doesn't use a sentinel, because it >> sometimes steals the process sentinel to save the shell history on >> exit. > > Agreed, which is why I suggest `add/remove-function' so that packages > can share something like process-sentinel without having to fight over > it, or even having to plan ahead. > >> Perhaps that's not such a big deal, because both modes are in the >> Emacs tree, and we can just fix that. > > No, it is important. > >>> - provide a standard way to combine sentinels and filters, which is to >>> run them in sequence (for sentinels, it might be a fine default, but >>> for filters, it might be more useful for each filter to be able to >>> affect the passed to the next filter). >> I'll add that this can be useful for any hook that takes arguments. > > Agreed. > >> I think it is a bad idea to consider process callback functions special. > > I do not want to treat process callback functions specially. > >> If it is useful behavior to modify callback arguments, then let us be >> consistent and give that ability to any type of callback, not just >> processes. > > That's what I want out of add/remove-function. Maybe it can even be > used on (symbol-function f) as a lightweight alternative to defadvice. > >>> I'm not sure the first is useful since in my experience sentinels and >>> filters do different things anyway. >> I personally think it is cleaner to have them together, but if others >> disagree there is probably a reason for it :) This is not an essential >> part of my proposal. > > I'm not dead-set against merging them, but unless it simplifies > implementation, I don't see much benefit, so I'm leaning towards keeping > the separation. > >>> (add-function (process-filter proc) #'toto) >> Why have a different way of doing things? > > Different from what? > >> API. The slogan: "If you want have a callback, use the hook API." > > Oh, so you want to use add-hook instead of a new add-function? > The problem with that is that add-hook is written specifically for > symbols/variables and I don't see how to make it work for > process-callbacks, unless process-callbacks returns a symbol (itself > holding a list of function), which I think is not very elegant. > >> Since there is no way for filters and sentinels to guarantee order >> (just like hooks) I think the best route is to just add the ability >> for a hook to modify the arguments that are passed to the next hook. > > In add/remove/run-hook, this is determined by the kind of hook, i.e. how > the hook is run (run-hooks vs run-hook-with-args vs > run-hook-with-args-until-success with with-wrapper-hook). > > Indeed for a new add-function, the choice would be made in add-function > instead. > >> Although I am not too convinced that this is important, >> comint-input-filter-functions doesn't do this. > > But comint-input-filter-functions is comint's hook for > process-send-string, whereas comint-preoutput-filter-functions (the hook > corresponding to the process-filter) does have the ability to modify the > string passed to the next function. > >>> run-hooks takes symbols as arguments. >> It was just an example, I am a busy person and I think I got the gist >> of what I was saying across. But I'll add (off-topic) that there seems >> to be no reason for run-hooks to take a symbol as an argument. The C >> code just immediately dereferences it. > > It's slightly more complex than that (it dereferences it potentially > twice: once for the buffer-local value and once for the global value), > but the real problem comes in add/remove-hook where receiving a list is > not good enough since that list can be nil in which case there's no > updatable field on which to add/remove the function (hence the need for > an additional indirection, such as making function-callbacks return > a symbol). > > > Stefan