From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 19e09cf: Ensure redisplay after evaluation Date: Mon, 09 Nov 2015 11:06:47 -0800 Message-ID: References: <20151106192313.30794.29154@vcs.savannah.gnu.org> <83oaf4o4gs.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447096172 3384 80.91.229.3 (9 Nov 2015 19:09:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 19:09:32 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 20:09:26 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 1Zvroh-0006K1-PD for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 20:09:24 +0100 Original-Received: from localhost ([::1]:55084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvroh-0002Nt-6d for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 14:09:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvroO-0002Km-Nj for emacs-devel@gnu.org; Mon, 09 Nov 2015 14:09:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvroN-0005dB-Rv for emacs-devel@gnu.org; Mon, 09 Nov 2015 14:09:04 -0500 Original-Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:36790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvroJ-0005am-5e; Mon, 09 Nov 2015 14:08:59 -0500 Original-Received: by pacdm15 with SMTP id dm15so183423935pac.3; Mon, 09 Nov 2015 11:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=CEyS0kAD7Orq690cPSoatSLbX1FIPoZcupeHnWBQH8Y=; b=Ql+7LZdzXOuTb9q6bydBk99KUwDumA1JuWz7/teR56B89tnGNypxHVo/9A4KEbZIUD qzuSnJcH0tbfavR7BZ3fnYWeI8c8erDu1Q6HEBk984RHiRk69QPDfMs0YN4uiipodrh0 b/xBA/iJRk0YbUC6DEO/W5wgyiSMrEM36vWsGOAjc0aUcsAH3Nba25Z/W8j/Autp15/C YaRIKcKZaKi67nhvhqCQd8WsftBh+x3AbcIMuDW/fi+Md3vIFyE5/+/O5QqQJ8SF6zSZ Hg1Nq051K9GDOwKWWjmR/EvZJAReoHnitmlDcvAhe/TWC3eLNAWXMOyeqjwkRzEoG4RS W5QQ== X-Received: by 10.68.57.171 with SMTP id j11mr43150867pbq.17.1447096138591; Mon, 09 Nov 2015 11:08:58 -0800 (PST) Original-Received: from Vulcan.attlocal.net (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id iv5sm8136637pbb.24.2015.11.09.11.08.57 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 09 Nov 2015 11:08:57 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.attlocal.net (Postfix, from userid 501) id 1337B103C1412; Mon, 9 Nov 2015 11:08:57 -0800 (PST) In-Reply-To: <83oaf4o4gs.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 08 Nov 2015 18:12:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::233 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:193740 Archived-At: I am unaware of the historical context for this argument. To chime in based on what I've read from Eli: Allowing dynamic behavior to trigger on modifying a variable could be very valuable during debugging. GDB allows this in the form of watchpoints. As long as we never allow the use of this facility to creep into Emacs itself, I can see value in giving users another way to debug and/or customize their environment, as long as they are fully informed of the potential costs. John >>>>> Eli Zaretskii writes: > Also, we have this strong objection to the idea from Richard: >> Hooks on setting variables is a fundamentally bad idea >> because it means that Lisp code which appears to just bind variables >> can call functions where you did not expect it. >> [...] >> However, having any variable, the binding of which can run Lisp code, >> is an absolute disaster. If the price we pay for to avoid that disaster >> is that we don't have the feature you would like, so be it. >> >> > Besides that, hooks on setting variables would be useful for debugging. >> >> No matter what they would be useful for, it is not worth the chaos >> they would cause. >> >> Maybe a specialized feature solely for debugging could be made safe. > AFAICT, these objections were never addressed in the discussions. And we > _are_ talking about using such a facility for purposes other than debugging, > albeit internal purposes. Maybe calling a C function for "hooked" symbols > takes care of Richard's objections, but then such a function will probably > have to consult some Lisp data to know what to do with each "hooked" symbol. > Not sure if this is okay or sufficient.