Re: line-move-visual

[Joseph Brenner <doom@kzsu.stanford.edu>]

Evans Winner <thorne@unm.edu> writes:
> Tim X wrote:
> |   For example, how would most of the users feel if every
> |   discussion regarding emacs development, even if
> |   restricted to discussions that directly impact on
> |   basic/core behavior (however that would be defined). was
> |   posted to this list? I suspect that many would be
> |   irritated as this is supposed to be an emacs help forum,
> |   not a discussion forum for developments.
>
> Actually I think that would be a great idea -- I think
> that's exactly what ought to be done.

Some software projects publish summaries of what's been
happening on the developers list.  If you can find a volunteer
to do the job, these weekly newsletters are obviously a good
thing to have.

But this isn't the solution to the problem at hand.

> I have read a number of posts on the devel list discussing the
> question of how to communicate with Emacs users about things like
> proposed changes to defaults.

The right answer is that you should not be changing the defaults.

If we really can't convince the developers that they need to respect
backwards compatibility, an actual solution to the problem might
be something like creating a switch that needs to be flipped on to
get the new whizzy behavior, something like:

  (setq modernize-emacs t)

You then recommend that the default ~/.emacs for *new* users should
include that line.

Existing users should never have their existing ~/.emacs over-written
the default, so they should only see the old behavior (unless, of
course, they choose to add that line).

Documentation for "modernize-emacs" should make it clear that it's
under development, and that for the immediate future at least,
the behavior it imposes may change.

Doing something like this would be far better than the current
practices, though it's obviously not perfect.  Problems include:

  o  A third-party developer may be suprised by the need to ask
     users not to flip on "modernize-emacs", and may have to
     write code to shut it off and live with some user confusion
     when the "modernized" behavior goes away temporarily.

  o  It's effectively a project fork that at the very least
     complicates documentation and testing.

> I agree that there is a limit to what complaining about it
> after the fact can accomplish,

If you minimize UI changes, then these complaints are minimized.
If you eliminate UI changes, then these complaints are eliminated.