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: Unbalanced change hooks (part 2) Date: Tue, 2 Aug 2016 10:15:49 +0000 Message-ID: <20160802101549.GA2328@acm.fritz.box> References: <20160731121642.GB2205@acm.fritz.box> NNTP-Posting-Host: blaine Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470133064 17993 195.159.176.226 (2 Aug 2016 10:17:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 10:17:44 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 12:17:40 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 1bUWlX-0004Iw-BD for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 12:17:39 +0200 Original-Received: from localhost ([::1]:55115 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUWlR-0004AV-37 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 06:17:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUWkj-0004AD-03 for emacs-devel@gnu.org; Tue, 02 Aug 2016 06:16:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUWkc-0003MJ-Pt for emacs-devel@gnu.org; Tue, 02 Aug 2016 06:16:47 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:46732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUWka-0003Ls-WF for emacs-devel@gnu.org; Tue, 02 Aug 2016 06:16:42 -0400 Original-Received: (qmail 21681 invoked by uid 3782); 2 Aug 2016 10:16:30 -0000 Original-Received: from acm.muc.de (p548C7CD5.dip0.t-ipconnect.de [84.140.124.213]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Aug 2016 12:16:27 +0200 Original-Received: (qmail 2388 invoked by uid 1000); 2 Aug 2016 10:15:49 -0000 Content-Disposition: inline In-Reply-To: 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 X-Received-From: 193.149.48.3 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:206344 Archived-At: Hello, Richard. On Mon, Aug 01, 2016 at 12:38:42PM -0400, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > There are several functions in .../src/insdel.c which have a parameter > > `prepare'. The meaning of `prepare' is "direct the function to call > > prepare_to_modify_buffer" (YUCK!). > Why do you say "yuck" to that? Hey, don't misquote me! I said "YUCK!", not "yuck". :-) It's my emotional reaction to a dodgy coding practice. We have two functions, one of which assumes far too much about the inner workings of the other. This "convolution" (as Richard Copley described it) is liable to lead to all sorts of tangles and awkwardnesses and things generally being very difficult to maintain. > I'm not saying it can't have problems, or that you can't > think of some change for the better. However, to merit "yuck", > it would have to be grossly and conspicuously bad. I think the particular instance IS grossly and conspicuously bad. The resulting code is so difficult to maintain that (i) our before-change-functions/after-change-functions mechanism is broken, in that the b-c-f hook is only called for some changes, not all changes; (ii) Eli Z. has forcefully declined my offer to fix this, on the grounds that the pertinent code (in .../src/insdel.c) is so fragile that any attempt to fix it will inevitably introduce hidden bugs elsewhere. This `prepare' parameter is central to the difficulties of fixing/not being able to fix the b-c-f/a-c-f mechanism. > -- > Dr Richard Stallman > President, Free Software Foundation (gnu.org, fsf.org) > Internet Hall-of-Famer (internethalloffame.org) > Skype: No way! See stallman.org/skype.html. -- Alan Mackenzie (Nuremberg, Germany).