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:29:06 -0500 Message-ID: References: <87wnw5yt58.fsf@hajtower> <87o8hgzrzi.fsf@hajtower> <87a6t0z974.fsf@hajtower> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34924"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Emacs Developer List To: haj@posteo.de (Harald =?windows-1252?Q?J=F6rg?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 23 04:29:54 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 1l39cY-0008zP-NJ for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jan 2021 04:29:54 +0100 Original-Received: from localhost ([::1]:43272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l39cX-0006f6-LB for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jan 2021 22:29:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l39bt-0006EQ-9N for emacs-devel@gnu.org; Fri, 22 Jan 2021 22:29:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11127) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l39br-0000ER-5J for emacs-devel@gnu.org; Fri, 22 Jan 2021 22:29:12 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BD98B440FDA; Fri, 22 Jan 2021 22:29:09 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2631E440ADE; Fri, 22 Jan 2021 22:29:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1611372548; bh=JARnKsHWiHIV9Kl75OeVS6OiAqDOZtZyCtoqDJBCbZ0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=eVgpoulz9+SZqU23TlvhR70G9aB8xuXpec0VPPPu031plODsRQVnnPytcFgDndMJS LzORMjuLkeZYh1NQecS2uTj2julp7tiJcrlfh7kIyIXlqFIuN0ZDWNx8a1ClHzYYEH JlVAjdB8ZBt1b3nIyPdQIph9cgaddQT+A/xH4VVsOUSbkw7T+KTjasc3veuBoknNFH Snim/pngwHNP2r28WkvoRevQF+W9oFUMbPLfFlZvEzFm+qKuYvlzzQgWG3CS1Zl651 1Pbu1xVqXXF/9BO2q8kOR7lQ0XmCo+mfLE2gg4haVmxs46UVApNFSg7XGaBQeLoYu1 IZ9EpodLJ3Hhg== Original-Received: from alfajor (65-110-220-188.cpe.pppoe.ca [65.110.220.188]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DF7F8120304; Fri, 22 Jan 2021 22:29:07 -0500 (EST) In-Reply-To: <87a6t0z974.fsf@hajtower> ("Harald =?windows-1252?Q?J=F6rg=22?= =?windows-1252?Q?'s?= message of "Sat, 23 Jan 2021 03:19:27 +0100") 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:263297 Archived-At: >> Concrete examples would be helpful and could be reported as bugs ... > I don't think these are bugs, but my personal user preference is to have > RET indent in programming modes but not in text modes. You might like to try removing that customization and then complain about the cases that don't behave like you want. I don't guarantee I'll agree, but since `electric-indent-mode` is globally enabled by default, I think it's important to try and make sure it's not too annoying in those modes where it's not helpful. >> I know it takes many people by surprise (because the choices are more >> refined than just "on or off" and they don't expect that), but I find it >> hard to improve the docs to guide the users/programmers. > I admit that the whole electric-indent stuff is new to me. I saw it > happening but never checked *why* it is happening. First time I noticed > it explicitly was in the backtrace leading to my original post. Yes, it happened because I think it's important to consolidate the needs shared by all major modes. It's surprisingly hard work, because every major mode tends to do it slightly differently, so the consolidated version is never "quite the same", thus encountering a lot of resistance to change. > Wouldn't that result in `newline` re-indenting both the new and the > previous line (as per electric-indent-mode), but `newline-and-indent` > *not* re-indenting the previous line? Yes. > That would seem a bit surprising. Then again, the users have the choice of either calling `newline-and-indent` or `reindent-then-newline-and-indent`, so presumably when they choose `newline-and-indent` it's because they don't want the first line to be reindented. It also brings back the behavior they had before `electric-indent-mode`. > First experiments suggest that the patch does indeed change the behavior > when a line contains just a closing "]" or ")" - neither > (newline-and-indent) nor (cperl-linefeed) now re-indent that line (which > they should) This behavior is the behavior that `cperl-linefeed` had when it was written, so I disagree with "they should". >> IMO keybindings is more harmful than anything here, so a better choice >> would be to offer only plain newline and newline+indent+fancystuff, bind >> them to RET and LFD, let `electric-indent-mode` control which of RET and >> LFD does which, and let `cperl-electric-linefeed` control whether >> fancystuff is done at all. > > That sounds good... it would need some unraveling to prevent deep > recursion. `electric-indent-mode` calls the mode-specific indentation > function, which would optionally call fancystuff, which in turn calls > both newline-and-indent _and_ the mode-specific indentation function. I haven't even looked at what it would take in terms of coding. Hell! I don't even know half of what the "fancystuff" does, so maybe I'm just plain wrong about what should be done. In other words: I won't be touching this code any time soon (I'd much rather add some of the "fancystuff" features to `perl-mode`, where I wouldn't need to worry about breaking old cperl-mode users's habits). Stefan