From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Lisp primitives and their calling of the change hooks Date: Fri, 05 Jan 2018 17:28:15 -0500 Message-ID: References: <20180103124543.GA5435@ACM> <20180104155111.GB6846@ACM> <20180104211154.GC6846@ACM> <838tdcbxrb.fsf@gnu.org> <83lghc9j62.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1515191236 27616 195.159.176.226 (5 Jan 2018 22:27:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Jan 2018 22:27:16 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 05 23:27:11 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXaS8-0006Sw-He for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 23:27:04 +0100 Original-Received: from localhost ([::1]:33505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXaU7-0005DC-Aj for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 17:29:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXaTQ-0005BW-LR for emacs-devel@gnu.org; Fri, 05 Jan 2018 17:28:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXaTN-00086Q-9K for emacs-devel@gnu.org; Fri, 05 Jan 2018 17:28:24 -0500 Original-Received: from pmta31.teksavvy.com ([76.10.157.38]:61451) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eXaTI-0007yp-3b; Fri, 05 Jan 2018 17:28:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GudgBy+09a/yyKSC1cHgEGDIM+gVqJS?= =?us-ascii?q?YR6jwOCApk/hUUChDFEEwEBAQEBAQEBAQNoKIUlAQQBDlcUBQsLDScSFBgxijo?= =?us-ascii?q?ItBEhAookAQEBBwImhBSCFYZtixoFkiSBFJAkoUgoh1KYTzcigVAyGggwgmiEd?= =?us-ascii?q?COKJAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2GudgBy+09a/yyKSC1cHgEGDIM+gVqJSYR6jwOCApk/hUU?= =?us-ascii?q?ChDFEEwEBAQEBAQEBAQNoKIUlAQQBDlcUBQsLDScSFBgxijoItBEhAookAQEBB?= =?us-ascii?q?wImhBSCFYZtixoFkiSBFJAkoUgoh1KYTzcigVAyGggwgmiEdCOKJAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,320,1511845200"; d="scan'208";a="16877328" Original-Received: from unknown (HELO pastel.home) ([45.72.138.44]) by smtp.teksavvy.com with ESMTP; 05 Jan 2018 17:28:15 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 3B2E4606C5; Fri, 5 Jan 2018 17:28:15 -0500 (EST) In-Reply-To: <83lghc9j62.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Jan 2018 21:53:25 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.38 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:221630 Archived-At: > We don't normally include such "preemptive" explanations in the > manual. If the text doesn't say one should expect balanced calls, the > reader has no reason to expect balanced calls. I think the name of the hooks suggests such a balance, and actual experimentation can very easily lead the user to think that they're balanced. Alan may not be the "average Emacs coder", but I think his experience is not completely unexpected. > The current text even makes a point of saying that explicitly. Indeed, and this discussion wants to replace this with something a bit more specific. > This basically says the calls are mostly balanced, but don't rely on > that, because sometimes they aren't". It says a bit more because it describes the way in which they're not balanced. > The text about after-change-functions being called zero or more times > adds non-trivial information, but what is its practical usefulness? It says that subsequent calls to a-c-f aren't calls with a missing b-c-f but that they "belong" to (I think of it as "they are covered by") the last b-c-f. > Same with the text about BEG and END. Not sure how important it is, but I think it can help the coder have a mental model of the kind of unbalancedness that can occur. > Maybe I don't understand what are we trying to accomplish with these > changes, and that's why I fail to see why the proposed changes are for > the better. The current text basically says "don't rely on them being balanced" but doesn't say what the coder can rely on if he wants to share information between a-c-f and b-c-f. The new text tries to be sufficiently loose that if Emacs doesn't obey it it's actually a bug, yet sufficiently precise that an Elisp coder can make use of it to reliably share information between a-c-f and b-c-f. Stefan