Re: delete-selection-mode as default

[Ergus <spacibba@aol.com>]

Hi Alan:

On Sat, Sep 15, 2018 at 10:20:16AM +0000, Alan Mackenzie wrote:
>Hello, Eli.
>
>On Sat, Sep 15, 2018 at 10:50:18 +0300, Eli Zaretskii wrote:
>
>I can't help feeling that this isn't the right approach.  I feel that it
>will increase complexity which the new features won't justify.  I know
>I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here,
>but still: I think having to press a key sequence before d-s-m would work
>would take the purpose of d-s-m away - that key sequence might as well be
>C-w.
>
>You seem to be proposing to associate a three-value state with the
>region, which state users could change with key sequences.  I can see
>this being more confusing than the current two-value state (or is it
>2.5?) we currently have.
>
>It might well be that, having introduced transient-mark-mode as a
>default, a certain degree of confusion in Emacs is unavoidable.  If so,
>does it make sense to spend a lot of effort which might merely switch the
>confusion to somewhere else?  Assuming that we'd want to have options to
>retain all the "old" behaviour, I think it would be difficult to avoid
>increasing the confusion.
>
>I've interacted somewhat with hw, who's been driving this thread, and
>come to the conclusion that he doesn't really want to use Emacs.  The
>mechanisms of point, mark, and the regions are fundamental to Emacs and
>can't be readily customised away.  I don't think we should try to provide
>this customisability.
>
I have also interacted with hw and I totally disagree that he doesn't
want to use emacs. Maybe it is because I am a "younger" emacs users too,
or that I have tried many other editors & IDEs, but I understand what he
says and the fear the first time a user opens emacs comparing to other
similar tools. He just perceives the same than I: Emacs needs changes to
simplify the user experience, but any key change faces too much resistance.

My approach is 

1) To keep the default things AS SIMPLE AS POSSIBLE for the user in any
case, specially in a basic software like a text editor. (SIMPLE and
INTUITIVE if possible)

2) I agree with the Eli's approach to find a mean point that makes
less unhappy most of the people (if possible).

3) But interface changes are needed to survive, they require care to
avoid conflicts and reduce the collapse with backward compatibility, but
are needed.

NEVERTHELESS

The mark-point approach is not a fundamental emacs thing, it is just a
design choice enforced for technical limitations 40 years ago (like the
vi modes, the meta-hyper-syntax and so on) This means that (citing Bill
Joy about vi) it was created for a world that doesn't exist anymore. So
it can (and should) be updated/upgraded as many other things in emacs
and any long living project.

Many emacs default behaviors are confusing for ALL new users even after
reading the tutorial or the manual. Others are just considered as
limitations/bugs because they require too many binds or are very
difficult to find/remember comparing with other editors. But some of
them are design choices made 40, 30 or 20 years ago. New ideas have born
after 1980, different approaches that make the user live easier or were
impossible to try in 1980. But any intent to change the old, becomes in a
thread like this, where many opinions (and very strong ones specially
the ones to keep the status quo) come out and conduce to nothing.

This difficult to change anything in the user interaction makes emacs to
feel still like in 1990 in spite of all the changes and modern stuff if
has. It has open doors to the actual vim use increase, the born and
HUGE grow of editors like atom and sublime and communities like
spacemacs or evil-mode; while the pure emacs use is becoming marginal.

There are new functionalities that appeared more recently and Emacs can
(and should) incorporate asap out of the box (switching lines, selection
highlight, better rectangular selection and interaction). And the real
problem to implement all this is not the emacs potential, but the most
orthodox/purist users that resist too much to any change.

Same thing happens with the suggestions about the tutorial changes, the
proposal of a centralized documentation in a web site and so on.

I think the only way to properly solve this kind of endless discussions
is to ask the users and not only the developers or advanced
users. Something like feathub in the emacs page will work (this should
be extended to many other GNU projects too).

Advantages:

1) Users (new and old) will have a voice in the emacs future.

2) The Developers will know if a proposed functionality will be usefully
for many users and check if it worth to invest time in it (and emacs
code size).

3) Better interaction user-user and user-developer.

4) Developers will know what are the most demanded functionalities with
priorities (easy and fast).

5) Users will have an idea if some functionality will be delivered soon
or not and why, and how many other users claimed them.

6) The featured comments opinions arguments and everything will be
grouped and ordered and if they reborn after some years will be easier
to check if the conditions changed to add it or if

I know that the mailing list can offer all this somehow... but again, it
is something that can be improved. Thinking as a 2018 under 30 yo user.

>Sorry if I've been a bit negative in this post.
>
>[ .... ]
>
>-- 
>Alan Mackenzie (Nuremberg, Germany).