From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Dunn Newsgroups: gmane.emacs.devel Subject: Re: New Package for GNU ELPA Date: Fri, 27 May 2016 21:16:53 -0400 Message-ID: <87lh2v0ynu.fsf@gnu.org> References: <8760u045uv.fsf@gnu.org> Reply-To: Ian Dunn NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1464398255 5422 80.91.229.3 (28 May 2016 01:17:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 May 2016 01:17:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kaushal Modi , John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 28 03:17:35 2016 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 1b6Ssg-0005VG-M0 for ged-emacs-devel@m.gmane.org; Sat, 28 May 2016 03:17:34 +0200 Original-Received: from localhost ([::1]:49912 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6Ssf-0006Jy-LB for ged-emacs-devel@m.gmane.org; Fri, 27 May 2016 21:17:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6Ss7-0006Jq-CU for emacs-devel@gnu.org; Fri, 27 May 2016 21:17:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6Ss5-0000qm-9K for emacs-devel@gnu.org; Fri, 27 May 2016 21:16:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6Ss5-0000qg-68; Fri, 27 May 2016 21:16:57 -0400 Original-Received: from [2604:6000:1010:176:d06f:8928:a420:e516] (port=39432 helo=escafil) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1b6Ss3-0005d3-IJ; Fri, 27 May 2016 21:16:55 -0400 In-Reply-To: (John Wiegley's message of "Fri, 27 May 2016 10:19:09 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:204096 Archived-At: John Wiegley writes: >>>>>> Kaushal Modi writes: > >> IMO the standard add-hook and remove-hook don't seem to need syntactic >> sugar. The macros in the package lack many things that the default >> add-hook/remove-hook do and also it is more verbose. > >> It's not too difficult to define a foo function and add that to a hook using >> the standard way. And ALWAYS explicitly defining a function first is a good >> rule of thumb. It applies to hooks and advices both. > > I like this package. First, it's not being suggested for core, or as an > alternative to standard methods. Second, just because you *can* do something > in a manual way, is no reason to argue against convenience. I would both > welcome this addition, and start using it. > > As a bonus, it could be implemented as a macro that does actually generates a > new function and adds that function symbol to the hook, in such a way that if > you change the body and re-evaluate with C-M-x, it removes the old function, > and adds the changed one. Then it would be identical to what "best practices" > say one should do when adding a hook, but with a clearer declaration of > intent: "I want the following FORMS to happen when the hook is run". I appreciate the feedback from both of you. John, you've succinctly stated my goal with this package, and I appreciate your support. It's not a replacement for add-hook/remove-hook, because Kaushal, as you put it, you can't beat the simplicity and brevity of the two. My intention was something similar to `define-advice', except for hooks. I wanted something that would clean up functions that were only ever added to a hook, wrapping them inside a nice macro and tucking them away where we don't have to see them. > PS: "define-mode-hook-helper text" and "define-hook-helper text-mode" seem to do > the exact same thing. The macro user is not saving any time by using > define-mode-hook-helper; they still need to type "-mode" but at a different > place. I don't understand the point of that. I'm not sure why that's never occurred to me. Thanks for pointing that out. One of the glaring flaws that almost everyone has pointed out is that there is no way to add the new function to multiple hooks. With my most recent push, I added `define-hook-function', which is mostly just `defun', but with the "hooks" keyword that allows a user to specify one or more hook to which the function will be added. It doesn't address every concern, as people are different and have different ways of doing things, but this does give people the ability to define a function, find it with `C-h f', and specify as many hooks as they want. -- Ian Dunn