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: Mon, 18 Jul 2016 17:27:45 -0400 [thread overview]
Message-ID: <87oa5u63hq.fsf@udel.edu> (raw)
In-Reply-To: jwvoa5whzpt.fsf-monnier+gmane.emacs.devel@gnu.org
Stefan Monnier <monnier@iro.umontreal.ca> 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?
http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/textmodes/tex-mode.el#n1262
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
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.
next prev parent reply other threads:[~2016-07-18 21:27 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 [this message]
2016-07-19 2:47 ` Stefan Monnier
2016-07-19 23:20 ` Mark Oteiza
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=87oa5u63hq.fsf@udel.edu \
--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.