From: Uday S Reddy on 10 Jun 2010 14:38 Mark Crispin wrote: > 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. Exactly! By "community-owned", I don't mean community-developed. There needs to be control and discipline etc in the development team. Otherwise, there will be chaos, and mission-critical fitness will go out of the window. 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. In any case, I think we have reached a point where you and Stefan need to talk to each other directly and sort it out. 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. > 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. > 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. Cheers, Uday
From: Thad Floryan on 10 Jun 2010 15:06 On 6/10/2010 6:43 AM, Stefan Monnier wrote: > [...] > 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. > [...] Hmmm, I've had the following line (global-set-key "\M-#" 'goto-line) in my .emacs for so many years (think decades) as a quick'n'easy method to go to a specific line number mentioned in a compiler warning/error regardless where I'm presently in the buffer. I.e., "C-u 8 ESC #" goes to line 8; "C-u 1234 ESC #" goes to line 1234. How is/will that be affected (if C-n and C-p are affected)?
From: Stefan Monnier on 10 Jun 2010 15:53 >> 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? Only for the display part: it doesn't help navigation. > So, this particular decision doesn't seem to be all that difficult. Leaving line-move-visual as nil would have been an easy decision to satisfy old users who already like Emacs. But setting it to t (without switching all the way to visual-line-mode) seemed like a good compromise. Given the reactions we've seen since Emacs-23.1 was released, I don't regret the decision. Stefan
From: Stefan Monnier on 10 Jun 2010 15:57 >> A third suggestion is that we should start thinking of Emacs as >> mission-critical software. > It amazes me that anyone would think otherwise. 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 ;-) Stefan "who never uses Emacs while root"
From: Tassilo Horn on 10 Jun 2010 18:02
Stefan Monnier <monnier(a)iro.umontreal.ca> writes: > - 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 [...], 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?). I agree, and with the macro exception I'm in favour of operating on visual lines by default. But what I don't understand is why there are two levels of operating on visual lines: line-move-visual and visual-line-mode. IMO, the former is confusing, because C-a/e (and probably others) still operate on logical lines. I guess, that's because VLM is more invasive, i.e. keys get bound to new functions. But then, why not drop VLM altogether and make `move-beginning/end-of-line' obey line-move-visual, too? Bye, Tassilo |