line-move-visual
in [Lisp]
|
From: Tassilo Horn on 10 Jun 2010 18:10 Stefan Monnier <monnier(a)iro.umontreal.ca> writes: > Stefan "who never uses Emacs while root" I think you forgot to add the subordinate clause "...because he uses TRAMP's sudo method in an already running emacs server to access files where he has no permissions for", right? Bye, Tassilo
From: Evans Winner on 10 Jun 2010 18:48 In my opinion, the question should never be what new users of Emacs want. What new users want is an editor that is 5% better than notepad.exe because that is per-force the limit of their imagination. They generally do no know 1% of what Emacs can do, so are not in a position to intelligently decide what the defaults should be. They /should/ want to rely on experienced users for that, and they should be willing to spend the extra tiny bit of effort up-front to learn the reasoning behind it. If they aren't, then Emacs isn't for them. Let them go. Changing defaults to whatever makes the least friction for those who switch to Emacs is not a service to new users; the principle is that people tend to stick with what they learn first, so dumbed-down defaults produces dumbed-down users, who will, after a few months or years, show up on emacs-devel demanding even more dumbed-down defaults, because that would make it even easier for the next generation of Microsoft/IBM/CUA refugees. It sometimes surprises me to find that even some experienced users of Emacs don't use and even sometimes don't know how to use keyboard macros. The name Emacs does, after all, come from the phrase "Editor MACroS." It is a fundamental part of the user experience. The question with regards to new users and line-move-visual is whether the slight savings in initial cognitive friction comes and the price of making it more difficult for new users to learn to create and use typical line-at-a-time-type keyboard macros. I don't claim to know the answer to this particular question, but I think the principle above is the right one to consider in this kind of case.
From: Uday S Reddy on 10 Jun 2010 19:56 On 6/10/2010 11:02 PM, Tassilo Horn wrote: > > I guess, that's because VLM is more invasive, i.e. keys get bound to new > functions. Hi Tassilo, Can you or anybody else give us some examples of how visual-line-mode is invasive? I haven't been able to understand this point. Cheers, Uday
From: Tassilo Horn on 10 Jun 2010 20:48 Uday S Reddy <uDOTsDOTreddy(a)cs.bham.ac.uk> writes: >> I guess, that's because VLM is more invasive, i.e. keys get bound to >> new functions. > > Hi Tassilo, Can you or anybody else give us some examples of how > visual-line-mode is invasive? I haven't been able to understand this > point. Not invasive from a user's point of view, but from a implementation point of view. With visual-line-mode, C-e is not bound to `move-end-of-line' but to `end-of-visual-line', and the same applies to other bindings. It's possible that this redefinition of standard keys leads to unexpected behavior, for example when using [remap move-end-of-line]. Not sure if that's really problematic, so that's why I've asked. Bye, Tassilo
From: Mark Crispin on 11 Jun 2010 19:56
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. The problem is that nobody ever asked the existing users whether or not they wanted this global change foisted upon them. Rather, it was done unilaterally, and the individuals responsible are saying "See! Some people like it! It was a good change." This sort of thing happened in the past as well. The difference was that there was accountability in the past that is absent today. > In my humble opinion, it is > easy to argue that the current default was ill-chosen. But it is not so easy > to argue that it should be changed. If we change it, then we face all the > same issues all over again affecting the other users that are depending on > the current default. So, it seems best to leave things as they are and make > a note of all the lessons learned. I agree that we are probably screwed, and royally so. 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. 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. >> 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. >> Since user interface surprise is a barrier to upgrade, they make sure there >> aren't any such surprises. > Yes, that point is well-made. But, the same argument now suggests that the > default should not be changed yet again. Yup. We're probably screwed. -- 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. |