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, 1 Jun 2009 14:00:34 -0700 Message-ID: <31703F2EAE7D4CAF8E671B0C18916D01@us.oracle.com> References: <87eiue83i7.fsf@cyd.mit.edu><87my92dmdt.fsf@cyd.mit.edu><87eiudewtq.fsf@uwakimon.sk.tsukuba.ac.jp> <831vqdubqy.fsf@gnu.org><6161f3180905270548t3012bc1ah161719ae01db0fb5@mail.gmail.com><5f0ff9220906010736paad9321td86fd52326ebe722@mail.gmail.com><87oct7sur8.fsf@cyd.mit.edu> 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 1243890132 10185 80.91.229.12 (1 Jun 2009 21:02:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2009 21:02:12 +0000 (UTC) Cc: 3438@emacsbugs.donarmstrong.com, "'T.V. Raman'" , 'Chong Yidong' , "'Andrew W. Nosenko'" , emacs-devel@gnu.org, 'ishikawa' , ams@gnu.org, stephen@xemacs.org, eliz@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 01 23:02:06 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 1MBEdr-0003cu-NL for ged-emacs-devel@m.gmane.org; Mon, 01 Jun 2009 23:02:00 +0200 Original-Received: from localhost ([127.0.0.1]:41614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBEdo-0007fQ-GY for ged-emacs-devel@m.gmane.org; Mon, 01 Jun 2009 17:01:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBEcl-0007QE-GV for emacs-devel@gnu.org; Mon, 01 Jun 2009 17:00:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBEcg-0007Ny-Q0 for emacs-devel@gnu.org; Mon, 01 Jun 2009 17:00:51 -0400 Original-Received: from [199.232.76.173] (port=52604 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBEcg-0007Nu-Jy for emacs-devel@gnu.org; Mon, 01 Jun 2009 17:00:46 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:21495) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MBEcb-0007g1-Dg; Mon, 01 Jun 2009 17:00:41 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n51L14Nv009280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Jun 2009 21:01:07 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 n51L1F40031688; Mon, 1 Jun 2009 21:01:16 GMT Original-Received: from dradamslap1 (/141.144.65.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2009 14:00:18 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acni9TfuB/1/jwFYT6CPhCw/kKgzPAAAvN2Q X-Source-IP: abhmt003.oracle.com [141.146.116.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010204.4A244164.00B6: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:111263 Archived-At: > > More typically (in formatted buffers), we want to reflect > > the use of newlines (they are positioned intentionally) > > and maintain the current column for line movement, but > > there is no single, privileged column (e.g. file name) > > that we want to constrain point to, as there is in Dired. > > I don't know if it's typical, but for most of those kinds of > buffers you describe as "formatted", I think they should at > least set truncate-lines. No reason given. Why? Why should Buffer List or Info or Man output or grep output or C code or Java code buffers have `truncate-lines' turned on? Because newlines are intentionally positioned in such modes, they should use `truncate-lines'? Why would that be? Is this a diversion to some other topic? What's the relation to the topic at hand, which is `line-move-visual'? > > Each formatted buffer could individually define its own > > line-movement commands, which amounts to just binding > > `line-move-visual' to nil around a call to `next-line'. > > But that would be a bit silly. Better to just let the > > variable be buffer-local. And provide nil as > > the default value for most formatted buffers. > > Any major mode is free to (set (make-local-variable > 'line-move-visual) nil). For those modes that come with Emacs, it is the Emacs code that would need to do that. It doesn't happen by spontaneous combustion. I proposed making the variable always buffer-local. If you don't want to do that, then yes, each mode for which nil is appropriate would need to do that. Or the opposite: Switch the default to nil, and let the (relatively fewer?) modes that use primarily free-form text do (set (make-local-variable 'line-move-visual) t). > As of now, I don't think any mode bothers to do that. Of course not. Nothing has been done yet about this issue. That's what the discussion is about: tailoring `line-move-visual' so that it DTRT. Which means turn itself off, by default, for non free-text modes, that is, code modes and modes with formatted text. IMHO. > > BTW, you didn't answer the questions about the poll. > > How's it coming along? Where is it? > > I can't think of any poll which would bring any satisfactory answer to > the discussion. "Let them eat cake!" (Or as the right-wing French government official said back in the day, speaking of the Nouvelle Caledonian independentistes, "Ever since we stopped listening to them, we don't hear anything from them anymore.") Poll, what poll?