[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] RFC: eldoc-documentation-functions hook

From: Mark Oteiza
Subject: Re: [PATCH v3] RFC: eldoc-documentation-functions hook
Date: Tue, 19 Jul 2016 19:20:17 -0400
User-agent: Mutt/1.6.2+14 (b2cb7a38c1ed) (2016-07-01)

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…

reply via email to

[Prev in Thread] Current Thread [Next in Thread]