From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: please make line-move-visual nil Date: Sun, 24 May 2009 17:52:06 -0700 Message-ID: <2A3A0621C3974D8A8BD4F58FFD63C61D@us.oracle.com> References: <23521879.post@talk.nabble.com><7b501d5c0905131659r1d79ec56s5a59f76e4713edf9@mail.gmail.com><23532135.post@talk.nabble.com> <87tz3odq3l.fsf@iki.fi><23538683.post@talk.nabble.com> <87eiuru24b.fsf@iki.fi><39370.130.55.118.19.1242397867.squirrel@webmail.lanl.gov> <48914.130.55.118.19.1242592120.squirrel@webmail.lanl.gov> <66C6BA04EBCF4B6DAED69E851627D852@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1243212738 8469 80.91.229.12 (25 May 2009 00:52:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 May 2009 00:52:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'David Reitter'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 25 02:52:10 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 1M8OQD-0002os-Ph for ged-emacs-devel@m.gmane.org; Mon, 25 May 2009 02:52:10 +0200 Original-Received: from localhost ([127.0.0.1]:53040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8OQC-0002Jt-TS for ged-emacs-devel@m.gmane.org; Sun, 24 May 2009 20:52:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M8OQ5-0002II-RN for emacs-devel@gnu.org; Sun, 24 May 2009 20:52:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M8OQ0-0002Eg-N5 for emacs-devel@gnu.org; Sun, 24 May 2009 20:52:01 -0400 Original-Received: from [199.232.76.173] (port=52805 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8OQ0-0002Ed-HR for emacs-devel@gnu.org; Sun, 24 May 2009 20:51:56 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:41729) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M8OPz-0007Gs-VG for emacs-devel@gnu.org; Sun, 24 May 2009 20:51:56 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4P0pZCK013327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 May 2009 00:51:36 GMT Original-Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4P0qZ92032595; Mon, 25 May 2009 00:52:35 GMT Original-Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 24 May 2009 17:51:49 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcncyvUTQ85G6QLASyO7sM4HzfM7CAAAWU5w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.4A19EBA5.014A:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:111051 Archived-At: > > If you absolutely feel the need to make the default value be t for > > modes such as text-mode, which (you are convinced) are likely to > > benefit from it, then do so. But PLEASE leave the rest of Emacs > > alone, by default. This is a bad choice for > > Emacs - please reconsider this. > > You didn't give any reason to support your view. I did too, though perhaps not explicitly enough. Most buffers in Emacs are code buffers or formatted text, with non-proportional fonts and hard-returns (newlines) as line separators. For _at least_ those contexts, we should keep the normal behavior. The traditional line movement fits well with lines as they are defined in those contexts. Lines defined by newlines fit well with newline-oriented movement. If a poll indicates that most people want to use the new behavior for buffers such as text-mode, then the default can be non-nil for such buffers. I don't have a problem with that. But my crystal ball says that those buffers are in the minority, in Emacs. And even if they were in the majority, it wouldn't make sense to impose non-nil for the other buffers, which have newline-delineated lines and provide a good fit for the traditional line movement. This is a widespread change, and it should not be. Impose the change, if you must impose it, on only text-oriented buffers - the kind of buffers for which you might use a proportional font, for instance. (Yes, the two things are different, but the use cases overlap considerably.) Use it for mail messages and text-mode. Do not use it, by default, for code and formatted buffers, whose content is split into newline-delineated lines by design. > I can see where you're coming from, though. Even though you didn't notice the reasons I gave? ;-) Good. Maybe you sense the reasons yourself? > I believe line-move-visual should be t because in this mode of > operation, cursor movement commands correspond most closely to the > visual representation of the buffer. Visual representation is not all that is important in a buffer. In code and formatted (e.g. tabular) text, the positions of hard newlines can make a difference. Look, GNU Emacs Dev itself demands that Emacs-Lisp code you submit not have lines longer than N columns. Why? Why do we format Info and *Help* and *Man* and *Dired* buffers? Shouldn't you be proposing that we do away with all that, and just have lines that are a zillion chars long? Let the display take care of it all, right? That's a different discussion, perhaps, but I sense that the door is being opened here... > Note that I have bound C-n/p to non-visual movement in Aquamacs, > while arrow keys are visual. Why would you even want non-visual movement? ;-) What's the use case/reason? Let me guess... code? formatted buffers? most Emacs buffers? > How about a newbie-mode, which can be en/disabled directly from the > startup screen? I don't think this is about newbies at all (except that some Emacs developers might be hoping that many newbies will be likely to use mainly Emacs for text, mail, etc.). I think it is about different line movements being appropriate for different kinds of "line". The solution, in terms of finding good default behavior, is to do this based on the buffer, that is, on its mode. Use newline-oriented line movement for buffers where "lines" are typically delineated by newlines. Use, if you like, visual-line-oriented movement for buffers where "lines" have no use for newlines. When I write a paragraph in this mail client (Outlook), there is no auto-fill or anything that chops the text by inserting newlines. Visual line movement might be appropriate here (and that's in fact the line movement I have). When you read this plain-text mail, it will have had newlines inserted (for better or, more likely, for worse), and newline-oriented line movement might be appropriate. If I instead sent the mail as HTML, then visual line movement might be appropriate. > Ps.: I think it's too late in the game for 23.1 for this sort > of change. Dunno if it's too late, but if time is really an argument here, then we can argue that this change of default came too late. But I think it doesn't really matter when we have the discussion. ;-)