line-move-visual
in [Lisp]
|
From: David Kastrup on 6 Jun 2010 05:39 Uday S Reddy <uDOTsDOTreddy(a)cs.bham.ac.uk> writes: > Coupled with these real technical issues, there are the attitudinal > problems of holier-than-thou, smarter-than-thou and modern-than-thou > and what have you. Everybody is free to join the discussions on the Emacs developer lists. Those who choose not to help with the work don't get to criticize the results. A common democratic principle. > In another part of this thread, we have also seen the astonishing idea > that the developers don't have to care about what the users > want/need. If that is the attitude that open source developers take, > then I will be the first to give up open source! An excellent idea. The Free Software Foundation cares principally about free software, not open source. Open source sports the notion of creating superior software by significantly different processes than common. Free software is based on the premise of empowering the recipient of software to change and adapting it according to his own needs. Pampering to the needs of users who are not interested in changing and adapting the software according to their needs is not a major priority. Feel free to fork any free software which does not behave like you want it: you have the power. You are not dependent on upstream developers. If you tie yourself to distribution channels that take this power from you effectively, you are doing it by choice. If you think you are in a suitable majority, tell your distribution channel to change the upstream decision for you if you don't feel like discussing this in a civilized manner on the developer discussion lists created for that purpose. -- David Kastrup
From: Uday S Reddy on 6 Jun 2010 09:55 On 6/6/2010 10:39 AM, David Kastrup wrote: > Free software is based on the premise of empowering the recipient of > software to change and adapting it according to his own needs. > > Pampering to the needs of users who are not interested in changing and > adapting the software according to their needs is not a major priority. > > Feel free to fork any free software which does not behave like you want > it: you have the power. You are not dependent on upstream developers. Good point. But not all users have the time or the ability to do their own changing or forking or even significant customization. Allowing the *possibility* of users to change things is not the same as *expecting* them to change things. 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. (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!) 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. 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. Cheers, Uday
From: Tassilo Horn on 6 Jun 2010 11:21 Uday S Reddy <uDOTsDOTreddy(a)cs.bham.ac.uk> writes: Hi Uday, > 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. IMO, the first thing a new emacs user should learn is using the help facilities. So after seeing that `C-n' moved point not to the next (logical) line as it always did should be a reflexive `C-h C-n': ,----[ C-h k C-n ] | C-n runs the command next-line, which is an interactive compiled Lisp function | in `simple.el'. | | It is bound to C-n, <down>. | | (next-line &optional ARG TRY-VSCROLL) | | Move cursor vertically down ARG lines. | [...] | If the variable `line-move-visual' is non-nil, this command moves | by display lines. Otherwise, it moves by buffer lines, without | taking variable-width characters or continued lines into account. | [...] | | If you are thinking of using this in a Lisp program, consider | using `forward-line' instead. It is usually easier to use | and more reliable (no dependence on goal column, etc.). `---- > (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!) As you can see in the docs above, `next-line' wasn't the right function to call from lisp even before visual line movement. > 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. I agree with all of that. Bye, Tassilo
From: Mark Crispin on 6 Jun 2010 13:24 On Sun, 6 Jun 2010, Uday S Reddy posted: > In the megabytes of debate that has gone on on this issue, I haven't seen a > single point mentioned as to why it should move by visual line in the logical > line mode. Yet, that is the default in Emacs 23! Worse, it *changes* the > semantics of C-n which as, Mark Crispin points out, has been here the 70's. And breaks key macros. > So, there are three things that an old-timer is annoyed about: > 1. Change of established semantics. > 2. Inconsistency. > 3. Pointlessness. 4. Breaking long-standing key macros and procedures, which in turn leads to file corruption based upon the current screen width (= "random and unpredictable"). > Coupled with these real technical issues, there are the attitudinal problems > of holier-than-thou, smarter-than-thou and modern-than-thou and what have > you. It seems to be a common problem among some Gen-X types. John Xenakis (a colorful character if ever there was one!) writes a good essay related to the topic: http://www.generationaldynamics.com/cgi-bin/D.PL?d=ww2010.i.java080701 > In another part of this thread, we have also seen the astonishing idea > that the developers don't have to care about what the users want/need. If > that is the attitude that open source developers take, then I will be the > first to give up open source! This attitude has always been a problem, but in the past it would be corrected. In a lab where everybody was under one roof, the users would gang up (often with the lead developer) and discipline the offending young developer. Today, the only recourse is to spawn a fork. The problem is that each fork erodes the credibility of open source. The classic example is BSD, which committed suicide by fork. -- 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.
From: Mark Crispin on 6 Jun 2010 14:17
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. |