New Package for GNU ELPA

New Package for GNU ELPA

[Ian Dunn]

[-- Attachment #1: Type: text/plain, Size: 174 bytes --]


I'd like to offer my new package, hook-helpers
(https://savannah.nongnu.org/projects/hook-helpers-el/), to GNU ELPA.
I've already filled out copyright paperwork for Emacs.


[-- Attachment #2: Type: text/html, Size: 2066 bytes --]

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
Ian Dunn

Re: New Package for GNU ELPA

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 2177 bytes --]

> ;; Add font lock for both macros.
> (font-lock-add-keywords
>  'emacs-lisp-mode
>  '(("(\\(define-hook-helper\\)\\_>[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?"
>     (1 font-lock-keyword-face)
>     (2 font-lock-constant-face nil t))
>    ("(\\(define-mode-hook-helper\\)\\_>[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?"
>     (1 font-lock-keyword-face)
>     (2 font-lock-constant-face nil t))))

Is there a reason why these two macros aren't highlighted properly by default? I don't think other packages do this.

On 2016-05-22 12:45, Ian Dunn wrote:
> 
> I'd like to offer my new package, hook-helpers
> (https://savannah.nongnu.org/projects/hook-helpers-el/), to GNU ELPA.
> I've already filled out copyright paperwork for Emacs.
> 
> 
> 
> Often times, I see people define a function to be used once in a hook. If they don’t do this, then it will be an anonymous function. If the anonymous function is modified, then the function can’t be removed. With a function outside of the |add-hook| call, it looks messy.
> 
> The |define-hook-helper| macro is a solution to this. Think of it as an anaphoric |add-hook|, but one that can be called many times without risking redundant hook functions. It gives a cleaner look and feel to Emacs configuration files, and could even be used in actual libraries.
> 
> The purpose of this package is to build upon add-hook and remove-hook. When you have something like the following:
> 
> (defun my/after-init-hook ()
>   (set-scroll-bar-mode nil))
> 	    
> 
> You’ve got to remember to actually add this to the after-init-hook variable. Alternatively, you can use a lambda function:
> 
> (add-hook 'after-init-hook (lambda () (set-scroll-bar-mode nil)))
> 	    
> 
> But then if you want to modify the function, it’s permanently stuck on the after-init-hook variable, and you have to deal with it. It’s not a problem for after-init-hook, which is used once, but would be a problem for a mode hook, like text-mode-hook.
> 
> Instead, hook-helpers can do the following:
> 
> (define-hook-helper after-init
>   (set-scroll-bar-mode nil))
> 	    
> 
> Which handles everything for you.
> 
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: New Package for GNU ELPA

[Drew Adams]

> >  '(("(\\(define-hook-helper\\)\\_>[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?"
...
> >    ("(\\(define-mode-hook-helper\\)\\_>[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?"
...
> 
> Is there a reason why these two macros aren't highlighted properly by
> default? I don't think other packages do this.

If this is a package in GNU ELPA, shouldn't its thingies have a
package prefix?

IOW, shouldn't `define(-mode)-hook-helper' be called something like
`hkhlp-define(-mode)-hook-helper'?

I'm not saying it should, as the rules for GNU ELPA packages are not
clear to me.  But if its packages follow the general rule then they
should have a prefix, no?

(And if they did have a pkg prefix then no, these macros would
presumably not be highlighted by default.)

Re: New Package for GNU ELPA

[Ian Dunn]

On 2016-05-22, Cl?ment Pit--Claudel wrote:
> > ;; Add font lock for both macros.
> > (font-lock-add-keywords
> >  'emacs-lisp-mode
> >  '(("(\\(define-hook-helper\\)\\_>[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?"
> >     (1 font-lock-keyword-face)
> >     (2 font-lock-constant-face nil t))
> >    ("(\\(define-mode-hook-helper\\)\\_>[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?"
> >     (1 font-lock-keyword-face)
> >     (2 font-lock-constant-face nil t))))
> 
> Is there a reason why these two macros aren't highlighted properly by default? I don't think other packages do this.
> 

Yes and no.  Yes, as macros, they have their name highlighted, but to emphasise the significance of the second argument, I wanted that be highlighted as well.

I know for a fact that both use-package and hydra do this same thing, as I used the two of them as an example when creating the above code.

Also, please CC me on any replies to this, and not just the mailing list.  I'm sure it was just a mistake.

-- 
Ian Dunn

Re: New Package for GNU ELPA

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 355 bytes --]

On 2016-05-22 13:27, Ian Dunn wrote:
> Also, please CC me on any replies to this, and not just the mailing list.  I'm sure it was just a mistake.

I'm not sure what you mean (I don't understand what mistake you're talking about). Can you clarify?
AFAICT your original message didn't include a Mail-Followup-To header; should I still have cced you?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Package for GNU ELPA

[Ian Dunn]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-05-22 13:27, Ian Dunn wrote:
>> Also, please CC me on any replies to this, and not just the mailing list.  I'm
>> sure it was just a mistake.
>
> I'm not sure what you mean (I don't understand what mistake you're talking
> about). Can you clarify?
> AFAICT your original message didn't include a Mail-Followup-To header; should I
> still have cced you?
>

I wasn't included in your last response.  I see the message headers as only sending to emacs-devel, not my email.

-- 
Ian Dunn

RE: New Package for GNU ELPA

[Ian Dunn]

On 2016-05-22, Drew Adams wrote:

> If this is a package in GNU ELPA, shouldn't its thingies have a
> package prefix?
> 
> IOW, shouldn't `define(-mode)-hook-helper' be called something like
> `hkhlp-define(-mode)-hook-helper'?
> 
> I'm not saying it should, as the rules for GNU ELPA packages are not
> clear to me.  But if its packages follow the general rule then they
> should have a prefix, no?
> 

According to the "Emacs Lisp Coding Conventions" section of the "GNU
Emacs Lisp Reference Manual":

"Constructs that define a function or variable should be macros, not
functions, and their names should start with ‘define-’."

That might make sense for `remove-hook-helper', though.

-- 
Ian Dunn

RE: New Package for GNU ELPA

[Drew Adams]

> > shouldn't `define(-mode)-hook-helper' be called something like
> > `hkhlp-define(-mode)-hook-helper'?
> 
> According to the "Emacs Lisp Coding Conventions" section of the "GNU
> Emacs Lisp Reference Manual":
> 
> "Constructs that define a function or variable should be macros, not
> functions, and their names should start with ‘define-’."

Touche. ;-)

(That exception was not there originally, BTW.  But it's fine by me.)

Re: New Package for GNU ELPA

[Ian Dunn]

    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

Re: New Package for GNU ELPA

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]

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 “linum” mode should 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 <dunni@gnu.org> 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
>
> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3472 bytes --]

Re: New Package for GNU ELPA

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> 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".

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: New Package for GNU ELPA

[Ian Dunn]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Kaushal Modi <kaushal.modi@gmail.com> 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