line-move-visual
in [Lisp]
|
From: Stefan Monnier on 10 Jun 2010 09:43 > The thinking behind the line-move-visual decision went something like > this. If C-n moves by logical lines then the new users would be > confused. If it moves by visual lines then the experienced users would > be bothered. But we have a flag whereby experienced users can revert to > the old behavior. The new users won't know enough to set a flag. So, > let us go with the default that helps out the new users. See this > thread for example: Choosing defaults is very difficult indeed. You can never please everyone. In this specific case, I'm the main guy to blame: I wrote the original patch for line-move-visual (oddly enough, since it touches parts of the code I still am not at all familiar with), mostly because it seemed it would be important for proper support of word-wrap (which I didn't care for much, but many users cared about it). After writing the patch, I tried it out, mostly for debugging purposes, and much to my surprise I discovered that I actually liked it. Yes, it occasionally doesn't do what I want, but in practice, it does what I want more often than the previous case: - when no line wraps, it either makes no difference, or it works slightly better because it correctly accounts for variable-pitch fonts. - when lines are long (typically the "single-line paragraph" text coming from people who either use word-wrap or longlines-mode or an editor that behaves similarly, but can also happen in many other cases like binary files, or mechanically-generated files), the new behavior is much better (how did you move to "that spot I see about 10 visual-lines down from point" in a single logical line in previous Emacsen?). - when the buffer mostly fits without wrapping, except for a few exceptions, then yes, the new behavior is less good for those wrapped-lines. In my particular case, such lines are usually (very minor) bugs anyway, so it's not that important, but I understand that some people get annoyed. And of course, if you use C-100 C-n instead of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100 instead ;-), you'll be disappointed, and if you use keyboard macros you'll also be disappointed. Depending on your particular circumstances, the second case will only rarely happen whereas the third will be very common, so you'll be really annoyed. Sorry about that. Please (setq line-move-visual nil) in your .emacs and/or try to come up with some idea how we could keep the advantages in cases 1 and 2 without suffering in case 3. Stefan
From: Uday S Reddy on 10 Jun 2010 11:17 Stefan Monnier wrote: > Choosing defaults is very difficult indeed. You can never please > everyone. In this specific case, I'm the main guy to blame: I wrote the > original patch for line-move-visual (oddly enough, since it touches > parts of the code I still am not at all familiar with), mostly because > it seemed it would be important for proper support of word-wrap (which > I didn't care for much, but many users cared about it). Isn't word-wrap the ideal solution for dealing with the single-line paragraphs that you mention in the second bullet point below? > > Yes, it occasionally doesn't do what I want, but in practice, it does > what I want more often than the previous case: > - when no line wraps, it either makes no difference, or it works > slightly better because it correctly accounts for > variable-pitch fonts. > - when lines are long (typically the "single-line paragraph" text coming > from people who either use word-wrap or longlines-mode or an editor > that behaves similarly, but can also happen in many other cases like > binary files, or mechanically-generated files), the new behavior is > much better (how did you move to "that spot I see about 10 > visual-lines down from point" in a single logical line in > previous Emacsen?). > - when the buffer mostly fits without wrapping, except for a few > exceptions, then yes, the new behavior is less good for those > wrapped-lines. In my particular case, such lines are usually (very > minor) bugs anyway, so it's not that important, but I understand that > some people get annoyed. And of course, if you use C-100 C-n instead > of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100 > instead ;-), you'll be disappointed, and if you use keyboard macros > you'll also be disappointed. > > Depending on your particular circumstances, the second case will only > rarely happen whereas the third will be very common, so you'll be > really annoyed. Sorry about that. Please (setq line-move-visual nil) > in your .emacs and/or try to come up with some idea how we could keep > the advantages in cases 1 and 2 without suffering in case 3. If line-move-visual is nil by default, the users that care about 1 and 2 can set it to t, can't they? It is the same issue from the other side of the fence. They don't need the default set in a particular way to get their behaviour. Moreover, the people dealing with single-line paragraphs (me being one of them) will normally use visual-line-mode, which does visual line motion anyway. So, they are not affected by the default at all. So, this particular decision doesn't seem to be all that difficult. Cheers, Uday
From: despen on 10 Jun 2010 11:44 Stefan Monnier <monnier(a)iro.umontreal.ca> writes: >> The thinking behind the line-move-visual decision went something like >> this. If C-n moves by logical lines then the new users would be >> confused. If it moves by visual lines then the experienced users would >> be bothered. But we have a flag whereby experienced users can revert to >> the old behavior. The new users won't know enough to set a flag. So, >> let us go with the default that helps out the new users. See this >> thread for example: > > Choosing defaults is very difficult indeed. You can never please > everyone. In this specific case, I'm the main guy to blame: Good, then I have something to contribute to this thread. Nice work and I support the idea of making this a default. For me, it was easy to spot the new behavior, and I assumed I would find a description and override in the NEWS file. So far I've found no reason to do so. I hope the complainers get a full refund of all the money they paid for your hard work and nothing else.
From: Richard Kettlewell on 10 Jun 2010 12:24 Stefan Monnier <monnier(a)iro.umontreal.ca> writes: > Depending on your particular circumstances, the second case will only > rarely happen whereas the third will be very common, so you'll be > really annoyed. Sorry about that. Please (setq line-move-visual nil) > in your .emacs and/or try to come up with some idea how we could keep > the advantages in cases 1 and 2 without suffering in case 3. Perhaps an 'auto' setting where the behavior depended on the buffer mode? For instance equivalent to 'nil' in programming language modes and to 't' in text editing modes. -- http://www.greenend.org.uk/rjk/
From: Mark Crispin on 10 Jun 2010 12:57
On Thu, 10 Jun 2010, Uday S Reddy posted: > A third suggestion is that we should start thinking of Emacs as > mission-critical software. It amazes me that anyone would think otherwise. > It is really platform on which a > number of critical services are delivered, for development of projects > or for running of teams and organizations. A lot rides on it and any > changes that potentially cause corruption of files or data can be quite > serious. As the kids say, "well, duh!" This discussion is rapidly leading to "is free software suitable as mission-critical software?". Some people would be more comfortable is the answer is "no". Then they don't have to deal with the responsibility of mission-critical software. > Finally, and I might be a bit OTT here, I think we should think of free > software as community-owned software. It is not developer-owned > software (despite the aberration caused by the existence of FSF as a > copyright-owner). The notion of "community-owned software" works as ideology, but not as reality. If emacs was really community-owned software, I as a community member could revert the change in the official distribution sources. And then there could be revert wars ala Wikipedia. That existed once upon a time in the mid-1970s, at MIT (the ITS systems) and elsewhere. It didn't end well. The dichotomy between "the cathedral and the bazaar" that ESR postulated doesn't really exist. The full-fledged bazaar option doesn't scale and never actually happened. It's just two types of cathedrals, one run by a pope and the other run by a board of laymen. But even the laymen become power-corrupted. > Free software isn't > "free-to-fork" software, even though the right to fork exists as a last > resort and as a foundation for everything else. If that right needs to > be exercised, it is a signal that the community-ownership of the > software has broken down and that is not good for any of us. That is certainly true. Again, BSD serves as an example. Another sign of a process breakdown is when a developer's answer to user complaints about changes in a new version is "so just run the old version". The need to revert to an old version means that the new version is broken. The corrolary to this is that the standard developer's answer to complaints about bugs in an old version is "upgrade to the new version". This only works if the upgrade is a viable option. Developers can't have it both ways. If they create a new version that is unacceptable to some portion of the user community, they they have effectively forked the software. Responsible developers figure this out after a while. It takes maturity. Generally, they want their users to be using one, and only one, version; and they do what is necessary to ensure that there are no barriers to upgrade. Since user interface surprise is a barrier to upgrade, they make sure there aren't any such surprises. In the real world, people get fired for inflicting surprises in mission-critical software. -- 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. |