From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Lisp primitives and their calling of the change hooks Date: Fri, 5 Jan 2018 15:54:19 +0000 Message-ID: <20180105155419.GC6954@ACM> References: <20180103124543.GA5435@ACM> <20180104155111.GB6846@ACM> <20180104211154.GC6846@ACM> <838tdcbxrb.fsf@gnu.org> <20180105114107.GA6954@ACM> <83373kbguy.fsf@gnu.org> <20180105133448.GB6954@ACM> <831sj4bdpc.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1515167823 20631 195.159.176.226 (5 Jan 2018 15:57:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Jan 2018 15:57:03 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 05 16:56:58 2018 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 1eXUMa-0004fP-5U for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 16:56:56 +0100 Original-Received: from localhost ([::1]:46828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXUOX-0005Ma-P7 for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 10:58:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXUOQ-0005L3-Al for emacs-devel@gnu.org; Fri, 05 Jan 2018 10:58:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXUOK-0001Ba-B5 for emacs-devel@gnu.org; Fri, 05 Jan 2018 10:58:50 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:58856 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eXUOJ-0000z8-BZ for emacs-devel@gnu.org; Fri, 05 Jan 2018 10:58:44 -0500 Original-Received: (qmail 16965 invoked by uid 3782); 5 Jan 2018 15:58:34 -0000 Original-Received: from acm.muc.de (p548C703C.dip0.t-ipconnect.de [84.140.112.60]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 05 Jan 2018 16:58:33 +0100 Original-Received: (qmail 8681 invoked by uid 1000); 5 Jan 2018 15:54:19 -0000 Content-Disposition: inline In-Reply-To: <831sj4bdpc.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:221621 Archived-At: Hello, Eli. On Fri, Jan 05, 2018 at 16:08:31 +0200, Eli Zaretskii wrote: > > Date: Fri, 5 Jan 2018 13:34:48 +0000 > > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > From: Alan Mackenzie > > On Fri, Jan 05, 2018 at 15:00:21 +0200, Eli Zaretskii wrote: > > > > Date: Fri, 5 Jan 2018 11:41:07 +0000 > > > > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > > From: Alan Mackenzie > > > > The "complex primitive" case can be distinguised from the "atomic > > > > primitive" case because either the call to `after-change-functions' > > > > is missing (i.e. there are two consecutive calls to > > > > `before-change-functions'), or in the first call to > > > > `after-change-functions', `OLD-LEN' is less then `END' - `BEG' in > > > > `before-change-functions'. > > > > The above leaves unsaid what happens when a "complex primitive" happens > > > > to call b-c-f and a-c-f as though it were an "atomic primitive". > > > It also provides no way to know, up front, whether a given primitive > > > I'm about to call, is one or the other. IMO, we need some way of > > > doing that, if we want to document this distinction. > > Do we really need this level of detail? My idea was to enable users of > > b-c-f and a-c-f to predict what they're going to be being hit with. > > There are two patterns of handling b/a-c-f, the "atomic" and the > > "complex". My above proposal documents enough for somebody using > > b/a-c-f to be able to handle the "atomic" and "complex" uses. > > [...] > > What am I missing here? > Maybe it's me that is missing something. You first say above that you > want to "enable users of b-c-f and a-c-f to predict what they're going > to be being hit with", which is exactly my concern, but then provide a > recipe that AFAIU only works post-factum, i.e. the user can only know > whether they called an "atomic" or a "complex" primitive by analyzing > the calls to the 2 hooks as result of calling the primitive. If > that's indeed what you are saying, IMO it's not a useful criterion, > because generally when I read documentation, I shouldn't be required > to write code in order to interpret the documentation. I think I understand what you're getting at now: that Lisp hackers will be using these "complex" primitives in their code, and hence need to know the b/a-c-f calling details in detail for each such primitive. I don't think people writing modes will be using the "complex" buffer changing primitives explicitly, at least not very much. There are no such calls of these primitives in CC Mode (as far as I know). But the Lisp code will need to handle any "complex" primitives the user throws at it, e.g. upcase-region (C-x C-u). For this purpose, it is only necessary to know what sequences of b/a-c-f are foreseen, so as to be able to handle them. > > Why does that hacker need to know exactly what each buffer-changing > > primitive does, or which falls into which category? Surely it is enough > > that she handle the b/a-c-f calls appropriately. > How can she handle these calls correctly unless she knows which of the > hooks will be called by a given primitive, and whether these calls > will be balanced? And if she doesn't need to know that, then why do > we have to tell her these details about the 2 classes of primitives? Perhaps my idea of describing the primitives' use of b/a-c-f in the two categories "atomic" and "complex" would create more confusion than it would alleviate. The "atomic" primitives constitute the overwhelming bulk of those actually called at run time, so it seemed sensible to describe this common, simple case separately. Maybe this isn't the case. > IOW, accurate information is only useful if one knows exactly how to > apply it to the practical case in hand. I thought the proposed text was adequate to instruct hackers how to write b/a-c-f's to handle _any_ existing primitives. -- Alan Mackenzie (Nuremberg, Germany).