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: Mon, 18 Jul 2016 17:27:45 -0400 Message-ID: <87oa5u63hq.fsf@udel.edu> References: <20160612061229.GA6463@holos.localdomain> <838tyahoim.fsf@gnu.org> <20160612182453.GA12034@holos.localdomain> <20160613211735.GA5969@holos.localdomain> <20160617210849.GA3775@holos.localdomain> <20160707033019.GA22360@holos.localdomain> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468877456 7942 80.91.229.3 (18 Jul 2016 21:30:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2016 21:30:56 +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 Mon Jul 18 23:30:46 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 1bPG7h-0007Hr-Q0 for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2016 23:30:46 +0200 Original-Received: from localhost ([::1]:50423 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPG7h-0005wf-4X for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2016 17:30:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPG4v-0002Tf-3X for emacs-devel@gnu.org; Mon, 18 Jul 2016 17:27:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPG4q-0007ox-W1 for emacs-devel@gnu.org; Mon, 18 Jul 2016 17:27:53 -0400 Original-Received: from mail-qk0-x241.google.com ([2607:f8b0:400d:c09::241]:33478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPG4q-0007ot-Qg for emacs-devel@gnu.org; Mon, 18 Jul 2016 17:27:48 -0400 Original-Received: by mail-qk0-x241.google.com with SMTP id n202so11202025qke.0 for ; Mon, 18 Jul 2016 14:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version; bh=mT5O3SNLC3bk9XYzQPXCBihaUXiINaiCm0qFo3KA/BA=; b=2R1VQ2Xo0j0ehNnecRPT5iWLtcN/N7fT+8sCqV08XOB+GrK1eABbzioa7jj7YtQgOr lSC1oWEUnUzf5josgpPC44lgL329n6CxSiT6M3y4TJQYSKthvhoTOo1N2UCfEUkMajuQ uZJSmMZU8wY0g6YWu9dTUcijSxi4uUZPNhyuJ1ETVqKTeEBr1XdmEH/rxYhXcF4l0KzL LeEtuZY6/sVSCcoBEaeEtBxSAz6yXFbLcNdGzXQ3x7kM4IShL/CE/0Ji8lhjV184gSek S4g7JYri2qEo7xGsKnV95H48z8vIvZVRiL/9wJ+7giawSiJuBamhxSmOjKk5HXLeqY74 goqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version; bh=mT5O3SNLC3bk9XYzQPXCBihaUXiINaiCm0qFo3KA/BA=; b=Iy7pHOmpQxlT8CxxtIC/Cwob9n5E/kgpOCmmS0WyJY3vA7zArdijVrEFMh1DMYRf58 a1DXTJloM7qTSTsV5kr8sFe7dwGn2vumDGxHRl3NHE8w7x3iaXde4E2HBB4qxqAQYiBb Cw7yINF0dKYTahMKEZEEaEjo3GwAZXw6o/xhn8p7e5zvuWeMVBbsF3idpObhZjWvw8KY C4sQRHGIdO4BUawdAt95XcYsfC7x6v7cg/rAibSbOKTYVAX5MwgF1jLYTjYA7qN9tRgC b9i8WG5e4Jsl8M0+gtKXe/oDgnazctk4W7lqQinsxjTOF5liRgalteHGww2dpGeWYkI4 YnNQ== X-Gm-Message-State: ALyK8tJv9PJbv+MU2BV4kbjiKR9jEypKs8LB3odYOAgmXnZewKCVzJCMvK4b8QU8GaL2aUQI X-Received: by 10.55.124.132 with SMTP id x126mr46904196qkc.113.1468877267636; Mon, 18 Jul 2016 14:27:47 -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 o84sm2545660qke.38.2016.07.18.14.27.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 14:27:46 -0700 (PDT) Original-Received: by holos.localdomain (Postfix, from userid 1000) id DA10D66C35; Mon, 18 Jul 2016 17:27:45 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::241 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:205827 Archived-At: Stefan Monnier 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.