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: Default behaviour of RET. Date: Thu, 24 Oct 2013 05:53:41 +0400 Message-ID: <52687DA5.4040002@yandex.ru> References: <8361sqli02.fsf@gnu.org> <1730ebf3-db44-498c-b2a9-4d288d83a946@default> <87k3h6xuen.fsf@yandex.ru> <20131023201809.GA4175@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 1382579654 23590 80.91.229.3 (24 Oct 2013 01:54:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Oct 2013 01:54:14 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org, rudalics@gmx.at, monnier@iro.umontreal.ca, Eli Zaretskii , stephen@xemacs.org, Drew Adams To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 24 03:54:17 2013 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 1VZA7s-0007lO-FQ for ged-emacs-devel@m.gmane.org; Thu, 24 Oct 2013 03:54:16 +0200 Original-Received: from localhost ([::1]:52147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZA7r-0002qr-Uw for ged-emacs-devel@m.gmane.org; Wed, 23 Oct 2013 21:54:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZA7h-0002qm-GF for emacs-devel@gnu.org; Wed, 23 Oct 2013 21:54:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZA7Z-0007Ys-2n for emacs-devel@gnu.org; Wed, 23 Oct 2013 21:54:05 -0400 Original-Received: from mail-ea0-x22b.google.com ([2a00:1450:4013:c01::22b]:43729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZA7Q-0007TW-5M; Wed, 23 Oct 2013 21:53:48 -0400 Original-Received: by mail-ea0-f171.google.com with SMTP id n15so842020ead.2 for ; Wed, 23 Oct 2013 18:53:46 -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=X+oAmuJVM4XrXvrDsxDL7p5RWE0nMiN4739wsbvoADo=; b=JTOGPSLTg2WUcWBUrBilJKOncCragSsahx6hNptlNbo8TY8+JOxnObw7DPSKNz9pm2 dOzzndyj46BAkA/L8T0KKmnUY1Rf44LXjao8ZB94yZgPY0n3gslhCyYB+47cCl/av3BK 0dl6ae/zXZeKPNGygvnEELVzoJqA16HVAycFzT3aEltjUwAP+2ljUts9sHYpFpz+fOE4 4M9K6G8OeHK3ZLywLHFxUTv3zrJS36nuxKv30SDBOEQsQRuZ3trg3FukWBmNLu9k0iMp /KfYDbNwTYSg58DRHqzZjUWS5yrqewJYn8e5xEOPcsIGmLZw5Q/AgNRlMQcYbXrBQ4hq KGqw== X-Received: by 10.15.31.9 with SMTP id x9mr215340eeu.53.1382579626894; Wed, 23 Oct 2013 18:53:46 -0700 (PDT) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id e13sm77108597eeu.4.2013.10.23.18.53.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 18:53:46 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <20131023201809.GA4175@acm.acm> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22b 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:164497 Archived-At: Hi Alan, On 24.10.2013 00:18, Alan Mackenzie wrote: >> I really have to wonder when anyone would wish to use RET bound to >> newline. Why? Does some popular major mode provide inadequate >> indentation function, so that you have to pick whether to indent the >> next line automatically or not? > > `newline' is the Right Thing to do in non-programming modes like Text > Mode, at least a lot of the time. > > For example, it is if you have paragraphs indented like this one, where > you use auto-fill-mode to calculate a non-null fill prefix to indent > subsequent lines of the paragraph and RET to start a new paragraph at > column zero. > > Even in programming modes, you might want to start a whole-line comment > at column zero, even where (or especially where) the code is deeply > indented. I see your point. > My personal position is that I'm quite happy with RET doing `newline' and > C-j doing `newline-and-indent', but (despite being a traditionalist) I > wouldn't be that bothered if those bindings were exchanged. I would be > most unhappy if the `newline' functionality were to be obliterated, even > in restricted circumstances like `electric-indent-mode' being enabled and > \n being in `electric-indent-chars'. This seems like the best solution to me: either just a change of default bindings, or a new by-default-on minor mode. And removal of `\n' from `electric-indent-chars' everywhere. The alternative approach of remapping `C-j' to `newline' when `electric-indent-mode' is on seems less consistent to me, because there's no hard guarantee, AFAICT, that `electric-indent-chars' will include \n in all situations (modes and user configurations).