From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (Updated) Run hook when variable is set Date: Sun, 22 Feb 2015 16:35:57 -0500 Message-ID: References: <8vwOHsxYdm2iCzTC6gXmdGOk1vzQKZAhsD9XiWx1JDR@local> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424641005 2388 80.91.229.3 (22 Feb 2015 21:36:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Feb 2015 21:36:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kelly Dean Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 22 22:36:39 2015 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 1YPeCc-0005NE-Ma for ged-emacs-devel@m.gmane.org; Sun, 22 Feb 2015 22:36:38 +0100 Original-Received: from localhost ([::1]:41340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPeCc-0001Tg-4e for ged-emacs-devel@m.gmane.org; Sun, 22 Feb 2015 16:36:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPeCY-0001QJ-4r for emacs-devel@gnu.org; Sun, 22 Feb 2015 16:36:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPeCU-0004jQ-Ut for emacs-devel@gnu.org; Sun, 22 Feb 2015 16:36:34 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPeCU-0004jM-Qt for emacs-devel@gnu.org; Sun, 22 Feb 2015 16:36:30 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsTAPOG1lTO+LI//2dsb2JhbABbgwaDX4VTwGUEAgKBDUQBAQEBAQF8hA0BBAFWIwULCzQSFBgNJIg4CM4jAQEBBwEBAQEej3gHhCoFiiefS4FFIoICHIFuIIJzAQEB X-IPAS-Result: ArsTAPOG1lTO+LI//2dsb2JhbABbgwaDX4VTwGUEAgKBDUQBAQEBAQF8hA0BBAFWIwULCzQSFBgNJIg4CM4jAQEBBwEBAQEej3gHhCoFiiefS4FFIoICHIFuIIJzAQEB X-IronPort-AV: E=Sophos;i="5.09,536,1418101200"; d="scan'208";a="111177454" Original-Received: from 206-248-178-63.dsl.teksavvy.com (HELO pastel.home) ([206.248.178.63]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2015 16:36:30 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9DAD51028; Sun, 22 Feb 2015 16:35:57 -0500 (EST) In-Reply-To: <8vwOHsxYdm2iCzTC6gXmdGOk1vzQKZAhsD9XiWx1JDR@local> (Kelly Dean's message of "Sun, 22 Feb 2015 00:32:02 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183400 Archived-At: >> But that's orthogonal to the "variable hook" functionality, right? >> So I think we can keep this for some later changes. > You originally objected to my patch slowing down Emacs. So I looked for > optimization opportunities to ensure that my patch paid for its performance > costs. I was successful, and not only did I offset the costs, I even > produced a net improvement in speed, and provided benchmarks to prove it. I'm sorry, but I consider this a form of lying. It makes it sound like "the new var-hook functionality actually speeds things up", even though it's not this new functionality but some unrelated (tho bundled) change which does it (and which could be applied independently). > If I remove my optimizations, then my patch will slow down Emacs. > And then you can once again object to the performance impact. I'm quite willing to have Emacs be slightly slower for this new functionality. I just want to reduce this speed impact to the minimum. Offsetting this speed impact by adding unrelated optimization just hides the speed impact. > of the patch, so if you're so worried about the patch size, how about we The issue is not patch size per se, but just keeping the patch focused on its core purpose. Those optimizations you found are good changes. I'm just asking you to put them in a separate patch. >>> Because if you could, then as I explained in my previous message, you could >>> convert a setq into a makunbound, >> I don't think that's a serious problem. > The tradeoff is providing a new capability (not previously present in Emacs) > that's completely unnecessary (even for debugging) and pathological, "unnecessary" and "pathological" are judgments which are actually hard to make for such a generic hooking functionality where we don't (want to) know what the applications will be. As a general design principle Emacs doesn't really try to prevent you from shooting yourself in the foot. > Ok, I'll change it back. Thanks, Stefan