From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: line-move-visual Date: Sun, 13 Jun 2010 20:56:30 +0000 (UTC) Organization: muc.de e.V. Message-ID: References: <089883ee-0a63-4cb4-a0ec-d2fe4e71cc03@y18g2000prn.googlegroups.com> <87wruco5yq.fsf@lola.goethe.zz> <87wrubfd8p.fsf@rapttech.com.au> <848w6ndwn0.fsf@cs.bham.ac.uk> <87d3vx5cku.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1291834698 26554 80.91.229.12 (8 Dec 2010 18:58:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 18:58:18 +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 19:58:14 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 1PQPDS-0002PH-5c for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 19:58:14 +0100 Original-Received: from localhost ([127.0.0.1]:34047 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQPDR-00019t-FU for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 13:58:13 -0500 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!kanaga.switch.ch!switch.ch!news.belwue.de!news.tu-darmstadt.de!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help,comp.emacs,comp.lang.lisp Original-Lines: 96 Original-NNTP-Posting-Host: marvin.muc.de Original-X-Trace: colin2.muc.de 1276462590 28420 2001:608:1000::2 (13 Jun 2010 20:56:30 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: Sun, 13 Jun 2010 20:56:30 +0000 (UTC) User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Original-Xref: usenet.stanford.edu gnu.emacs.help:178907 comp.emacs:100014 comp.lang.lisp:289055 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:75839 Archived-At: In comp.emacs Mark Crispin wrote: > On Sat, 12 Jun 2010, Wojciech Meyer posted: >> Well it is certainly possible, one can use mailing list and the NEWS >> file, which was suggested before. > Please read the first chapter of the Hitchhiker's Guide to the Galaxy to > understand the flaw in that reasoning. Please feel free to suggest a way the development team could have canvassed users, particularly the vast majority who don't keep up with project mailing lists. It seems like a difficult problem. > Apparently not, if the "customers" are told that it's their fault for > not being on the development list. It seems like a difficult problem. >> What kind of Emacs users are they? Isn't possible to place on every >> machine a stub containing: (setq line-move-visual nil). > There include people who never use emacs, except to follow the procedure > that I outline (which is literally a cookbook "do these steps exactly"). > I have no control or access to the machines in question. > Perhaps I should have written a program to begin with. But it was so much > simpler to leverage upon emacs back in the days when emacs had a reliable > interface. Now that it no longer does, I'm now forced to write the > program. It seems you're exaggerating your predicament ever so slightly. I'd guess you could code up the replacement program (in elisp? in sed? in whatever?) in less time than you've spent discussing the problem here. It's far from obvious that this change (line-visual-mode being set) is a Bad Thing. Without it, moving around things like log files with 300 character lines was an utter pain. I'd suggest it was more of a pain than the one you're suffering, because it hit users using Emacs in its principal way of working, rather than in special cases in some obscure feature (keyboard macros). since Emacs 23, I haven't felt any need whatsoever to restore l-v-m to nil, and I haven't seen anybody else asking for it. >> There is nothing wrong in being young and creative, that makes often >> things better. Young people often do care more about things then >> Senior Architects, they are also more flexible for changes. > Yes, but they lack the wisdom and experience of their elders. This in > turn leads them to address complex problems with simple solutions that > backfire (sometimes disastrously). Hence the best team for writing something contains both stuck-in-the-groove maturity and feckless youth. Not that the Emacs team is lacking in solid wisdom. >> The reason why this setting wasn't kept by default is to fix the >> fundamental problem, > Yeah, right. The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N, > CTRL/P, etc. moved to predictable places in the file no matter what the > screen width, and thus could be relied upon for a cookbook procedure. Now you've got to take screen width into account. Big deal. And it was dashed near impossible to move easily to the middle of long, long lines. I suspect this need to be commoner than using keyboard macros on long lines. > We can't have predictability and reliability. We have to do > pretty-pretty to be just like Word, and destroy the one attribute that > made emacs superior to other choices. You're exaggerating at least a little bit here. There are lots and lots of attributes that make Emacs superior, some of them in contention with some others. You could easily enough amend your instructions, prefixing them with "M-: (setq visual-line-mode nil)". Or you could rewrite the thing (what does it do, exactly?) in elisp or whatever. > Bletch. > This wouldn't have been a problem had the arrow keys been changed to > the new semantics and CTRL-A/E/N/P been left alone. The new semantics > are even arguably right for arrow keys (although I would go further and > say that they should also treat tabs as the equivalent number of > spaces). It isn't as if we're still in the 1970s and have keyboards > without arrow keys. The arrow keys are a long way away from the home position on the keyboard. You're surely not suggesting rebinding those four key sequences to something else? > -- Mark -- -- Alan Mackenzie (Nuremberg, Germany).