From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 19e09cf: Ensure redisplay after evaluation Date: Sun, 08 Nov 2015 18:12:19 +0200 Message-ID: <83oaf4o4gs.fsf@gnu.org> References: <20151106192313.30794.29154@vcs.savannah.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1446999161 28622 80.91.229.3 (8 Nov 2015 16:12:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 16:12:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 17:12:33 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 1ZvSa0-0002MC-DT for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 17:12:32 +0100 Original-Received: from localhost ([::1]:47873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvSZz-00071J-LQ for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 11:12:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvSZw-00071E-0S for emacs-devel@gnu.org; Sun, 08 Nov 2015 11:12:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvSZs-0004hI-Pl for emacs-devel@gnu.org; Sun, 08 Nov 2015 11:12:27 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:37300) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvSZs-0004h0-D7 for emacs-devel@gnu.org; Sun, 08 Nov 2015 11:12:24 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NXI000007C9DX00@mtaout25.012.net.il> for emacs-devel@gnu.org; Sun, 08 Nov 2015 18:10:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXI00FGK7KQ70A0@mtaout25.012.net.il>; Sun, 08 Nov 2015 18:10:03 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.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:193618 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii > Date: Sat, 07 Nov 2015 18:40:30 -0500 >=20 > The write-barrier discussed in the past moved this check to within = the > SYMBOL_CONSTANT_P test. More specifically, it turned the > SYMBOL_CONSTANT_P boolean into a field with 3 different values, > depending on whether a write can: > - go through at full-speed > - goes through a watcher function (or call it a "barrier") > - is not allowed at all >=20 > This way, assignments to most variables is unaffected. Thanks. AFAIU, the patch posted in that discussion cannot be used du= e to copyright reasons. So Someone=E2=84=A2 will have to reimplement t= he idea =66rom scratch. I cannot do that: I understand the idea, but don't k= now enough about the machinery that's involved in binding symbols to work out the low-level details. Would you like to do that? 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 variable= s > can call functions where you did not expect it. > [...] > However, having any variable, the binding of which can run Lisp cod= e, > is an absolute disaster. If the price we pay for to avoid that dis= aster > is that we don't have the feature you would like, so be it. >=20 > > Besides that, hooks on setting variables would be useful for de= bugging. >=20 > No matter what they would be useful for, it is not worth the chaos > they would cause. >=20 > Maybe a specialized feature solely for debugging could be made safe= . AFAICT, these objections were never addressed in the discussions. An= d 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= .