From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Crispin Newsgroups: gmane.emacs.help Subject: Re: line-move-visual Date: Sun, 6 Jun 2010 11:17:19 -0700 Message-ID: References: <87pr07qjio.fsf@thinkpad.tsdh.de> <878w6vq7ew.fsf@thinkpad.tsdh.de> <871vcmhq79.fsf@wivenhoe.ul.ie> <580d5f23-e251-483f-9752-7e77b1ca2fb7@40g2000pry.googlegroups.com> <2a7dc148-e2cc-4681-9d8c-ccd1140aa6d7@j36g2000prj.googlegroups.com> <089883ee-0a63-4cb4-a0ec-d2fe4e71cc03@y18g2000prn.googlegroups.com> <87wruco5yq.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Trace: dough.gmane.org 1291943817 1064 80.91.229.12 (10 Dec 2010 01:16:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Dec 2010 01:16:57 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Dec 10 02:16:51 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 1PQrbM-0004Yp-QB for geh-help-gnu-emacs@m.gmane.org; Fri, 10 Dec 2010 02:16:49 +0100 Original-Received: from localhost ([127.0.0.1]:49305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQrbM-0008OB-46 for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Dec 2010 20:16:48 -0500 Original-Path: usenet.stanford.edu!postnews.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.isomediainc!news.posted.isomediainc.POSTED!not-for-mail Original-NNTP-Posting-Date: Sun, 06 Jun 2010 13:17:21 -0500 Original-Newsgroups: gnu.emacs.help,comp.emacs,comp.lang.lisp In-Reply-To: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) Original-Lines: 85 X-Usenet-Provider: http://www.giganews.com Original-NNTP-Posting-Host: 206.124.149.116 Original-X-Trace: sv3-5K5g9VhAl8bOkaumb5G2K9liXegur9Jeu1uoBxUvOK+2EKiQQs7+7abUvXdWnkUGIRiXl/DjgAXBV5l!UY+54Rptm15WLFtBr96jo5SPYgDB0imIih5oxUPPVKR70IJZsCTJ4yFzNAfrzE0/xaHwrcPsHQQT!ST1rfXwU34yvU/nE5zU5BBvb+2hpmxk= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Original-Xref: usenet.stanford.edu gnu.emacs.help:178692 comp.emacs:99931 comp.lang.lisp:288754 X-Mailman-Approved-At: Thu, 09 Dec 2010 20:09:15 -0500 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:77116 Archived-At: On Sun, 6 Jun 2010, Uday S Reddy posted: > In this particular instance, the customization needed is not a big deal: set > line-move-visual to nil. Almost everybody can do it. But the time they had > to spend in discovering that they needed to change it is what has been > significant. An additional significant burden is the need to update .emacs files on dozens of machines in order to keep common functionality. There is a huge scalability problem. There are things that you can do to avoid 2^n synchronization, such as designating one system as having the "master" copy from which all others are updated. But then, each time you encounter a problem on a "slave" that necessitates a change to the slave, you must: [1] make the corresponding change to the master [2] test on the master [3] test on at least one other slave [4] push the update from the master to all other slaves The fun and laughter proceeds apace if you don't have access to the master at that point of time. Then you have to make a note that you needed this change, and subsequently find that note when you can get to the master again. And all this presumes that it's a set that is harmless in old versions. The true joy comes in when the change has an unintended bad effect in some other slave and you didn't catch it in step [3]. The best case wastes a great deal of time, repeated for each affected user. The worst case is a nightmare. Part of the maturing process is learning to recognize when a simple cookbook solution is neither simple nor cookbook nor solution. > (In fact, after this thread started, I began to wonder if VM > might be vulnerable to the problem as well, and went and checked if there > were calls to next-line anywhere. There were three of them!) I hope that you didn't have any corrupted files as a result. > It is not for nothing that we have ideas like standards and > backward-compatibility. It didn't seem to me that the discussion on the > developers list showed much appreciation to these issues, despite them having > been raised repeatedly. A clueless developer is a very bad thing. > By the way, I think that the Emacs 23 visual-line-mode and word wrapping are > a great addition to Emacs. A civilized way of dealing with longlines has > long been needed. But the default setting of line-move-visual is an > independent issue to that. Let me be clear; I have no objection whatsoever to the feature having been added and made available. The issue is it having been made the default, particularly in modes where it is pointless. It is also important to realize that there are many editors that handle long lines in a "civilized" way. However, in certain circumstances, it is desirable and necessary to handle long lines the "uncivilized" way; and it is a feature of emacs that it can do that. No amount of raving about how the "civilized" way is better will change those circumstances. The only effect of enforcing the "civilized" way is to render emacs unsuitable for those applications. For example, I have a scripted procedure which depends upon emacs' "uncivilized" behavior. It is followed by individuals who never use emacs for any other reason. I have no control over what version they use, but that had always been alright since every program that ever called itself emacs worked the same way with it. Until now. I don't know what I'm going to about that procedure. I'm probably going to have to write a program and/or a sed script to replace it. This is unfortunate, since an advantage of the emacs method was that the user could see what the procedure was doing. All because of clueless developers who broke emacs in version 23. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.