[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: Mon, 18 Jul 2016 17:27:45 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>>> 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.  The state of eldoc shows this, as it is exactly
an emulation of what run-hook-with-args-until-success does.  Alas, I'm
repeating myself.

> I know of 3 motivations to replace foo-function with foo-functions:
> - habit and consistency: Emacs has used add-hook for many many years, so
>   having to start using add-function is inconvenient.  That is true and
>   I don't have a good argument against this, except that foo-function
>   also have existed for many years so the fact that you can't use
>   add-hook on them is not really new.  What is new is that you can use
>   add-function on them.

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.

> - 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.

> - (add-function :before (local 'foo-function) #'toto) is more verbose
>   than (add-hook 'foo-functions #'toto nil t).  That's true.  But the
>   difference is not very large.  We could try and reduce it, but I'm not
>   sure it's worth the trouble, especially since the fact that you can
>   choose between (say) :before and :around is one of the main benefits of
>   foo-function over foo-functions.

Which is great if that flexibility is even necessary.  Advice is useful,
no doubt; however, IME the only place I thought advice was the best
solution was tacking onto a process filter.  As I recall, there was an
interesting discussion on process API, but I can't find it now.

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?

PS: I'd have suggested a more graceful change like that of
But even then you end up with two (somewhat) disjoint APIs; for
instance, no degree of precedence will put your advice between function
symbols in the hook.

reply via email to

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