From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it. Date: Mon, 21 Jan 2019 20:45:44 +0000 Message-ID: <20190121204544.GC4514@ACM> References: <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> <20190119110729.GA4644@ACM> <875zukpxe2.fsf@gmail.com> <20190119174505.GA4749@ACM> <87k1j0sble.fsf@gmail.com> <20190119205833.GB4749@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="78701"; mail-complaints-to="usenet@ciao.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 21 21:58:02 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glgdr-000KLS-RS for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2019 21:57:59 +0100 Original-Received: from localhost ([127.0.0.1]:59945 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glgdq-0001Hw-Ny for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2019 15:57:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glgdZ-0001CG-1W for emacs-devel@gnu.org; Mon, 21 Jan 2019 15:57:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glgdX-0007V4-VI for emacs-devel@gnu.org; Mon, 21 Jan 2019 15:57:40 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:51596 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1glgdV-0007Ic-37 for emacs-devel@gnu.org; Mon, 21 Jan 2019 15:57:38 -0500 Original-Received: (qmail 65948 invoked by uid 3782); 21 Jan 2019 20:57:22 -0000 Original-Received: from acm.muc.de (p4FE15FA8.dip0.t-ipconnect.de [79.225.95.168]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 21 Jan 2019 21:57:21 +0100 Original-Received: (qmail 4012 invoked by uid 1000); 21 Jan 2019 20:45:44 -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 [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:232579 Archived-At: Hello, Stefan. On Mon, Jan 21, 2019 at 13:04:57 -0500, Stefan Monnier wrote: > > If I said the sky was blue would you say "where's your evidence?"? > > It is a fact that c-electric-brace controls, and must control, each > > change to the buffer which is done. > Not only I don't think that this is true, but I don't even know exactly > what it means (IOW, yes it's probably true for some interpretation of > it, but not for others). > > This is self evident from reading the source code. > I don't see this evidence. Look in c-do-brace-electrics in an up to date (i.e. within the last few days) version of cc-cmds.el. This function is called from several places in c-electric-brace. About 60% the way through is the "brace-else-brace" cleanup. It works by scanning the buffer for a particular pattern. If arbitrary changes (i.e. those not controlled by the major mode) have been made to the buffer, the pattern might not be found when it should be. For example. This was precisely the cause of bug #33794. The user typed "{", but unknown to c-electric-brace, self-insert-command randomly inserted "{}". This extra "}" prevented auto-newline from working. With the advent of post-self-insert-hook, it is clear that calling self-insert-command from a function can lead to arbitrary buffer changes. To prevent this, c-electric-brace and friends bind post-self-insert to nil. Another way to proceed would be your recent suggestion of using insert rather than self-insert-command. It is thus clear that the use of post-self-insert-hook is incompatible with Lisp code which calls self-insert-command, since that use effectively makes that function undefined. The way this hook is typically used is much more like advice (which modifies a function's function) than a traditional hook (where the hook performs things incidental to what triggers it, leaving the triggering event untouched). > > Please read the source code for c-electric-brace and its immediate > > sub-functions, understand it (it's not hard), and then come back to me > > with any questions you may have. > expand-abbrev also can be extensive changes during self-insert-command, > and so can the auto-fill-function. In practice, they haven't done so. If they did, then using insert would solve the problem. > > It is a fact that electric-layout-mode and electric-pair-mode are > > allowed to run from post-self-insert-hook, that they make buffer changes > > which are outside the control of c-electric-brace. > If you use electric-layout-mode and electric-pair-mode, then all that's > left for c-electric-brace is to call self-insert-command. No. There's more to it than that. > And indeed, I hope in the future that the { and } bindings will simply > be removed from CC-mode. Maybe in the medium future, when the pertinent generic functions are in all Emacs versions supported by CC Mode (assuming that XEmacs support will cease quite soon). These generic functions have some way to go before they match the functionality of CC Mode's own features. > I understand that there's a transition needed between these two and this > intermediate state can require more work, but it's important to keep the > long term goal in mind when designing the current solution. Whose long term goal? My goal, both long and short term, is to keep CC Mode working properly. > Stefan -- Alan Mackenzie (Nuremberg, Germany).