From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#38406: 27.0.50; post-self-insert-hook does not hold its contract in cc-mode derived modes Date: Sat, 7 Dec 2019 11:40:45 +0000 Message-ID: <20191207114045.GA6182@ACM> References: <20191204204159.GA7587@ACM> <83immuj0g7.fsf@gnu.org> <20191205190951.GA6252@ACM> <83pnh2h8x1.fsf@gnu.org> <20191205201713.GC6252@ACM> <83eexhho8o.fsf@gnu.org> <20191206182842.GA3999@ACM> <83y2vpffyd.fsf@gnu.org> <20191206222459.GB3999@ACM> <83h82cfsvf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253949"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 08 04:44:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1idnUQ-0013xY-Cp for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Dec 2019 04:44:10 +0100 Original-Received: from localhost ([::1]:55384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idnUP-0001SD-8q for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Dec 2019 22:44:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51622) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idnRU-0000ev-UT for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:41:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idnRS-0004Xw-Lo for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:41:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44292) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1idnRO-0004VQ-Ae for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:41:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1idnRO-0005D6-7o for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Dec 2019 03:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38406 X-GNU-PR-Package: emacs Original-Received: via spool by 38406-submit@debbugs.gnu.org id=B38406.157577646020013 (code B ref 38406); Sun, 08 Dec 2019 03:41:02 +0000 Original-Received: (at 38406) by debbugs.gnu.org; 8 Dec 2019 03:41:00 +0000 Original-Received: from localhost ([127.0.0.1]:50265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1idnRL-0005Ci-N8 for submit@debbugs.gnu.org; Sat, 07 Dec 2019 22:41:00 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:65077 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1idnRD-0005CT-Dw for 38406@debbugs.gnu.org; Sat, 07 Dec 2019 22:40:58 -0500 Original-Received: (qmail 55220 invoked by uid 3782); 7 Dec 2019 11:40:48 -0000 Original-Received: from acm.muc.de (p2E5D5590.dip0.t-ipconnect.de [46.93.85.144]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 07 Dec 2019 12:40:45 +0100 Original-Received: (qmail 6304 invoked by uid 1000); 7 Dec 2019 11:40:45 -0000 Content-Disposition: inline In-Reply-To: <83h82cfsvf.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:173022 Archived-At: On Sat, Dec 07, 2019 at 10:21:40 +0200, Eli Zaretskii wrote: > > Date: Fri, 6 Dec 2019 22:24:59 +0000 > > Cc: yyoncho@gmail.com, 38406@debbugs.gnu.org > > From: Alan Mackenzie > > > If you already call that particular function explicitly, then calling > > > it one more time is indeed redundant. > > No, it's not redundant. It's positively harmful. > Agreed. > > smie-blink-matching-open is inapplicable to CC Mode and just takes up > > processor cycles. > > electric-pair-post-self-insert-function we've already discussed. > > blink-paren-post-self-insert-function would do nothing anyhow, since > > blink-paren-function has been bound to nil - this is so that the actual > > blinking doesn't occur until the newly inserted brace is at its final > > position. > > electric-indent-post-self-insert-function is redundant and possibly > > harmful. > > electric-layout-post-self-insert-function is undocumented, thus likely > > to be harmful. Its name suggests it is redundant. > > electric-quote-post-self-insert-function is undocumented, uncommented > > and obscure. It is safer not to risk running it. > > Given that the mechanism for filtering post-self-insert-hook is there, > > why is there the resistance to filtering out redundant and effect-free > > functions? > Alan, I'm trying to do TRT here, but I cannot do everything by myself, > because that would mean I need to invest an inordinate amount of time > in each decision, and will never be able to catch up. Please help me > with this particular task by providing more detailed information about > your reasons for filtering out each of the functions you want to > filter out. You have evidently studied them, so you should know more > about them then shown above, and certainly more than I do. > In general, I'd like to leave any function that is not harmful in the > list unfiltered, even if calling it in this context is silly, or has > no effect, or is otherwise redundant. Can you please humor me by > looking at the above list through these eyes, and trying to avoid your > apparent dislike for the whole idea while at that? I really need your > help. OK, sorry for the misunderstanding. I was reasoning, subconsciously, on the basis of justifying each function to remain on the hook. Again, subconsciously, I assumed you were doing the same. If I move over to justifying each function to be filtered out of the hook, things get a lot easier. > Specifically, I'd like the following questions answered, at the very > least: > . why is smie-blink-matching-open inapplicable? The "simple-minded indentation engine" is not used in CC Mode. But we can leave it in the hook since it is harmless. > . where and why is blink-paren-function bound to nil? Your patch > calls blink-paren-function explicitly -- does that mean calling > blink-paren-post-self-insert-function will be redundant? blink-paren-function is bound to nil at the start of c-electric-brace and c-electric-paren. Otherwise, the paren blinking would happen instantaneously after inserting the } or ), even though auto-newline may still need to insert a NL before the } or ); this would be jarring for the user. c-electric-brace/paren instead call blink-paren-function explicitly after any adjustments in the buffer have been made. But leaving blink-paren-post-self-insert-function on the hook, although it is redundant, will be harmless. > . why do you think electric-indent-post-self-insert-function could be > harmful? If it's merely redundant, could we please call it here? > . electric-layout-post-self-insert-function inserts newlines, and its > documentation is in electric-layout-rules; the latter is nil by > default and only used in js.el and octave.el -- why would it be > harmful here? These two functions never have any business in CC Mode, so I wanted to exclude them from the hook for safety reasons. If they somehow became active, they might corrupt CC Mode's indentation or auto-newline mode. But there is no immediately pressing reason to filter them out of the hook. > . electric-quote-post-self-insert-function replaces quote characters > (see the doc string of electric-quote-mode); do you have specific > reasons why calling it here could be harmful or risky? Thanks for the pointer. This hook alters ASCII quotes to curly quotes, but does so only in comments and strings. It might corrupt code if a user edits the code whilst it is commented out, or (in C++) "stringed out" by a long raw string (yes, I have seen this happening). So, I suppose we could say that any user who enables electric-quote-mode and comments out code should be aware of what she is doing. Although it would not happen often, getting a curly quote into commented out code, then uncommenting it, would be a difficult error to spot, with seemingly non-sensensical compiler error messages. But, thinking about it, there is no function `c-electric-quote', so filtering out electric-quote-p-s-i-f will never have any effect on anything. So there is no point in doing so. So, that would leave just electric-pair-post-self-insert-function to be filtered out of the hook. > > And how come functions without meaningful doc strings are allowed onto > > Emacs hooks? > Please, let's not try fix all of Emacs while working on this single > issue. I agree that undocumented functions is not a good thing, but, > as shown above, documentation for what these functions do _is_ > available nearby. OK. > Thanks. -- Alan Mackenzie (Nuremberg, Germany).