From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478. Date: Thu, 27 Mar 2014 10:02:49 +0200 Message-ID: <5333DB29.7030403@yandex.ru> References: <20140316223509.GD3854@acm.acm> <20140319224231.GB4783@acm.acm> <20140322131350.GA3163@acm.acm> <20140322223454.GA3562@acm.acm> <20140324224055.GB3825@acm.acm> <87d2hb9hys.fsf@yandex.ru> <20140326205330.GA3787@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1395907386 7089 80.91.229.3 (27 Mar 2014 08:03:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Mar 2014 08:03:06 +0000 (UTC) Cc: Stefan , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 27 09:03:15 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WT5HN-0003IZ-Lt for ged-emacs-devel@m.gmane.org; Thu, 27 Mar 2014 09:03:13 +0100 Original-Received: from localhost ([::1]:52162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WT5HN-0003OS-9o for ged-emacs-devel@m.gmane.org; Thu, 27 Mar 2014 04:03:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WT5HD-0003OF-0F for emacs-devel@gnu.org; Thu, 27 Mar 2014 04:03:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WT5H4-0002Ed-Ht for emacs-devel@gnu.org; Thu, 27 Mar 2014 04:03:02 -0400 Original-Received: from mail-ee0-x232.google.com ([2a00:1450:4013:c00::232]:35702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WT5H4-0002EU-72 for emacs-devel@gnu.org; Thu, 27 Mar 2014 04:02:54 -0400 Original-Received: by mail-ee0-f50.google.com with SMTP id c13so2473288eek.23 for ; Thu, 27 Mar 2014 01:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=upN66YGkzRlXXPRhEdspcBdmuAB1OkJX/pG1IwHe5Zw=; b=ik5JPrPlCK8+M2D3CntT7ZB/6L4SPLH6y3mtL2sozJ2YqS52tsaTza43IVGpWGXpi7 X4pz54d8vtx6AQqNI9juxDkWdZS5PIUpa6tPqjQcFQ+ndr/q6od8Uu5poz2plXMgkgJA fWEEKbW7r/UP3c+CiZSwTzBlyMW8zOWXEHLvbemjenYxZqKwdSKYxt+B3rbz1X+gf3fv OMxqXw11F8hm3BfTmSZ4OXAseNlAYoErsDXfPEdr+33/vIWqOtnRM4O57SenW/gfWNvK ohmAKJ1RE2PicxcwnQFMqgwTEhHf4ivKp7uLziL+Uz1jXPDOvev9fN7Z2RsEfeqEQtD9 G5LA== X-Received: by 10.14.224.6 with SMTP id w6mr344919eep.60.1395907373179; Thu, 27 Mar 2014 01:02:53 -0700 (PDT) Original-Received: from [192.168.10.2] (6-67.adsl.cytanet.com.cy. [83.168.6.67]) by mx.google.com with ESMTPSA id x45sm2642291eeu.23.2014.03.27.01.02.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 01:02:52 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <20140326205330.GA3787@acm.acm> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171025 Archived-At: Hi Alan, On 26.03.2014 22:53, Alan Mackenzie wrote: > Indentation (in the sense of what `indent-line-function' does) only makes > sense in programming (etc.) modes. In text modes, and the like, > indentation is, in practice, done with adaptive fill prefices. This could be considered a reason to improve the indent-line-function in text-mode. `indent-relative' offers behavior that's pretty close. Maybe it could be made to follow the behavior of auto-fill even closer. > Having RET do `newline-and-indent' in Emacs Lisp Mode while doing > `newline' in Text Mode makes a lot of sense to me. A trickier question > is to identify which of the non-programming modes really want this sort > of indentation. I'd rather make exceptions for specific "non-programming modes", where indentation of the next line is really hard to guess. Many modes that don't inherit from prog-mode have something to do with structured content, and often define their own specific indentation functions (sgml-mode, markdown-mode inherit from text-mode, css-mode and yaml-mode inherit from fundamental-mode). I'd really expect typing
and pressing RET in html-mode to offer hard +2 indentation on the next line, but I wouldn't call it a programming mode. In Markdown, I'm often typing code blocks, and I expect RET to bring me to the column which the previous line was indented to, so I don't have to press TAB each time. And if I'm outside of a code block, the lines usually either have no indentation (then indent-relative indents to the 0th column as well), or they serve as continuation of a paragraph, and I want each next line to have the same extra indentation until the paragraph ends (and indent-relative does that well enough). The last time I used text-mode, it was for a similar purpose (a couple of code blocks, and the rest of the text is indented to column 0). `M-x fill-paragraph' would slaughter the code blocks, and it wouldn't improve the indentation anywhere else. It also eats line breaks that were put in manually. A good example is ChangeLog files: we often see cleanup commits in Emacs that change the places where the lines are broken, for better readability, in ways that fill-paragraph is unable to do automatically. And if ChangeLog files didn't always magically have the right indentation (one tab), and one had to fix it with `fill-paragraph', all the manual line breaks would be mangled, each time. It still happens when I fix lines that are too long this way. >> There's a certain class of users who've been binding RET to >> `newline-and-indent' for a long time (myself included), and I haven't >> seen anyone mention only doing that in prog-mode, instead of globally. > > That was what we collectively decided last Autumn when the topic came up. Okay: I haven't seen anyone mention doing it outside of emacs-devel. > Richard Stallman alluded to it in his disgust at bug #16156, when what > was bound to RET at the time zapped his indentation. > > I personally would not be unhappy at leaving the traditional binding in > place for RET and C-j, but wouldn't mind them swapping in "indenting" > modes. I'd object strongly to RET in text mode messing around with > indentation. Maybe text-mode by itself should be a special case. I don't use it often enough to have a strong opinion. >> How hard can it be for a user to change the key bindings without a mode? > > Middling, not very. Such a minor mode might serve to damp down the > inevitable complaints the change in defaults will provoke. As long as this new mode is divorced from electric-indent-mode, I'd be happy. > By "makes sense" I think you mean "seems a sensible thing to do". I take > issue with you here and say that, in Text Mode, it's a bizarre thing to > do. I can't think of any normal circumstances where this behaviour would > be commonly desired; just how often in Text Mode do you not want RET just > to insert a new line when you type it at the beginning of a line? This specific behavior is a consequence of using `newline-and-indent'. One answer may be "Don't want that? Use `open-line'", which I sometimes do, but special-casing indent-line-function in text-mode not to reindent on the first invocation (when point is at bol followed by whitespace and then non-whitespace on the same line) could well be another option. What makes sense to me, is using `newline-and-indent' itself. Richard doesn't like foo | bar turning into foo |bar I can understand that, but I don't like foo bar|baz turning into foo bar |baz (note the missing indentation) Which situation do you think occurs more frequently?