From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: New Package for GNU ELPA Date: Fri, 27 May 2016 10:26:14 +0000 Message-ID: References: <8760u045uv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0441f4bed8380533d056c2 X-Trace: ger.gmane.org 1464345967 6488 80.91.229.3 (27 May 2016 10:46:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 May 2016 10:46:07 +0000 (UTC) To: Ian Dunn , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 27 12:46:06 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 1b6FHG-0002N4-N0 for ged-emacs-devel@m.gmane.org; Fri, 27 May 2016 12:46:02 +0200 Original-Received: from localhost ([::1]:45159 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6FHF-000679-RY for ged-emacs-devel@m.gmane.org; Fri, 27 May 2016 06:46:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6EyO-0005BY-FO for emacs-devel@gnu.org; Fri, 27 May 2016 06:26:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6EyM-0003eb-Rt for emacs-devel@gnu.org; Fri, 27 May 2016 06:26:32 -0400 Original-Received: from mail-oi0-x22f.google.com ([2607:f8b0:4003:c06::22f]:33350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6EyJ-0003dj-9f; Fri, 27 May 2016 06:26:27 -0400 Original-Received: by mail-oi0-x22f.google.com with SMTP id k23so167217241oih.0; Fri, 27 May 2016 03:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7H868aI8mmxQEd1XtmjYxWM7ZrmeGKKp+A0JRzxSbWo=; b=Kv2lOMA2YM3dmQVIqhPh1QGtnkYM5WY1xC0CAAD1wtjYNCP1OpAnfX25JiYZY3WKa+ CD+lQL3Uin37AwUq13wG7d0YHWXJiSWxwt7WnzvOmVdmX0IgffZrv+uDgjcZCK6ZMbSi VyeHRxgV4PjcXdhSjkEcb5kdRPQ2rQ/fBnY0+HFssZ5uU8t9MRk6aycCq2Bi38JWsL5g upJ1MGYIXnpA670A90GjYOVWVMSjfySTuUlFyCbIilAzvQ1vQBDg7+UebxRtN2VKrMuN gKObQFrFjj7MdcVYN4nb0BzeS+UV2IOPL9sf68zjqjp22Xsm4wgZ8Ce/dduT0CkT0Ulq WHcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7H868aI8mmxQEd1XtmjYxWM7ZrmeGKKp+A0JRzxSbWo=; b=UbCWQRKNpiJ61oAEkasfL0uXU2OXaY8l9/mmx8jrmtubpviwRm01EBACmc9E7pJeOW rpLa4yMclUcvVQUmn8uNLFTxoMXyxDpgaXzaB901ahh0aoPSLb9DxzUvIN6vhIy/GYK8 rgN82815y3UHAE4j7ypKV0PS3Y+8hj4zF21Sw303bHu1ErNh6FgKspvQvJgh/WoUWMSY VO1hdaJEmYVNjLZvQffZeTv+ABSG0NH6IpPJ0O7C9ytns4iClMYIi0K32ERi7/jJwmzs lhMOR52uxqNC/QYqk/B89qL/QwwSTrmWbZJdpW/CmCmHvbV6vIls9kMg9c7eskDBiQyl lcYg== X-Gm-Message-State: ALyK8tLnFuJnRDDZmd7UQEqsl0KssAxPdHkc2Hbx/UD3PPryUNRdbQ7nibgHse4BRVXMtszP73I0LgaFjRVPcQ== X-Received: by 10.157.0.68 with SMTP id 62mr9673646ota.189.1464344785113; Fri, 27 May 2016 03:26:25 -0700 (PDT) In-Reply-To: <8760u045uv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c06::22f 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:204068 Archived-At: --94eb2c0441f4bed8380533d056c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. Here's what I believe the users will miss out if they use the hook helper macros: 1. Applying function to a local hook. 2. Edebugging a function applied to a hook. I believe that if the macro is crating a function, you would need to macroexpand the macro first and then edebug the function definition shown in the temp buffer, right? 3. Adding the same function to multiple hooks. 4. Brevity of add-hook and remove-hook. 5. Many times you just happen to have a function already defined and you just need to add that to the hook in a concise manner like the below example. 6. Quickly look up the value of a hook with point on the hook name and doing C-h v. Now as the macro uses the hook name without the "-hook" suffix, C-h v will not work that fast. Also user needs to then add ":suffix" when using these macros for non-standard hooks that end in "-functions". (defconst my/linum-mode-hooks '(verilog-mode-hook emacs-lisp-mode-hook cperl-mode-hook c-mode-hook python-mode-hook) "List of hooks of major modes in which a =E2=80=9Clinum=E2=80=9D mode sho= uld be enabled.") (dolist (hook my/linum-mode-hooks) (add-hook hook #'linum-mode)) In summary, at least for me, I do not seem to gain more by using these set of macros; it's more verbose and doesn't entirely cover the original add-hook and remove-hook feature set. I would rather educate people to always have defuns and almost never use bare lambda forms in hooks and advices. 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. And then you have just one remove-hook-helper. That looks inconsistent. On Thu, May 26, 2016, 10:01 PM Ian Dunn wrote: > > If no one else sees any issue with this, would someone with commit > access to ELPA mind adding hook helpers? If it helps, the git repo is > here: > > git://git.savannah.nongnu.org/hook-helpers-el.git > > -- > Ian Dunn > > -- --=20 Kaushal Modi --94eb2c0441f4bed8380533d056c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 d= efault 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 fun= ction first is a good rule of thumb. It applies to hooks and advices both. =

Here's what I believe the users will miss out if they us= e the hook helper macros:

1. Applying function to a local hook.
2. Edebugging a function applied to a hook. I believe that if the macro is = crating a function, you would need to macroexpand the macro first and then = edebug the function definition shown in the temp buffer, right?
3. Adding the same function to multiple hooks.
4. Brevity of add-hook and remove-hook.
5. Many times you just happen to have a function already defined and you ju= st need to add that to the hook in a concise manner like the below example.=
6. Quickly look up the value of a hook with point on the hook name and doin= g C-h v. Now as the macro uses the hook name without the "-hook" = suffix, C-h v will not work that fast. Also user needs to then add ":s= uffix" when using these macros for non-standard hooks that end in &quo= t;-functions".=C2=A0

(defconst my/linum-mode-hooks '(verilog-mode-hook
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 emacs-lisp-mode-hook
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cperl-mode-hook
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c-mode-hook
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 python-mode-hook)
=C2=A0 "List of hooks of major modes in which a =E2=80=9Clinum=E2=80= =9D mode should be enabled.")

(dolist (hook my/linum-mode-hooks)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (add-hoo= k hook #'linum-mode))

In summary, at least for me, I do not seem to gain more by u= sing these set of macros; it's more verbose and doesn't entirely co= ver the original add-hook and remove-hook feature set. I would rather educa= te people to always have defuns and almost never use bare lambda forms in h= ooks and advices.

PS: "define-mode-hook-helper text" and "defin= e-hook-helper text-mode" seem to do the exact same thing.=C2=A0 The ma= cro user is not saving any time by using define-mode-hook-helper; they stil= l need to type "-mode" but at a different place. I don't unde= rstand the point of that. And then you have just one remove-hook-helper. Th= at looks inconsistent.


On Thu, May 26, 2016, 10:01= PM Ian Dunn <dunni@gnu.org> wro= te:

=C2=A0 =C2=A0 If no one else sees any issue with this, would someone with c= ommit
access to ELPA mind adding hook helpers?=C2=A0 If it helps, the git repo is= here:

git://git.savannah.nongnu.org/hook-helpers-el.git<= /a>

--
Ian Dunn

--
Kaushal Modi

--94eb2c0441f4bed8380533d056c2--