From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Questioning the new behavior of `open-line'. Date: Mon, 16 Nov 2015 18:42:30 -0600 Message-ID: <87ziydbgnd.fsf@red-bean.com> References: <87vb98csu1.fsf@red-bean.com> <83si4cjnyw.fsf@gnu.org> <87twosp5ke.fsf@fencepost.gnu.org> <87fv0cm64g.fsf@gmx.us> <87si4bsktk.fsf@red-bean.com> <87wptnlbl6.fsf@gmx.us> <87pozfl2ut.fsf@gmx.us> <87d1vfl17p.fsf@gmx.us> <878u63p6sh.fsf@fencepost.gnu.org> <87pozfchq6.fsf@red-bean.com> <87h9komkty.fsf@fencepost.gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447723119 12707 80.91.229.3 (17 Nov 2015 01:18:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 01:18:39 +0000 (UTC) Cc: Pierpaolo Bernardi , Artur Malabarba , emacs-devel To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 02:18:38 2015 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 1ZyUul-0001aZ-C0 for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 02:18:31 +0100 Original-Received: from localhost ([::1]:54852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyUuk-0001qX-V9 for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 20:18:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyUM4-0004Zs-Lv for emacs-devel@gnu.org; Mon, 16 Nov 2015 19:42:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyUM1-0001nb-FR for emacs-devel@gnu.org; Mon, 16 Nov 2015 19:42:40 -0500 Original-Received: from mail-ig0-x22f.google.com ([2607:f8b0:4001:c05::22f]:38452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyUM1-0001nV-A3; Mon, 16 Nov 2015 19:42:37 -0500 Original-Received: by igbxm8 with SMTP id xm8so2247147igb.1; Mon, 16 Nov 2015 16:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=jVBtdpfqNaVfVxtc4K1u9TlbLtO1Pk6TGXtCLvd3umQ=; b=rzvZCqXVoJXUT+PyVgZBdTf7SyKV+jgvj1h46uMe7gHbVtz9TT1f80XM6oHT6+L+Wb ST7BuJ7N05gL62f/RB4Z8jMv8Rbzq6dzWUBD43l0TR+LZWhLm8P35ltxISEKwxqaRd1W AcxdUKaiRqv4U8aK5OlD/NP7JsqInsj47P/l0C6BzGAelwxmMrPcm984uoiBBYPL6PhW hftNBhmV8E7OmupD8wGj/RXGbXFuRYYerHPYzcMLOGpMGDyd40myMuxY+bBE22b0DGIS VKNUuVHDC20MUjgA0ydNZ1uWSs95TWc/NfrZFUyuWFuw8Mj0HH4/xAq51V+q8sQfZk9q PgTA== X-Received: by 10.50.43.162 with SMTP id x2mr17911952igl.82.1447720956655; Mon, 16 Nov 2015 16:42:36 -0800 (PST) Original-Received: from floss (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id 4sm9072640igz.2.2015.11.16.16.42.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 16:42:35 -0800 (PST) In-Reply-To: <87h9komkty.fsf@fencepost.gnu.org> (David Kastrup's message of "Sat, 14 Nov 2015 20:39:53 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::22f 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:194619 Archived-At: Artur, it sounds to me like there is not yet consensus on what C-o should do at column >0. There have been plausible arguments both ways. But since there wasn't really consensus on the original change either, and since there *is* consensus on what C-o should do in column 0 (namely, just insert a newline and do no indentation), maybe the best course for now is to revert the change, so we go back to the old behavior, and then continue this discussion so we can determine the right behavior for the next release of Emacs after this one? By "old behavior", I mean "just inserts a newline". This is correct for column 0, and is at least desired by some people in other positions; and it's the behavior we had for a long time, of course, so it's okay if it stays the same in this release too. After all, the old behavior was not really considered an outright bug by most people, as far as I'm aware. Thoughts? This is assuming there's still time to make the reversion on the release branch (it would then get merged to master soon). I'm not sure whether there is, and hope someone here who is tracking that more carefully can say for sure. I'm happy to do the reversion, if you're pressed for time. Best regards, -Karl David Kastrup writes: >Artur Malabarba writes: > >> 2015-11-13 6:04 GMT+00:00 Pierpaolo Bernardi : >>> The old behaviour is: ctrl-o inserts a newline after the point, >>> nothing else is done. >> >> Ok, thanks for clarifying. Still can I ask for an example usage where >> that behaviour is good and the current behaviour is bad. > >I want to break a line before a line-ending comment (single ;) and >change that line-ending comment to a line comment (double ;;) >afterwards. If Emacs gets a chance at indenting before I get a chance >at editing, it will even make a total mess of the comment line even when >it is doing everything "correctly" according to the current look of the >line. > >More often than not, however, I use C-o when I know that Emacs' >indenting is going to be terminally wrong anyway. > >But of course not having the material run away automatically before I >get a chance at editing it is also a valid consideration. > >> I'm not trying to be annoying here. It's just that I want to clearly >> list all relevant scenarios when I write the commit message (so that >> future hackers will know about them before changing some behaviour). > >Frankly, I cannot imagine your C-o behavior to be useful at all since >C-o is intentionally a dumb command to revert to for incremental >editing. You use it either when you don't want automatic indentation, >or if you still have material to add on the current line. And if you >still have material to add on the current line, it will likely be >relevant for indentation, so it's comparatively useless for C-o to >indent prematurely. > >If not, there is still C-M-o bound to split-line rather than C-o bound >to open-line.