line-move-visual
in [Lisp]
|
From: Wojciech Meyer on 11 Jun 2010 20:17 Mark Crispin <mrc(a)panda.com> writes: > On Thu, 10 Jun 2010, Uday S Reddy posted: >> By community ownership, I only mean that all the people that have a >> stake in the system have a voice in the matter and we all feel >> ownership of the system. When the community is divided, as seems to >> be the case on this issue, the developers have to make a decision >> and move on. Well it is certainly possible, one can use mailing list and the NEWS file, which was suggested before. > This sort of thing happened in the past as well. The difference was > that there was accountability in the past that is absent today. What sort of acountability, I think unhappy `customers' is enough punishment. > I have a new task on my list: replace emacs in the procedures for my > target audience since emacs is no longer suitable for that purpose. I > simply can not tell these users "make sure that you set > line-move-visual to nil"; they would have no clue what that means. > More likely than not, I will end up being obliged to write a program > for the task; and there will be one less way those users will be > exposed to emacs. What kind of Emacs users are they? Isn't possible to place on every machine a stub containing: (setq line-move-visual nil). > > One of the advantages of the "software tools" mindset of the past was > that you did not have to write a program for every task. Instead, you > could leverage the existing tools. That falls apart when those tools > are corrupted so that they no longer can be relied upon to produce > predictable results. It is ever more true now. > >>> But even the laymen become power-corrupted. >> I think that is a bit of an exaggeration. They have a >> responsibility to bear and sometimes they get carried away. > > Every young programmer wants to put his own mark on things. The > problem is that these changes are frequently ill-considered and > sometimes have bad consequences. 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. The reason why this setting wasn't kept by default is to fix the fundamental problem, without additional cost of keeping this setting hidden. People have full rights to receive the fixes like this, as you have full rights to complain about them. This is part of the game, IMHO Emacs does not change that often, and really keeps things the same, just because there is nothing to fix apart from things that need to be changed in order to guarantee future of Emacs. Wojciech
From: Uday S Reddy on 13 Jun 2010 08:46 On 6/10/2010 8:57 PM, Stefan Monnier wrote: > > Based on the amount of bugs in Emacs, the wishy-washy semantics of most > of its operations, the quick&dirty half-solutions seen in most of its > packages, it amazes me that someone would consider Emacs as > mission-critical ;-) Mission-critical software isn't necessarily perfect software. What software is? Mission-critical software requires a clean architecture, attention to fundamental notions of reliability, a design that can isolate any potential problems and an ability to recover from them. Even though you seem to think the semantics of the Emacs operations is wishy-washy (and I have pointed out some of them to you myself), the Emacs manuals - both the user's manual and the programming manual - are of quite high-quality and do an excellent job of defining things. We can generally spot the portions that are wishy-washy or too complicated for comfort and stay away from them. The use of Lisp with type safety and memory safety means that even inexperienced programmers can usually deliver code of decent quality. The various fail-safe mechanisms, such as autosave, backups, movemail etc, help for failure recovery. The large, professional user base, along with its age, imply that most problems have been identified and fixed a long time ago. The small developer community might also mean that it grows at a manageable pace (even though that seems to be changing now). When I was trawling through the net, I found somebody say that nobody ever lost an email message in VM (the Emacs package for email that I currently maintain). When I enquired about it, it was pretty much true. There is only one known instance of mail folder corruption, which happened due to the unibyte-multibyte transition of Emacs around the same time that Kyle Jones was retiring from VM. So, the transition was apparently half-done and wasn't discovered until much later. In comparison, I have lost loads of emails in Microsoft tools, lost files or changes to files in the Office Suite, had files damaged by Sun-Microsoft file servers, and had damaging system crashes due to hardware/device driver faults. On the whole, Emacs has been among the most reliable of all the tools I use. And, I suspect that must be true for almost all of us here. So, please do own up to this proud heritage! > > Stefan "who never uses Emacs while root" I guess you will have to amplify this point for us to draw the right conclusions from it. Cheers, Uday
From: Mark Crispin on 13 Jun 2010 13:23 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. >> This sort of thing happened in the past as well. The difference was >> that there was accountability in the past that is absent today. > What sort of acountability, I think unhappy `customers' is enough > punishment. Apparently not, if the "customers" are told that it's their fault for not being on the development list. > 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. > 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). > 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. 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. 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. -- 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 13 Jun 2010 13:26 On Sun, 13 Jun 2010, Uday S Reddy posted: > Mission-critical software requires a clean architecture, attention to > fundamental notions of reliability, a design that can isolate any potential > problems and an ability to recover from them. To this, also add predictability. Mission critical software doesn't deliver different results just because the screen width is different. -- 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: Alan Mackenzie on 13 Jun 2010 16:56
In comp.emacs Mark Crispin <mrc(a)panda.com> 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). |