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: Thu, 18 Aug 2016 12:56:32 -0400 Message-ID: References: <83fuqnm6og.fsf@gnu.org> <83eg67m3aq.fsf@gnu.org> <20160808143614.GA7208@acm.fritz.box> <83mvkni7xf.fsf@gnu.org> <20160808165449.GB7208@acm.fritz.box> <83d1lji3ih.fsf@gnu.org> <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> <831t1wharr.fsf@gnu.org> <83mvkaduh0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1471539527 30932 195.159.176.226 (18 Aug 2016 16:58:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Aug 2016 16:58:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 18 18:58:43 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 1baQeQ-0007o7-7P for ged-emacs-devel@m.gmane.org; Thu, 18 Aug 2016 18:58:42 +0200 Original-Received: from localhost ([::1]:53619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baQeN-00072G-CV for ged-emacs-devel@m.gmane.org; Thu, 18 Aug 2016 12:58:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baQcY-0005yL-FF for emacs-devel@gnu.org; Thu, 18 Aug 2016 12:56:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1baQcU-0006FA-Cu for emacs-devel@gnu.org; Thu, 18 Aug 2016 12:56:45 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:44790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baQcU-0006Ew-6p; Thu, 18 Aug 2016 12:56:42 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u7IGv856014081; Thu, 18 Aug 2016 12:57:10 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 30295AE0E9; Thu, 18 Aug 2016 12:56:32 -0400 (EDT) In-Reply-To: <83mvkaduh0.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 18 Aug 2016 17:26:03 +0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5770=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5770> : inlines <5115> : streams <1686190> : uri <2269468> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:206651 Archived-At: > One questionable place is insert-file-contents: it deliberately never > calls the before-change-functions when it deletes portions of the > text, only when it inserts text. So, if insert-file-contents only deletes a portion of text, it doesn't call before-change-functions at all? That'd be a bug, yes. > I don't really understand the reasons behind your insisting on > before-change-functions being called before any changes in this case, For example, because syntax-ppss uses before-change-functions to notice when the cache needs to be flushed, and that is necessary for any change, including deletions, and whether the deletion is performed by insert-file-contents or something else is mostly irrelevant. > but maybe a simple way out would be to announce at the beginning of > the function that the entire range between point-min and point-max is > about to be changed, when REPLACE is non-nil. That'd be pessimistic, but yes, it's an easy way to fix the bug, and it'd probably be good enough. > Another place where before-change-functions is not called, but > after-change-functions are is set-buffer-multibyte. Moreover, if the > function is called with a nil argument, we don't call > after-change-functions as well. Is that supposed to be handled as a > buffer change or not? Good question. I guess it would make sense to call b-c-f on the whole buffer. This said, I think we should strongly discourage use of set-buffer-multibyte in non-empty buffers, so it's not terribly important: in the "normal" case set-buffer-multibyte should not perform any buffer modification anyway. > In the low levels of encoding and decoding routines, we sometimes call > the hooks and sometimes don't, depending on what is the source and the > destination of the en/decoding, and whether there are pre-write or > pre-write conversions. But the buffer in question is a temporary > conversion buffer, so do we care? The temp-conversion-buffer is an internal implementation detail. I'd rather we never call a/b-c-f in those, but it's not terribly important. > In message_dolog, which is called by any code which logs a message in > *Messages*, we never call the before-change-functions for the > *Messages* buffer, but we do call the after-change-functions for it. > Problem or not? The *Messages* buffer is sufficiently special that I'm not worried. > That's all I found. Great, thank you very much. > It intentionally refrains from saying "any and all modifications", and > instead tries to be more vague. Do you still think this is not good > enough? I think it's good enough. Stefan