From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Fixing post-self-insert-hook. Date: Sun, 19 Sep 2021 14:57:07 +0000 Message-ID: References: <874kahcx4h.fsf_-_@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="424"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 19 16:58:26 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mRyGw-000ARc-4r for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Sep 2021 16:58:26 +0200 Original-Received: from localhost ([::1]:52500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRyGv-00054S-6m for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Sep 2021 10:58:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRyFk-0003WF-L2 for emacs-devel@gnu.org; Sun, 19 Sep 2021 10:57:12 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:15360 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mRyFi-00020d-Bm for emacs-devel@gnu.org; Sun, 19 Sep 2021 10:57:12 -0400 Original-Received: (qmail 40004 invoked by uid 3782); 19 Sep 2021 14:57:08 -0000 Original-Received: from acm.muc.de (p2e5d5c04.dip0.t-ipconnect.de [46.93.92.4]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Sep 2021 16:57:08 +0200 Original-Received: (qmail 9003 invoked by uid 1000); 19 Sep 2021 14:57:07 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275057 Archived-At: Hello, Stefan. On Sun, Sep 19, 2021 at 08:59:59 -0400, Stefan Monnier wrote: > >> My alternative suggestion, which I've offered now and then, over the > >> years, is for you to study how cc-mode behaves when you bind the > >> delimiter keys simply to 'self-insert-command' .... > > You know full well that this is problematic. > I can't speak for Joćo, but no I don't. OK, I'm telling you now it is problematic. > >> and refrain from re-inventing 'electric-pair-mode' inside cc-mode. > > I sometimes wonder if such a reimplementation inside CC Mode might have > I don't understand the "might". You do have such a "reimplementation" > (and you even implemented it before `electric-*-mode`). And we're now reduced to silly discussions about the precise meanings of words. There is no implementation of the electric pair mode functionality in CC Mode. There is a call to an unofficial function in elec-pair.el which currently happens to work. There is no better interface available, and Joćo seems determined that there won't be one. > The difficulty you're facing is due to the face that contrary to all > other major modes which used to have such features, .... There were no other such modes. Or were there? Which modes at the time had electric indentation, or auto newline? > .... you decided to keep your implementation and try to make it > interact correctly with `electric-*-mode`s. More precisely, the difficulties were caused by electric-*-mode being developed in such a way as to be incompatible with existing major modes, in particular CC Mode modes. Perhaps you might like to say something about why you did this. It is (at least in hindsight) obvious there would be incompatibilities with CC Mode. I don't recall there being any discussion on emacs-devel at the time these electric-*-modes were being planned. If there had been, the friction which has happened since might well have been avoided. So, why did you design these new modes in such an incompatible fashion? It's perhaps worthwhile to come back to a main incompatibility introduced, and that is the original topic of this thread, post-self-insert-hook. This broke self-insert-function, at least as used in CC Mode. This is what has forced the ugly workarounds on CC Mode. Again, the question why? [ .... ] > I understand your desire to preserve exactly the featureset you designed > for CC-mode, .... More the features introduced by Barry Warsaw, Martin Stjernholm and their predecessors. They're good features, not obsolete, and change for change's sake is never something I've been keen on. > .... rather than rely on the `electric-*-mode`s features which aren't > exactly equivalent and aren't configured in the same way. They're worse features, from CC Mode's point of view. They're more complicated, more fragmented (you yourself admitted to cross coupling between the mechanisms of the different electric-*-modes), more difficult to debug, and so on. All this compared with a collection of straightforwardly written commands, c-electric-brace and friends, which just work, and have done for several decades, and would be exceptionally easy to debug if that were ever needed. > So you gave more importance to preserving compatibility with older > Emacs/CC-mode, whereas I give more importance to harmonization of > configuration and behavior across major modes. If you really wanted such harmonization, why did you create these modes with such gross incompatibilities with CC Mode? Why didn't you discuss these things with me or Martin Stjernholm first, so that we could have developed things co-operatively rather than you going your own way and trying to force the result on CC Mode? > > been less work than all the email exchange with you trying to get > > you to fix things. > There is a simpler solution at hand. You say it's "problematic", but > all solutions have their downsides. It's problematic, and anything but simple. > >> I must be honest. I don't really expect you arrive at that conclusion > >> or even try that experiment. > > No. I have a user base to consider. > Some of your user base would appreciate not having to do things > differently in CC-modes than in other modes. That's pure speculation. Also speculation: CC Mode users appreciate not having to report bugs for c-electric-brace. > Stefan -- Alan Mackenzie (Nuremberg, Germany).