RE: please make line-move-visual nil

[Drew Adams]

> >  > This was done in July 2008, and there were fairly 
> >  > extensive discussions
> >  > on this list then, and on several occasions afterwards.
> > 
> > Why have prereleases then, if it's "too late" for feedback 
> > from users who are not willing to bleed on the edge, and
> > who don't necessarily read emacs-devel with their morning
> > coffee?
> 
> Pretest is not for changing the default behavior.  They are for fixing
> bugs before the release.  The time for users to voice their objections
> and requests for improvements is after Emacs is released.  There's
> always the next release.

I see. So if you happen not to have dug deeply into each discussion thread
before the prerelease, and spoken up about it, you're out of luck? Your voice
doesn't count because it's too late?

That's ridiculous.

There has sometimes been a tendency to regard changes that have been made during
Emacs 23 development as cast in bronze - even long, long before Emacs 23 is
released. We hear arguments such as "that's been true since last July", as if
that means it represents established practice from ancient history.

Now we are in pretest, so this too-late!-already-cast-in-bronze argument is I
suppose slightly stronger, but I still don't buy it.

FWIW, here is what Richard replied to me after I complained to Chong Yidong in
just such a situation, admittedly pre-pretest (2008-10-21, bug list, bug #1175),
but pertinent anyway, I think:

|DA. This is analogous to `find-file-noselect'. 
|   `bookmark-jump-noselect' is an obvious choice for some
|   function to call, to obtain the bookmark buffer and
|   buffer position. Without actually displaying it - perhaps 
|   because some other display mechanism is preferred or
|   perhaps because some other manipulation is to be performed.
| 
|RMS. I agree with you.
| 
|DA. Emacs 23 has not even been released, so please don't speak of
|   "changing" from the Emacs 23 behavior to what has always 
|   been the behavior before.
| 
|RMS. You are right here too.  Compatibility with past Emacs releases
| is more important, generally speaking, than avoiding changes in
| the sources now.  I am sure this function isn't used in very 
| many places in Emacs, so changing it back to be compatible won't
| be a lot of work.

No, the context wasn't exactly the same, but the spirit seems similar, to me.

Emacs 23 has not been released, so new features are really just proposals still,
no matter how long ago they were implemented. "Is this the default value we
really want?" That's a fair question up until the release. And it's actually a
fair question even after the release, IMO.

Some of you complained that Richard took too long to put out a new release,
because he insisted on bug fixes and documentation. I, for one, never had that
complaint. Quite the contrary, in fact. For all your proclaimed haste, I don't
see that we are better off.

[One thing I do wish had happened: I wish that we had produced an Emacs 23 that
had only the Unicode addition. Other changes could have come in another release
after that. No one argued against adding Unicode - it is a super-important
feature, and it should have been separated from all of the many behavioral
changes that are now accompanying it. Just one (late) opinion.]

> > You should also consider that for this particular default,
> > positive esponses will come quickly from those who use long
> > lines a lot, while they are unlikely to notice much
> > aggravation in environments where visual motion is likely
> > to be inappropriate, because those environment
> > typically strongly discourage long lines anyway.  Thus the 
> > complaints are likely to be relatively late and few
> 
> I don't know why you assume this: I happen to use 
> longer-than-80-column lines quite a lot, and I'm quite sure
> it's not as rare as you seem to think.  Not every text we
> see in Emacs is necessarily a well-formatted program source.

Stephen's point is valid. And your response doesn't really respond to it. The
point is that if you use Emacs with lines that are not long, and so do not wrap,
then you will not necessarily notice much difference.

That is my case, since I often have one buffer per frame, and I fit the frame to
the buffer. With code etc., I rarely encounter any wrapped text, so I rarely
notice visual-line movement. That doesn't mean that there is no reason to prefer
newline-oriented line movement in those contexts.