From: Mark Oteiza <mvoteiza@udel.edu>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: John Wiegley <jwiegley@gmail.com>, emacs-devel@gnu.org
Subject: Re: [PATCH v3] RFC: eldoc-documentation-functions hook
Date: Tue, 19 Jul 2016 19:20:17 -0400 [thread overview]
Message-ID: <20160719232017.GA16820@holos.localdomain> (raw)
In-Reply-To: <jwv7fci5pu2.fsf-monnier+emacs@gnu.org>
On 18/07/16 at 10:47pm, Stefan Monnier wrote:
> >>>>> Applied with some wording changes as 5811404
> >>>> I don't think we have reached any consensus.
> >>> The problem is not just that it introduces a gratuitous incompatiblity,
> >>> but that it's a regression since you can't use things like :around nor
> >>> choose precedence (as in add-function's `depth') with add-hook.
> > There was never a need.
>
> But your change removes the possibility. Just because it hasn't been
> needed yet doesn't mean it won't be needed in the future. After all,
> eldoc has not seen much use so far.
The possibility is still there, just different in that one would advise
a function instead of the single-function hook. I still can't think of
a practical use for the different WHEREs, but until such a need arises
I suppose it's of no importance anyways.
> > Usually foo-function holds a function symbol. If one had a desire to
> > add-hook on foo-function whose value is #'bar, then perhaps bar should
> > run a hook; but then perhaps foo-function is just a layer of indirection
> > and you really should just have a hook.
>
> foo-function *is* a hook.
Oh, meant to distinguish single function hooks from the rest
(which I just called hooks).
> >> - C-h v foo-function RET gives a value that's unreadable. That is true
> >> and we should improve it. I don't think there's anything really hard
> >> about doing so, so it's a transient motivation and it'd be better to
> >> fix `C-h v' than to circumvent the problem by using foo-functions.
> > Yes, we should not have to read bytecode or (at best) RTFS to decipher
> > what foo-function is doing.
>
> 100% Agreement.
>
> > Which is great if that flexibility is even necessary.
>
> The great thing about foo-function (along with add-function) is that you
> don't need to guess beforehand if it's going to be necessary.
>
> > The verbosity of writing advice isn't so bad; using advice even when the
> > circumstance doesn't call for it is. To cite an example, is the
> > following somehow different from just using setq-local?
> > http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/textmodes/tex-mode.el#n1262
>
> Yes, the use of add-function here is overkill. But this exact same
> setting would be just right for a minor mode (where using setq-local
> and kill-local-variable is painful and brittle).
>
> > PS: I'd have suggested a more graceful change like that of
> > pre-redisplay-function(s)
> > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=84e0b7d
>
> As you can see, I'm not completely dogmatic about forcing the use
> of foo-function in place of foo-functions everywhere. In the case of
> pre-redisplay-function, the function does not return any value, so
> there's not much point in using things like :around, or :before-until.
Ok, then perhaps something to the effect of
(defun run-single-function-hook (hook)
(let ((global-hook (default-value hook))
(local-hook (when (local-variable-p hook) (symbol-value hook))))
(or (and (functionp local-hook) (funcall local-hook))
(and (functionp global-hook) (funcall global-hook)))))
can instead be used. Haven't bothered looking to see if this is useful
outside of eldoc…
next prev parent reply other threads:[~2016-07-19 23:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-12 6:12 [PATCH] RFC: eldoc-documentation-functions hook Mark Oteiza
2016-06-12 7:09 ` Eli Zaretskii
2016-06-12 7:46 ` Leo Liu
2016-06-12 8:33 ` Eli Zaretskii
2016-06-12 18:24 ` Mark Oteiza
2016-06-13 21:17 ` Mark Oteiza
2016-06-17 21:08 ` [PATCH v3] " Mark Oteiza
2016-07-07 3:30 ` Mark Oteiza
2016-07-07 4:12 ` Leo Liu
2016-07-07 10:02 ` Kaushal Modi
2016-07-17 15:17 ` Noam Postavsky
2016-07-17 17:48 ` Mark Oteiza
2016-07-17 23:47 ` Dmitry Gutov
2016-07-18 0:09 ` Leo Liu
2016-07-17 18:28 ` Stefan Monnier
2016-07-17 18:52 ` Stefan Monnier
2016-07-18 21:27 ` Mark Oteiza
2016-07-19 2:47 ` Stefan Monnier
2016-07-19 23:20 ` Mark Oteiza [this message]
2016-07-20 1:50 ` Clément Pit--Claudel
2016-07-20 4:50 ` John Wiegley
2016-07-20 23:03 ` Mark Oteiza
2016-07-07 14:55 ` Clément Pit--Claudel
2016-06-12 13:23 ` [PATCH] " Noam Postavsky
2016-06-12 18:52 ` Mark Oteiza
2016-06-12 18:57 ` Dmitry Gutov
2016-06-12 19:44 ` Mark Oteiza
2016-06-12 19:50 ` Dmitry Gutov
2016-06-13 20:36 ` Richard Stallman
2016-06-19 2:45 ` Dmitry Gutov
2016-06-20 23:00 ` Richard Stallman
2016-06-13 4:37 ` Leo Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160719232017.GA16820@holos.localdomain \
--to=mvoteiza@udel.edu \
--cc=emacs-devel@gnu.org \
--cc=jwiegley@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.