From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: please make line-move-visual nil Date: Thu, 14 May 2009 18:17:12 +0000 Message-ID: <20090514181712.GA2413@muc.de> References: <4A0C402C.7060804@slugfest.demon.co.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242325021 22162 80.91.229.12 (14 May 2009 18:17:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 May 2009 18:17:01 +0000 (UTC) Cc: Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 14 20:16:54 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M4fUE-00035S-6d for ged-emacs-devel@m.gmane.org; Thu, 14 May 2009 20:16:54 +0200 Original-Received: from localhost ([127.0.0.1]:53397 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M4fUD-0003eK-FS for ged-emacs-devel@m.gmane.org; Thu, 14 May 2009 14:16:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M4fU8-0003e2-AS for emacs-devel@gnu.org; Thu, 14 May 2009 14:16:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M4fU3-0003ak-TI for emacs-devel@gnu.org; Thu, 14 May 2009 14:16:47 -0400 Original-Received: from [199.232.76.173] (port=37749 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M4fU3-0003aY-OD for emacs-devel@gnu.org; Thu, 14 May 2009 14:16:43 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:1141 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M4fU2-000460-Pp for emacs-devel@gnu.org; Thu, 14 May 2009 14:16:43 -0400 Original-Received: (qmail 14679 invoked by uid 3782); 14 May 2009 18:16:39 -0000 Original-Received: from acm.muc.de (pD9E23C92.dip.t-dialin.net [217.226.60.146]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 14 May 2009 20:16:36 +0200 Original-Received: (qmail 3626 invoked by uid 1000); 14 May 2009 18:17:12 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110875 Archived-At: On Thu, May 14, 2009 at 09:20:44AM -0700, David Reitter wrote: > On May 14, 2009, at 9:00 AM, Shaun Johnson wrote: > >Alfred M. Szmidt wrote: > >>Please make line-move-visual nil, it is totally uninutive to have the > >>point move to the same line, when you explicitly told it to move to > >>the next line. > >FWIW I completely agree, I find this behaviour bizarre in the extreme. > >I appreciate that others, coming from a different background, may find > >this behaviour intuitive but I don't see that as a reason to change > >such a core behaviour. > For people seeking to understand the reasons behind this default > choice at this late stage in the release process, it may be helpful to > review the discussions here about the new word-wrap (soft wrapping) > feature, where continued buffer lines comprise whole paragraphs in > text rather than just the occasional over-long line in code. Also, > consider the increased use of variable width fonts, which are standard > for non-code text in modern operating environments. I don't see anything bizarre and extreme about this change, but as a minor point I wish this change had been made by rebinding C-n to a [new?] command `next-visual-line'. It used to be that "line" meant the text between two \n's, and now its definition has become vague and mushy. I think I'm marginally in favour of C-n, C-p moving by screen lines, since the pain it causes old-timers (having to type C-n again) is less than the pain of navigating through buffers with long lines when C-n jumps over several screen lines. But yes, these new commands will cuase pain for people who use them in keyboard macros. These people will probably twig quite quickly what's amiss, and will be able to fix it at the cost of a throbbing headache. > On a more general note, I wonder why experienced users occasionally > resist change in the UI in general (as it breaks things) rather than > avoiding to upgrade. [linguistic point: "avoid" takes a noun or a gerund (which needn't be round), not an infinitive. You want "avoiding an upgrade" or "avoiding upgrading" here.] You're not trying to ignite another rambling heated debate about changing long standing features, are you? OK, thought not. Changing the UI makes the new version incompatible with the learning of the users of the old versions. Either they must relearn things, which is painful, or they must track down the options they need to unset to make it work how it used to, which is painful. This pain is a Bad Thing. Only if the new UI is stunningly good is the change justified. IMAO, the UI changes in Emacs 23 aren't justified. > Perhaps, providing bug fixes for previous branches (e.g., Emacs 22) for > a few years after the release of a new full version would mitigate > these issues. It's too much work at the moment. It might become feasible with bazaar. That's pure speculation by the way - I haven't tried bazaar out yet. -- Alan Mackenzie (Nuremberg, Germany).