From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: newline-and-indent vs. electric-indent-mode Date: Fri, 22 Jan 2021 22:16:39 -0500 Message-ID: References: <87wnw5yt58.fsf@hajtower> <01d07f6d-cc4c-2f54-4bae-a611bba7be93@yandex.ru> <66b7932d-4cee-9628-fae0-168ee6ebc041@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24665"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Harald =?windows-1252?Q?J=F6rg?= , Emacs Developer List To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 23 04:17:33 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 1l39Qb-0006Jj-Ms for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jan 2021 04:17:33 +0100 Original-Received: from localhost ([::1]:38966 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l39Qa-00043z-L3 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jan 2021 22:17:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59732) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l39Pv-0003cI-KO for emacs-devel@gnu.org; Fri, 22 Jan 2021 22:16:52 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61057) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l39Ps-0004dq-G1 for emacs-devel@gnu.org; Fri, 22 Jan 2021 22:16:50 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CF2E180E11; Fri, 22 Jan 2021 22:16:46 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9382C80241; Fri, 22 Jan 2021 22:16:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1611371800; bh=QPO0WSyPMTmu9tH2TBDz3hHjPUK9yPcfBfauv98IHqY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RlfSMe+dJGFG/vPFpDXWOct74A+oWfvzNfEP6d+TpFxelWGKpU7eXS0c3md1EQ8Wo 8Z+FxOaMcUB/wjqw6PTGG1u+I73s+Mc8WBd9FHD9kBi1lUCyuzyTYaIQefD/76vUBR hWVGLtKgUW4kZTj0Grf1BxAuRgNVVssFUAJGzVWW1/PgFBMPf9yweHYsxdT3O3ZZW5 sQBxAjWkoJsAqhwjrzkOCwH9IphzYNPtToP84Xr7fqwqYeizo8EXkGqSJEAX5iDcyo R6pqGHQqXhiL1tMN7EF3DpCXzp5UB2iQESI4BmGvvYKfm5MsMKqyZEe23/wuyoy9TG 74tyEIw9BdZPg== Original-Received: from alfajor (65-110-220-188.cpe.pppoe.ca [65.110.220.188]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4EE9C1203D5; Fri, 22 Jan 2021 22:16:40 -0500 (EST) In-Reply-To: <66b7932d-4cee-9628-fae0-168ee6ebc041@yandex.ru> (Dmitry Gutov's message of "Sat, 23 Jan 2021 02:45:01 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:263296 Archived-At: > I'm not sure how it is a bug. It's "reindentation" in both cases, right? > And electric-indent-inhibit's docstring refers to reindentation. But with the current behavior, a char other than \n into `electric-indent-chars` can never have any effect when `electric-indent-inhibit` is non-nil. So I'd argue that a char other than \n should take precedence over `electric-indent-inhibit`, especially because such a char can only be there if it's been explicitly added. >>> It's just that in my mental model \n doesn't belong to the current line, >>> only to the next one. So it shouldn't reindent the original line. >> It's often useful for me, as in typing >> foo RET else RET blabla >> where the else benefits from being reindented upon the second RET. > I see. Well, ruby--electric-indent-p covers this scenario already. Indeed, this approach can work as well. [ BTW, here's another one where ruby-mode is saved by the reindentation done by `newline`: foo RET endl DEL RET ;-) ] > Perhaps your approach is simpler, but always reindenting the original line > gets annoying if the indentation function sometimes produces suboptimal > results. I think `electric-indent-mode` is annoying in any case if the indentation code disagrees with your style. There are lots of knobs to play with deciding when and were indentation happens, and it's hard to know what the statistically optimal heuristic. So I won't try to argue that the current choice is best, but I think it's equally hard to argue that some other choice is best. If we could automatically detect when a reindentation is immediately undone by the user, maybe we could collect statistics. > again, or undo the change and go with C-o C-n TAB. I think `C-j TAB` is quicker (but I must admit that my muscle memory often makes me do `C-q C-j TAB`) Stefan