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: Mon, 29 Aug 2016 21:04:42 +0300 Message-ID: <831t17bged.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> <7e1478b6-cf00-fcbf-8c24-43bdaa57e2b6@dancol.org> <415d1cca-f32c-624e-a4be-9aadcf8a0f17@dancol.org> <83inujbpek.fsf@gnu.org> <83eg57bl8f.fsf@gnu.org> <5ee6ff4a-2d58-82f1-8e83-479c62f0b729@dancol.org> <837fazbjb4.fsf@gnu.org> <75100b15-d49f-5a1a-d73b-24db77c891bf@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472493953 31676 195.159.176.226 (29 Aug 2016 18:05:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 18:05:53 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 29 20:05:48 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 1beQwN-0007cP-UZ for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 20:05:48 +0200 Original-Received: from localhost ([::1]:45102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beQwL-0003Yn-KT for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 14:05:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beQvi-0003Tv-Dw for emacs-devel@gnu.org; Mon, 29 Aug 2016 14:05:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beQve-0002cp-3x for emacs-devel@gnu.org; Mon, 29 Aug 2016 14:05:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beQve-0002ce-0J; Mon, 29 Aug 2016 14:05:02 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1541 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1beQvZ-0000Bx-UG; Mon, 29 Aug 2016 14:05:00 -0400 In-reply-to: <75100b15-d49f-5a1a-d73b-24db77c891bf@dancol.org> (message from Daniel Colascione on Mon, 29 Aug 2016 10:48:31 -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:206897 Archived-At: > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 29 Aug 2016 10:48:31 -0700 > > 1) Something b-c-f is not called _at_ _all_ before certain changes > 2) Sometimes b-c-f is called once, then a-c-f is called multiple times, > because internally, changes are split into several chunks, each of which > gets its own a-c-f call > > I can understand #2 being wontfix, but can you reconsider fixing #1? There's only one such case, and the only package that's affected (CC Mode) already worked around that case. So, while I agreed that #1 should probably be fixed, and even suggested how to do that in the least risky way, actually doing that is not a priority, IMO, not until we have a very grave problem caused by it. > #1 breaks the entire b-c-f model --- "hey, I'm about to modify the > buffer, so throw away caches" ---- and can lead to anything with a > cache flush in b-c-f (like syntax-ppss) not properly discarding > out-of-date buffer information. That single case of #1 is revert-buffer, which conceptually throws away the entire buffer and replaces it with what's on disk. That it actually keeps portions of the buffer is an optimization, but the concept still stands. So I don't see how it breaks the entire model, at least not in practice.