From: Uday S Reddy on
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
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
>> 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
>> 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
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