Re: line-move-visual

[Uday S Reddy]

>> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:
>>
>>> Coupled with these real technical issues, there are the attitudinal
>>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>>> and what have you.
>
> Despite the fact I don't agree witht he change in default behavior, I
> also want to make it very clear, I DO NOT support what has been
> posted regarding the motivation, care and competancy of the emacs
> developers and maintainers. To those of you who have done this I would
> say that making all sorts of assumptions regarding the motivations and
> considerations of the devel team without actually looking at what
> discussions did take place is an unjustified and unwarranted attack on
> those few people who put in the hard word to develop and maintain this
> free software. It is a cheap dishonarable swipe. It lumps all the
> developers together as if they are all in agreement regarding every
> change made and ignores the effort put in to try and get the right
> outcome and do the difficult job of balancing many different views. 

Oh, dear!  Sorry for the misunderstanding.  I didn't mean to imply that
the Emacs developers have shown the "attitudinal problems" that I
mentioned.  It had more to do with the attitudes expressed by some of
the "spokesmen" here (in Joseph Brenner's good words).

In themselves, the devs have been nothing less than professional and
polite, either here or on the emacs-devel list.  They do an incredible
amount of work, quite silently, and we all owe a great debt of gratitude
to them!

The thinking behind the line-move-visual decision went something like
this.  If C-n moves by logical lines then the new users would be
confused.  If it moves by visual lines then the experienced users would
be bothered.  But we have a flag whereby experienced users can revert to
the old behavior.  The new users won't know enough to set a flag.  So,
let us go with the default that helps out the new users.  See this
thread for example:

  http://thread.gmane.org/gmane.emacs.devel/101551/focus=101560

or tens of other threads that discussed line-move-visual.

I don't think there is any reason to attribute arrogance or carelessness
on the part of the developers in reaching that decision.  At worst, it
was a technical mistake in thinking that both the defaults are equally
bad.  Or, perhaps an error of judgement that the experienced users will
know enough to change the default.

---

Now that this thread has gone for this long and still seems to have some
life left, why don't we come up with some constructive ideas?  I have a
few of them here, mostly colored by my experience with maintaining VM.

The first suggestion I have is that the Emacs developers can find a way
to consult the user community about potential changes.  It is not
reasonable to expect that all users should take part in the developers
discussion in order to provide their input.  It seems like an additional
imposition on top of all the work that the developers already do, but
having an open discussion about visible behavior changes ahead of time
can save from unnecessary heartburn later on.  I do this kind of thing
regularly for VM.  See this discussion for example:

http://groups.google.com/group/gnu.emacs.vm.info/browse_thread/thread/1297bd3ab1de78d9/2361a430ee7e7bc3?lnk=raot#2361a430ee7e7bc3

The second suggestion, which Stefan seems to be thinking about already,
is to clearly label changes in the NEWS file.  This is also something I
have been doing in VM.  See, for example, the NEWS file here:

  https://launchpad.net/vm/+download

I am constantly irritated by the fact that some of the downstream
distributions omit the the NEWS files from installations.  I have
resorted to putting the NEWS file as an independent download on the web
site so that the downstream users can get it directly.  I think we
should try and impress upon the downstream guys the importance of NEWS
files.

A third suggestion is that we should start thinking of Emacs as
mission-critical software.  "Text editor" is a lousy description
which has long been out of date.  It is really platform on which a
number of critical services are delivered, for development of projects
or for running of teams and organizations.  A lot rides on it and any
changes that potentially cause corruption of files or data can be quite
serious. 

Finally, and I might be a bit OTT here, I think we should think of free
software as community-owned software.  It is not developer-owned
software (despite the aberration caused by the existence of FSF as a
copyright-owner).  Lots of people contribute, and they come and go.  The
software will live on for long after they are gone.  Free software isn't
"free-to-fork" software, even though the right to fork exists as a last
resort and as a foundation for everything else.  If that right needs to
be exercised, it is a signal that the community-ownership of the
software has broken down and that is not good for any of us.

Cheers,
Uday