From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 19:53:49 +0300 Message-ID: <83oa4amc4i.fsf@gnu.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> <9ea04944-c4a8-31ff-b717-6f6fb9d4618b@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472576065 31394 195.159.176.226 (30 Aug 2016 16:54:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 16:54:25 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, phillip.lord@russet.org.uk To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 18:54:20 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 1bemIh-0007Zg-Tr for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 18:54:16 +0200 Original-Received: from localhost ([::1]:50224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemIf-0001xy-K0 for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 12:54:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemIW-0001xs-SL for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:54:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bemIR-0001iP-SQ for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:54:03 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemIR-0001hj-PD; Tue, 30 Aug 2016 12:53:59 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1767 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bemIP-0007r7-EH; Tue, 30 Aug 2016 12:53:58 -0400 In-reply-to: <9ea04944-c4a8-31ff-b717-6f6fb9d4618b@dancol.org> (message from Daniel Colascione on Tue, 30 Aug 2016 09:23:51 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:206964 Archived-At: > Cc: acm@muc.de, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > From: Daniel Colascione > Date: Tue, 30 Aug 2016 09:23:51 -0700 > > > You are setting the bar impossibly high by expecting that. > > To be fair, according to Alan, XEmacs meets this impossibly high bar. I disagree with Alan (having looked at XEmacs' sources). > (And its insdel is considerably simpler.) That wasn't my impression. Beyond some stuff that is missing simply because XEmacs doesn't support it, the code is the same, except that they also have a separate "multi-change" hook called around changes that are done piecemeal, in addition to the hooks we have. IOW, it's a different model, and not necessarily a solution that we are looking for. Of course, I didn't read their sources too seriously, so maybe I missed something. > 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? I'm not sure which optimizations are you talking about, so it's hard to answer that question. I can tell that decoding a large file when we visit it takes a significant amount of time, even with today's machines. So at least some optimizations we have, like reading into the gap, are probably still justified. Of course, removing/simplifying optimizations in these internals would also need good test coverage, to make sure we don't introduce bugs while at that ;-)