From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 09:23:51 -0700 Message-ID: <9ea04944-c4a8-31ff-b717-6f6fb9d4618b@dancol.org> References: <83inv9hkjd.fsf@gnu.org> <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> <87a8fue656.fsf@russet.org.uk> <834m62ntqs.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1472574255 12558 195.159.176.226 (30 Aug 2016 16:24:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 16:24:15 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Cc: acm@muc.de, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii , Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 18:24:11 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 1belpa-0002ll-GN for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 18:24:10 +0200 Original-Received: from localhost ([::1]:50103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belpY-0005qv-4a for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 12:24:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belpR-0005qo-Lx for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:24:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1belpN-0002y6-Dt for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:24:00 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:53118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belpN-0002xw-4b; Tue, 30 Aug 2016 12:23:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=d2N0HfH9RhJpJivelIdFTPVlwwWK3hZswQd/8vbAUHE=; b=OWLUOW16mDH4+ikhsXDWNpxvrywRUer7s3x1/hXVQxB8nVeX5nGqQ9N7kLKQnaIhKc9Qm9YE7ki+4LtAfe5wLJWItBOt9EWnrwmExvUrNlu/H5UJkoL6ACadH7m6KZpGs+f624Gkr1le8b67rWoUwxBw/YxsuIFSaBDUKwN/ohXAzsjyHFMo2BFO/kdDrGUmnanVc2mvb2Nd2b8sXnAUahH/jvKAGdPx5B2XkbsT5tDR7cVseqYQWYdWMYbViz941ELCr7IV/rZknUU86P/4jqt+ELweKZo2a04aOlewT8damPTJpfS9SUntiScwdU8JxyoNn8Cr9Ngi6SdCF6fm/A==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1belpK-0006jZ-IX; Tue, 30 Aug 2016 09:23:54 -0700 In-Reply-To: <834m62ntqs.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:206959 Archived-At: On 08/30/2016 08:47 AM, Eli Zaretskii wrote: >> From: phillip.lord@russet.org.uk (Phillip Lord) >> Date: Tue, 30 Aug 2016 14:30:13 +0100 >> Cc: Alan Mackenzie , Stefan Monnier , >> emacs-devel@gnu.org >> >> I think to really avoid the complexity for mode authors, b-c-f and a-c-f >> need to not only balance, but also to be consistent. At the moment, they >> are not that either -- they can signal different locations for a given >> change. > > You are setting the bar impossibly high by expecting that. To be fair, according to Alan, XEmacs meets this impossibly high bar. (And its insdel is considerably simpler.) In today's world, do we really *need* the optimizations that complicate change region tracking? Might these things just be just as unnecessary as the old code that used to special-case self-insert-command in the event loop?