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: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Wed, 10 Aug 2016 11:44:26 -0400 Message-ID: References: <20160808184223.GC7208@acm.fritz.box> <838tw7hyk2.fsf@gnu.org> <20160808195459.GD7208@acm.fritz.box> <83tweugeu9.fsf@gnu.org> <20160809163814.GD4893@acm.fritz.box> <83inv9hkjd.fsf@gnu.org> <83h9ashfgx.fsf@gnu.org> <20160810151622.GA3413@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1470859688 2337 195.159.176.226 (10 Aug 2016 20:08:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2016 20:08:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 10 22:08:05 2016 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 1bXZnI-0000Rb-PF for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2016 22:08:04 +0200 Original-Received: from localhost ([::1]:43694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXZnF-0000PY-Nh for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2016 16:08:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXZkp-0007Q4-4t for emacs-devel@gnu.org; Wed, 10 Aug 2016 16:05:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXZkn-0001hJ-5s for emacs-devel@gnu.org; Wed, 10 Aug 2016 16:05:30 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:42516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXZki-0001fR-8X; Wed, 10 Aug 2016 16:05:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CkFACJI6tX/2aIs2tdHAEBIoMFhEuFULBdgX2GFwQCAoFdOhMBAQEBAQEBXSeEXwEBAwFWIxALDiYSFBgNJIg8CMFcAQEIAiWKd4l+HQEEmTyYWYV8kCwfATSEFiCHXgEBAQ X-IPAS-Result: A0CkFACJI6tX/2aIs2tdHAEBIoMFhEuFULBdgX2GFwQCAoFdOhMBAQEBAQEBXSeEXwEBAwFWIxALDiYSFBgNJIg8CMFcAQEIAiWKd4l+HQEEmTyYWYV8kCwfATSEFiCHXgEBAQ X-IronPort-AV: E=Sophos;i="5.28,500,1464667200"; d="scan'208";a="251012877" Original-Received: from 107-179-136-102.cpe.teksavvy.com (HELO pastel.home) ([107.179.136.102]) by smtp.teksavvy.com with ESMTP; 10 Aug 2016 16:05:20 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id DF05964E0F; Wed, 10 Aug 2016 11:44:26 -0400 (EDT) In-Reply-To: <20160810151622.GA3413@acm.fritz.box> (Alan Mackenzie's message of "Wed, 10 Aug 2016 15:16:22 +0000") 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.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:206555 Archived-At: >> In any case, my point is that the doc should still say "before any >> modification" because that's really what the code *should* do. We could >> add a blurb in the doc saying that the before and after hooks may not be >> properly paired (neither in number of calls nor in the specific value of >> BEG/END), > You mean we should add commentary saying that BEG and END _usually_ > bound the region about to be deleted, but sometimes they don't. No. They should always bound the region. But sometimes the before and after bounds are different (typically, they're tighter in a-c-f because when the b-c-f is run we don't know yet exactly which parts will be modified, so we give pessimistic bounds). E.g. I think it would be perfectly acceptable to have a revert-buffer with b-c-f called once on point-min/point-max and then a-c-f called a bunch of times on those few places where the buffer actually needed to be modified. >> but we should still claim that they're both called for any and >> all modifications (modulo inhibit-modification-hooks, obviously). > Given that the situation has been in place for several decades, I don't > see any urgency to fix it in 25.1. Agreed. But the doc should still say what the "spec" should be, so it's clear what is a bug. Stefan