Re: line-move-visual

[Tim X <timx@nospam.dev.null>]

Joseph Brenner <doom@kzsu.stanford.edu> writes:

> 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.
>

A good idea if someone is prepared to step up and do it.

> 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.

I tend to agree that defaults should usually not change. However, you
cannot anticipate all possible situations and should avoid absolutes.
Defaults should only change after serious consideration and discussion
and should be as inclusive of users as possible. However, they should
not be treated as sacred and can never be changed. 

>
> 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.

Again, we need to be very wary of any absolute such as UI will never
chnage or defaults can never change. We live in an environment that
changes and need to be able to adapt.

It would be a mistake to eliminate UI changes. There have been a number
of improvements in the emacs UI over the last couple of versions. Many
of htem I don't like, such as using dialog boxes for find file and
yes-no questions if you use the menu etc, but many others, think they
are excellent improvements that helps emacs reamin current and of
interest to new developers (who are important as some of them will
likely be future dev/maintainers). You also have things like the current
work on bi-directional editing, which will obviously be a UI change. The
developments in handling various character encodings also had some
impact on the UI. Many of these were positive and some of them were
important and some are necessary. 

Change is not the issue. Change can be positive and is necessary. The
issue is managing that change. Any attempt to enforce a static
unchanging environment will fail.

Tim


-- 
tcross (at) rapttech dot com dot au