unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Mark Oteiza <mvoteiza@udel.edu>
Cc: John Wiegley <jwiegley@gmail.com>, emacs-devel@gnu.org
Subject: Re: [PATCH v3] RFC: eldoc-documentation-functions hook
Date: Mon, 18 Jul 2016 22:47:17 -0400	[thread overview]
Message-ID: <jwv7fci5pu2.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87oa5u63hq.fsf@udel.edu> (Mark Oteiza's message of "Mon, 18 Jul 2016 17:27:45 -0400")

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

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

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


        Stefan



  reply	other threads:[~2016-07-19  2:47 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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv7fci5pu2.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=jwiegley@gmail.com \
    --cc=mvoteiza@udel.edu \
    /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 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).