From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: line-move-visual Date: Wed, 16 Jun 2010 19:29:41 +1000 Organization: Unlimited download news at news.astraweb.com Message-ID: <87ocfb2um2.fsf@rapttech.com.au> References: <2a7dc148-e2cc-4681-9d8c-ccd1140aa6d7@j36g2000prj.googlegroups.com> <089883ee-0a63-4cb4-a0ec-d2fe4e71cc03@y18g2000prn.googlegroups.com> <87wruco5yq.fsf@lola.goethe.zz> <87wrubfd8p.fsf@rapttech.com.au> <848w6ndwn0.fsf@cs.bham.ac.uk> <87y6ekevet.fsf@rapttech.com.au> <87bpbgq32f.fsf@unm.edu> <87hbl857xp.fsf@kzsu.stanford.edu> <87pqzvd7yx.fsf@rapttech.com.au> <87d3vuo2zv.fsf@rapttech.com.au> <87d3vs4ppr.fsf@rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1291835793 32629 80.91.229.12 (8 Dec 2010 19:16:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 19:16:33 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 08 20:16:29 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQPV6-00043U-ET for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 20:16:29 +0100 Original-Received: from localhost ([127.0.0.1]:54854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQPV5-0002c3-Em for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 14:16:27 -0500 Original-Path: usenet.stanford.edu!news-xfer.nntp.sonic.net!news.astraweb.com!border1.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:6p+u7RhoGQQZHNUGU3Equ3+VcME= Original-Lines: 93 Original-NNTP-Posting-Host: 638a5946.news.astraweb.com Original-X-Trace: DXC=A\:Mn6nB<2h1m]JSMD?cjjL?0kYOcDh@ji=VFiPm?<[eE^ZA\hJ`SIlK\<3KT5N\]ee_A3@kGf@?i Original-Xref: usenet.stanford.edu gnu.emacs.help:178998 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:75868 Archived-At: Uday S Reddy writes: > On 6/15/2010 10:20 AM, Tim X wrote: > >> I still don't understand the question you referred to when you wrote >> >> "When I asked "do you want C-n to move by logical line or visual line in >> the logical line mode", the gallery has been silent." >> >> Perhaps I don't understand what you mean by logical line mode. My >> interpretation was that logical line mode referred to what some would >> call the 'traditional' default mode that emacs had until v23 i.e. C-n and Cp >> moved to the next and previous lines where a line would be defined by >> standard eol characters. > > By "logical line mode," I meant the state of Emacs whenever visual-line-mode > is nil. When you fire up Emacs with 'emacs -Q', it is in this mode. This is > not standard terminology. It is something I made up to describe the situation > we expect to have when Emacs is not in visual-line-mode. > I think I understand what you mean now, but I still think your over complicating it somewhat. Forget about visual-line-mode. This is just confusing the situation. What you have is a logical line mode i.e. line-move-visual = nil and a visual line mode i.e. line-move-visual = t. The emacs mode called visual-line-mode is just the latter with a few enhancements, such as word wrap and the ability to have the previous 'state' restored when you turn it off. So, by default, emacs 23.1 starts in visual line mode. If you want it to start in logical line mode, you set line-move-visual to t and you have exactly the same behavior you had before. > By your terminology, "logical line mode" existed in Emacs 22, but it doesn't > exist in Emacs 23. No, it still exists, it just isn't the default. > When you fire up 'emacs -Q' you get some kind of an "emacs > default mode with a funny mixture of logical and visual lines". Where do you get the funny mix? Either line-move-visual is the default of t and you have movement by visual lines or it has been set to nil and you have the same logical line movement that you always had. > From this point of view, the problem is more simply stated: the Emacs > default is not logical line mode any more. Correct. Nobody has claimed otherwise. > > Perhaps my more important point is that, if we intend for Emacs to continue as > a dependable system component (as opposed to a personal text editor), these > kinds of incompatible changes should not be made. > If we had more than one contentious example, I might agree. However, the reality is that emacs has been improving and evolving considerably and remains incredibly stable. For the last 5 years or so, I've been running from the latest development sources and have yet to encounter anything other than minor trivial issues. Considering this has included quite substantial updates to core elements, such as GUI interface libraries, font rendering, character encoding etc. I think the maintainers have done an excellent job. Given that you agree the addition of the ability to move by visual lines is a good one and that possible issues exist, its worth noting that such issues would exist whether the change was made the default or not. Personally, I would have been more conservative and not made it the default initially. My preference would have been to make it an option and then, in a later release, if it turned out that having it as a default was justified, change it then. At the very least, this would somewhat rreduce possible negative impact as we would have understood the real impact and scope of issues better and maintainers would have had time to fix any issues (though there may be an arguement that developers wouldn't do anything until forced - I frequently see packages that still throw warnings for functions and variables that have been deprecated for years which never seem to get 'fixed' despite the release of new versions). However, that is all academic now. We have what we have and will have to wait and see to what extent it actually does cause all the issues that have been suggested. The bottom line is that there isn't a way to make this sort of development such that it is painless for everyone. Tim -- tcross (at) rapttech dot com dot au