* Any convention for the suffix of hook functions?
@ 2012-09-27 9:14 Bastien
2012-09-27 13:06 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: Bastien @ 2012-09-27 9:14 UTC (permalink / raw)
To: emacs-devel
Hook *variables* are suffixed with "-hook" "-functions" or
"-function".
I don't know if this is a standard, but it looks like the use
of this convention is pretty consistent in Emacs Lisp.
Hook *functions* are sometimes suffixed with "-hook" too.
This sounds pretty natural first: "This function is meant to be
hooked into the corresponding hook variable" ... but I find this
confusing while reading the code. When we say "a hook", for me
this is short for saying "a hook variable", so a hook function
is not a hook in this sense...
(Still with me?)
My question is: is there a naming convention for naming hook
functions?
I'm fine if there is none, but I'm curious about what other
devs do.
--
Bastien
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Any convention for the suffix of hook functions?
2012-09-27 9:14 Any convention for the suffix of hook functions? Bastien
@ 2012-09-27 13:06 ` Stefan Monnier
2012-09-27 23:00 ` Bastien
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2012-09-27 13:06 UTC (permalink / raw)
To: Bastien; +Cc: emacs-devel
> I don't know if this is a standard, but it looks like the use
> of this convention is pretty consistent in Emacs Lisp.
Yes, it's a convention, documented in the Elisp manual ("-hook" is
a normal hook: no args, no return values; "-functions" is a non-normal
hook: can have args, can pay attention to the return values; "-function"
is not manipulated with add/remove-hook but just a place to put a single
function with setq(-local)).
> My question is: is there a naming convention for naming hook
> functions?
Not really, no. It's frequent to see a function for use on FOO-hook to
be named PACKAGE-FOO-hook (which should be read as "PACKAGE's function
for use on FOO-hook") and for FOO-functions the name is often
PACKAGE-FOO-function, but while I don't want to explicitly discourage
such names (I use them myself), they're not very good since they don't
describe what the function does but only who calls them.
Still, it's a "natural" choice when you can't come up with a good way to
describe what the function actually does; and that happens often because
it's in the nature of the functions we add to hooks to be ad-hoc and
strongly depend on who calls them.
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Any convention for the suffix of hook functions?
2012-09-27 13:06 ` Stefan Monnier
@ 2012-09-27 23:00 ` Bastien
0 siblings, 0 replies; 3+ messages in thread
From: Bastien @ 2012-09-27 23:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> but while I don't want to explicitly discourage
> such names (I use them myself), they're not very good since they don't
> describe what the function does but only who calls them.
Okay. I've renamed such functions in Org when it made sense,
I've kept the -hook suffix for others.
> Still, it's a "natural" choice when you can't come up with a good way to
> describe what the function actually does; and that happens often because
> it's in the nature of the functions we add to hooks to be ad-hoc and
> strongly depend on who calls them.
Agreed. Another idea in the same vein is that those functions are
only relevant when run within hooks. Still, it may sometimes just be
laziness so I tried to give some Org functions explicit names.
Thanks for the explanations,
--
Bastien
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-09-27 23:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-27 9:14 Any convention for the suffix of hook functions? Bastien
2012-09-27 13:06 ` Stefan Monnier
2012-09-27 23:00 ` Bastien
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).