From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Oteiza Newsgroups: gmane.emacs.devel Subject: Re: [PATCH v3] RFC: eldoc-documentation-functions hook Date: Tue, 19 Jul 2016 19:20:17 -0400 Message-ID: <20160719232017.GA16820@holos.localdomain> References: <838tyahoim.fsf@gnu.org> <20160612182453.GA12034@holos.localdomain> <20160613211735.GA5969@holos.localdomain> <20160617210849.GA3775@holos.localdomain> <20160707033019.GA22360@holos.localdomain> <87oa5u63hq.fsf@udel.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1468970438 23094 80.91.229.3 (19 Jul 2016 23:20:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jul 2016 23:20:38 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 20 01:20:33 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bPeJS-0005tn-W8 for ged-emacs-devel@m.gmane.org; Wed, 20 Jul 2016 01:20:31 +0200 Original-Received: from localhost ([::1]:59511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPeJS-0007yK-3p for ged-emacs-devel@m.gmane.org; Tue, 19 Jul 2016 19:20:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPeJL-0007y1-NR for emacs-devel@gnu.org; Tue, 19 Jul 2016 19:20:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPeJI-0006c8-El for emacs-devel@gnu.org; Tue, 19 Jul 2016 19:20:23 -0400 Original-Received: from mail-qt0-x243.google.com ([2607:f8b0:400d:c0d::243]:32975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPeJI-0006c3-8J for emacs-devel@gnu.org; Tue, 19 Jul 2016 19:20:20 -0400 Original-Received: by mail-qt0-x243.google.com with SMTP id j37so1507451qta.0 for ; Tue, 19 Jul 2016 16:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=KyCDa6aO26W8hLGsU/aMc6JohqeGE/KMOJB7OWavp98=; b=C+VKctcuAMv0Nop8Oj2ZzXraxpH7vQqEPpFYk6Qwo6kB2+g82mamncT9DWkCRZIhQ8 LVsjlPtOwvf6mHdrjXPidq6YCiftJj/KyK5We/kKVFgBw/pNH78n77ZeTKP2rFyaI3xk lWNFKWDhIZlHksUskdLXv4ViF85OW/ePrgMtAuOKVRdso6nqhE/W1kaVbn+V8a0BJpDX hMDoTXDVRGwgzF6c5d55qI/JCp4vSkJEcbcMARMlbj6XZfNaUU4/U+sxMoHBphapaXH9 5fbR8KQLqe+uZZBFw65xBZV6CQ10+rF8RnF7SjDbxjjorNPNOI8u2y0BM1q/AQjrIOg5 05HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=KyCDa6aO26W8hLGsU/aMc6JohqeGE/KMOJB7OWavp98=; b=Dvh/A8jYwGkGg2YhjPmq1+JvZWEmHFPXAOIypxp92xPg6tLmLYYxWELwXrRfUZvDTy p7Vx5n+tj+ExCXYkCWp3edwOqh8qvHpCUDip/xjK4gYk/wCTLott4pTZhNaPc7vKn3V1 XECKHZo4pbzMsT9jP0mhq4PyCv8b01D2clunYlFqUUjPxOWzycY+2T6xQDCdVyXX7cqC ktRAFUyTVYxz1rFm1V9Uels5TbGE9pp1+HaHcXOGarTZB1nn53yTnJ2oCCTkHT2aChrv /TPwx1CC9n3T3DhcTC0aTQwX9D2BAgNCwhpDUhPjsikwPfX8uNx0o+zMkqXSt2bcwXoX EpDg== X-Gm-Message-State: ALyK8tKlm6aMMkqXZNTi3NDBtN0xsZcEzLrTQ8jeLfFICS10rK/F4VK1Qqh6v/Simoz6d4c6 X-Received: by 10.237.53.125 with SMTP id b58mr62943138qte.104.1468970419432; Tue, 19 Jul 2016 16:20:19 -0700 (PDT) Original-Received: from holos.localdomain (ip68-100-200-121.dc.dc.cox.net. [68.100.200.121]) by smtp.gmail.com with ESMTPSA id 62sm2373669qtg.14.2016.07.19.16.20.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 16:20:18 -0700 (PDT) Original-Received: by holos.localdomain (Postfix, from userid 1000) id 76B9E66C35; Tue, 19 Jul 2016 19:20:17 -0400 (EDT) Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2+14 (b2cb7a38c1ed) (2016-07-01) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c0d::243 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205848 Archived-At: 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…