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: Mon, 25 May 2009 01:35:11 -0700 Message-ID: <0170C133E8C140949037898E0F3A6C83@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> <2A3A0621C3974D8A8BD4F58FFD63C61D@us.oracle.com> <04DBCF84-74AA-4349-A891-9961E3F2779E@gmail.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 1243240547 30543 80.91.229.12 (25 May 2009 08:35:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 May 2009 08:35:47 +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 10:35:39 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 1M8Veg-0005bC-Hr for ged-emacs-devel@m.gmane.org; Mon, 25 May 2009 10:35:34 +0200 Original-Received: from localhost ([127.0.0.1]:38569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8Vef-00017z-Jc for ged-emacs-devel@m.gmane.org; Mon, 25 May 2009 04:35:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M8VeD-00012q-3I for emacs-devel@gnu.org; Mon, 25 May 2009 04:35:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M8Ve9-000120-0s for emacs-devel@gnu.org; Mon, 25 May 2009 04:35:04 -0400 Original-Received: from [199.232.76.173] (port=49282 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M8Ve8-00011s-M3 for emacs-devel@gnu.org; Mon, 25 May 2009 04:35:00 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:26190) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M8Ve7-0003Xy-Fd for emacs-devel@gnu.org; Mon, 25 May 2009 04:35:00 -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 n4P8YcE5031496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 May 2009 08:34:40 GMT Original-Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4P8Zd0q030156; Mon, 25 May 2009 08:35:39 GMT Original-Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 May 2009 01:34:52 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <04DBCF84-74AA-4349-A891-9961E3F2779E@gmail.com> Thread-Index: Acnc4QNtKTolkiOPRbK+7d5jcn656wAMJPKw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A01020A.4A1A582D.0098: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:111073 Archived-At: > > 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. > > Much of my stuff is actually done in variable-width fonts (LaTeX > editing, for instance). Sure, I can see that. Sometimes (or some parts of) LaTeX, HTML, and XML, depending on the code. Yes. (Troff, probably not. ;-)) > Using fixed-width fonts even for code is not a must No one said it is a must. This is about finding appropriate default values. It's not about forcing someone to use one or the other behavior. The point is that it makes sense for the defaults to be different, depending on the buffer type. Then users should be able to (easily) customize the values for different buffer types. > >> 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 know fairly well by now how a lot of the developers (and > certainly a share of the users) work. And as RMS pointed out in a > related thread some time ago, much of the GNU tool set is based > on line-by-line processing. Yessir. > > Why would you even want non-visual movement? ;-) What's the > > use case/reason? Let me guess... code? formatted buffers? > > most Emacs buffers? > > Yes, code and formatted buffers. But even there I wouldn't want it > all the time - just in some situations. Precisely. It all depends. On the buffer type. On personal preference. On the moon, perhaps. Customization is there for personal preference, but it needs to be easily tweakable for different contexts, as you point out. One size here does not necessarily fit all contexts. The _default_ behaviors should at least be tailored to a reasonable consensus according to the buffer type. I suspect there might be consensus for a nil default for code buffers. But that doesn't that mean some people won't want non-nil there too, just as some people (as you suggested) might prefer proportional fonts for code too. > I believe that Auto-fill is a thing of the past. The new > word-wrap is the way to go for non-code. Here's why: > > > When you read this plain-text mail, it will have had newlines > > inserted (for better or, more likely, for worse), > > For worse, because the text only occupies 50% of the window I use to > display your message. Yes, for worse, I already agreed. But that's what happens with plain-text mail, isn't it? Many of us use HTML mail outside of mailing lists. But I can tell you that I sometimes wish I had a line-oriented mode for dealing more easily with blocks of code or tabular text in HTML emails. The most I can do using Outlook is switch to a fixed-width font. (Yes, I know, Emacs as mail client...)