Re: line-move-visual

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Judgment call is ok, and none of us can claim that we are perfect at that.
> But what concerns me is that after seeing all the discussion here, you still
> maintain that you "don't regret the decision" because a lot of people like
> it. So, are you opening Emacs to potentially unsafe changes in an effort to
> get people to like it?

Getting people to like Emacs is one of the goals, of course.  But I tend
to think more of "what would be the best settings for most users" (note
that I said "best", not "least controversial", nor "easiest to adapt
to").
Of course, this has to be balanced against "don't alienate existing
users" (which is also spelled "preserve backward compatibility of the
UI").

For the same kind of reason, Emacs-24 will change the way minor-modes
react when called with a nil argument (in Emacs-23, it toggles the mode,
in Emacs-24 it turns it ON unconditionally).  In this case, this doesn't
change the UI (when called interactively, the arg is never nil), but for
some users, their .emacs will end up doing something else than what they
intended.  This was deemed OK, because for many more users this change
will make their .emacs DTRT (i.e. it will silently fix a lurking bug in
their config), and it also makes it easier to add minor modes on hooks,
without having to rely on the existence of a turn-on-foo-mode or the use
of the more verbose (lambda () (foo-mode 1)).
I know some people will complain.  We always hear them a lot more than
those who benefit from such changes.

> You also haven't acknowledged that Emacs gets used as a platform on which
> other services are delivered, such as programming environments or mail
> clients.  Your response only touches upon the use of Emacs for personal text
> editing. Imagine, for instance, that your favourite mail client happened to
> use `next-line' instead of `forward-line' somewhere in handling the mail
> headers.

The byte-compiler flags this, luckily.

> It could damage the mail folders irretrievably over a period of time
> before it ever gets noticed.  Is that kind of trouble an appropriate
> price to pay for the "convenience" you talk about?

Every Emacs release brings in incompatibilities for Elisp code, many of
which aren't ever flagged by the byte-compiler.  So this particular
`next-line' change for Elisp code is but one of many other such
problems, and experience has shown it was not particularly serious.


        Stefan