all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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…



  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.