From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: haj@posteo.de (Harald =?utf-8?Q?J=C3=B6rg?=) Newsgroups: gmane.emacs.devel Subject: Re: newline-and-indent vs. electric-indent-mode Date: Sat, 23 Jan 2021 03:19:27 +0100 Message-ID: <87a6t0z974.fsf@hajtower> References: <87wnw5yt58.fsf@hajtower> <87o8hgzrzi.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="39548"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: Emacs Developer List To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 23 03:21:44 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 1l38YZ-000ACN-UH for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jan 2021 03:21:43 +0100 Original-Received: from localhost ([::1]:52452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l38YZ-0002WW-0X for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jan 2021 21:21:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54254) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l38Wa-0001n1-Rs for emacs-devel@gnu.org; Fri, 22 Jan 2021 21:19:40 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:41754) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l38WU-0002Zh-SX for emacs-devel@gnu.org; Fri, 22 Jan 2021 21:19:40 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id EDEDF16005C for ; Sat, 23 Jan 2021 03:19:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1611368369; bh=MgMzOrPd8/URlXvItfIdpE8gemgKhd+HFWH5fYpDXWQ=; h=From:To:Cc:Subject:Date:From; b=M5wht7Io5kYSH2+V7w8H9KqLbrnIec7Z0AmkR/mZUgjI+xB4mfbBqj4wIYayKlCml EJXeVLoMEhUFhDEkAdAD+4B+U9o+3F1uNOUqOxh0i4aAjy4wuSJKlhi5MTO9ArhC5K AXQELhxe81xMphK85jb5+QNs3VBCJ8KaW11UQpeDsfIcUDM/w+LlNcMXYnUC7tq64r +TVeQISyrR3BOoB4uWTa3QoyuWhvFRC0DXbMaF5psUrGOyy33nuZCJbTROqrWoEmyK U7ZnQ4HbkFDFC4vUicztbPy5E5rBFsnd7sD+Wor8f8HVQA94bXYIhTM7YHpI3aAOA3 pTYTb6F/yIrlQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DN0FD134Vz6tmF; Sat, 23 Jan 2021 03:19:27 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Fri, 22 Jan 2021 17:05:41 -0500") Received-SPF: pass client-ip=185.67.36.65; envelope-from=haj@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:263293 Archived-At: Stefan Monnier writes: >>>> Many (almost all?) modes bind RET to newline-and-indent, >>> Any mode which does that should be fixed. >> Ouch... I see now that my "observation" was plain wrong. > > Yes and now: historically, it's been quite common for major modes to do > that kind of thing. I've been fighting it for many years now (even > long before `electric-indent-mode`) since it's usually the reflection of > the major mode's author's preference, rather than something directly > linked to the major mode ... Guilty, Your Honour. It would never occur to me to use any other than the RET key to advance to the next line, plus DWIM (Do What I Mean). I'm not the mode's author, though. >>> Whether RET indents or not is a user preference, not something that >>> should depend on the kind of language you're editing. >> For most programming and markup languages indenting makes sense, but >> less so for other modes. > > 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. Org mode doesn't indent, which is fine, but it has its own binding of RET (in a table it does many fancy things, amongst them add a newline). > `electric-indent-inhibit` doesn't inhibit auto-indentation. It inhibits > auto-*re*indentation. Ah, thanks for the clarification. > 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. >>> It sounds like a bug indeed. I think both having two calls (one for >>> each line) or having one call (for the new line) could arguably be >>> correct, but three calls is indeed an error. >> So... I guess newline-and-indent could suppress the call to >> indent-line-function for the new line if electric-indent-mode is t and >> electric-indent-inhibit is nil and ?\n is in electric-indent-chars? > That would be one way, tho I find it fairly ugly. Yeah, that has a certain smell. > Another might be to temporarily disable `electric-indent-mode`. The > more I think about it, the more I think this is the better choice. 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? That would seem a bit surprising. 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) - only a plain RET does. `newline-and-indent` could also temporarily enforce electric-indent-mode with electric-indent-chars set to ?\n, let that minor mode do its job while inserting the newline char, and never call indent-line-function by itself. >> [...] > 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. -- Cheers, haj