From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 15:07:27 +0100 Message-ID: <8760qie4f4.fsf@russet.org.uk> References: <83h9ashfgx.fsf@gnu.org> <831t1wharr.fsf@gnu.org> <20160810161821.GB3413@acm.fritz.box> <83wpjofttf.fsf@gnu.org> <20160810185735.GD3413@acm.fritz.box> <20160811112951.GA2154@acm.fritz.box> <7e1478b6-cf00-fcbf-8c24-43bdaa57e2b6@dancol.org> <415d1cca-f32c-624e-a4be-9aadcf8a0f17@dancol.org> <8cea494d-33e0-0a7d-2bd0-c8bfb9f597aa@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472566084 17794 195.159.176.226 (30 Aug 2016 14:08:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 14:08:04 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: Daniel Colascione , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 16:07:55 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 1bejhi-0003xL-Jj for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 16:07:54 +0200 Original-Received: from localhost ([::1]:49352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bejhg-00046x-2c for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 10:07:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bejhS-00041G-DF for emacs-devel@gnu.org; Tue, 30 Aug 2016 10:07:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bejhL-0006ld-A2 for emacs-devel@gnu.org; Tue, 30 Aug 2016 10:07:37 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:44562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bejhK-0006lE-W5 for emacs-devel@gnu.org; Tue, 30 Aug 2016 10:07:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=mU3q99tjum1LWFyKsVgA/SIt+jNjAQOpz7WSwtNW608=; b=obasqtFMYUe+hQwsjYhnp3u57w oHyIVS81YAznu2Go1c8KDSmIjS1MRgT440SQPjX3J+84lxCNGqpG3UlFRJWHD0ImjlXWEMq9zHzR7 +6Mm5Dc/VWLNIAqyN4P6w7lWNx5A2Q4aXrjAHmIq1h3aNlswVWWueDzem2al984VZ2Y34238yjYsG O5PASrvYchEW4MUIH7Gd23i4BlZLsgfNRwOr3UlTUXy7KITXOaC84asmV9dm0ziSOqo6TbQO44VBI EutHv2h+fbtT8wX7cms1NB5YAbRlxaojl9bwoD0U7DLZFQUTVtODHuCIZYb/fBzRScA4jA+LWVm9p e9fSnrTA==; Original-Received: from janus-nat-128-240-225-60.ncl.ac.uk ([128.240.225.60]:48019 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bejhI-001dO3-OD; Tue, 30 Aug 2016 15:07:29 +0100 In-Reply-To: (Stefan Monnier's message of "Mon, 29 Aug 2016 11:44:00 -0400") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 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:206932 Archived-At: Stefan Monnier writes: >>> I guess a way to "fix" it would be to add a random fudge factor to the >>> b-c-f calls, plus add random dummy calls to b-c-f, and sprinkle the >>> lisp/*.el code with combine-after-change-calls. This way, the "properly >>> paired up" case will be much more exceptional. >> You can't be serious. > > If it can finally get us rid of people who insist they want exactly > paired/matched/symmetric b/a-c-f, then I'd willing to do that, yes. > > AFAICT the result would be simpler, cleaner, and more robust code, since > instead of trying to think of the various different ways a buffer can > change here or there, the coder would be forced to step back and think > how to handle the general case. I use these functions for my package lentic, and I do handle the general case. In fact, I started off by handling the general case -- this involves using a-c-f only and just ignoring the parameters. It works, of course, but it is inefficient enough that it limits the usability to small buffers. So, I made use of the information on a-c-f and b-c-f. This increases the code complexity significantly, but it reduces the load massively. That b-c-f and a-c-f are not always balanced or consistent, unfortunately, works directly against this aim. So having them balanced and consistent would be nice. I agree that in fixing this, bad things might happens. But surely that is a risk of fiddling with any core part of Emacs. One response would be to not to it. Another response would be to incrementally increase the number of test cases Emacs has to enable this (and other) changes in the core to be made with more confidence. Phil