unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ergus <spacibba@aol.com>
To: Alan Mackenzie <acm@muc.de>
Cc: Eli Zaretskii <eliz@gnu.org>, Bingo <right.ho@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: delete-selection-mode as default (WAS: Some developement questions)
Date: Mon, 10 Sep 2018 00:33:17 +0200	[thread overview]
Message-ID: <20180909223317.h4bfzx4yjxeopfwq@Ergus> (raw)
In-Reply-To: <20180909191253.GD6047@ACM>

On Sun, Sep 09, 2018 at 07:12:53PM +0000, Alan Mackenzie wrote:

Hello Alan:
>Hello, Ergus.
>
>On Sun, Sep 09, 2018 at 19:59:53 +0200, Ergus wrote:
>
>> On Sun, Sep 09, 2018 at 01:13:16PM +0000, Alan Mackenzie wrote:
>> >Hello, Eli.
>
>> >On Sat, Sep 08, 2018 at 12:26:43 +0300, Eli Zaretskii wrote:
>> >> > Date: Sat, 08 Sep 2018 14:03:46 +0530
>> >> > CC: emacs-devel@gnu.org
>> >> > From: Bingo <right.ho@gmail.com>
>
>> >> > 1. When Emacs first starts, see if there is an init file. Various
>> >> > modern software do so, so we would be on solid ground there.
>
>> >> > 2. If so, trust the user that he would have set delete-selection-mode
>> >> > as required.
>
>> >> I'm not sure this is a valid assumption.  A user could have
>> >> delete-selection-mode not turned on because she had no idea such a
>> >> thing existed in Emacs.
>
>> >> >  This would avoid stepping on the toes of power users : which form
>> >> >  the majority of Emacs users.
>
>> >> Please note that veteran users only care about defaults when they need
>> >> to use Emacs on someone else's machine, or when logged on as some other
>> >> user (like root or su).
>
>> >A third situation, in which at least one veteran user (me) cares is when
>> >testing a bug fix with emacs -Q.  In such cases, I can get fairly
>> >irritated by, e.g., transient-mark-mode, and would get even more
>> >irritated were delete-selection-mode to be enabled by default.
>
>> >--
>> >Alan Mackenzie (Nuremberg, Germany).
>
>
>> I understand this. But then I only see 2 possible solutions:
>
>> 1) Keep emacs defaults only for experienced users, so forget about
>> getting new users and let it die slowly.
>
>Emacs is over 40 years old, and has seen many fads come and go.  It has
>been steadily acquiring new users in that time, and losing old ones.  As
>a program it combines extreme user friendliness with a long steep
>learning curve (i.e. it is not "beginner friendly").  I don't think we
>should be trying to change these attributes.
>
I partially agree because the project survived more or less
actively. But in the last 10 years the use have strongly declined.

The first 20 years emacs adapted to changes very quickly, changing
details, architectures, adopting gui, extending. After the 2000 appeared
many other editors and they more or less standardized what text editing
is. But also other factors affected the emacs extension like the
ubiquity of windows, notepad++ (with almost not learning curve), emacs
not being installed by default in the GNU/Linux distributions. So emacs
keeps a number of users like in the 90s while now the number of
programmers and developers in the world is orders of magnitude higher.
And we did nothing.

>> 2) Start thinking in the new generations who will inherit emacs but
>> already have a standard idea of how editors should behave; very
>> different of the emacs defaults.
>
>Many of them, faced with a choice between lots of clones which behave in
>a beginner-friendly, but suboptimal fashion, and the freshness of Emacs
>will come to chose Emacs.  We should not deprive them of this choice by
>dumbing down Emacs.
>
>Incidentally, the current discussion, in essence, has been going on on
>this list for the last 20 years or so, and probably quite a bit longer.
>
The point is that emacs can bring the same experience than any other
editor just some configuration (projects like spacemacs proves
this). But the default experience is too different that most users feel
scared and move to something "simpler". And we do nothing to avoid this;
stating with the tutorial or the online documentation (where 99% of the
users look for stuff and not in the self documentation, stackoverflow
success is the prove that nobody reads the manuals or the full
documentation in our days). 

There is not an interactive foro where users can make questions and
answer each other actively, and if the emacswiki is not updated in many
articles is a prove that we don't have enough users proportional to the
projects' dimension.  Add to this that many packages and functionalities
are duplicated in different packages and the user gets confused and some
packages in the repositories are unmaintained since 5 years or more.

Looking how the number of sublime text users grew in 2 years shows all
the users that emacs is loosing just for not bringing an initial good
face. Because Sublime is not superior to emacs in any sense, except the
behavior that is "like expected".

>> As a good consensus (and we are again where this thread started) is the
>> option to make an initial assistant (like the one in spacemacs but maybe
>> more complete) which can provide a bunch of options to the user to
>> set/unset them (with some information or more options depending of the
>> user (it can start with standard, advanced, minimal like many other
>> programs)). And add this configuration as the init file (if there was
>> not one) or as an extra file that cannot be skipped with -Q but with
>> another option that could be added.
>
>I suggested something similar some years ago, but never got around to
>implementing it: that there be several sets of defaults, and a user
>choses a set of defaults by the name of the command she starts Emacs
>with: for example, I would start emacs-classic, whereas you would start
>something like emacs-cua.  This could be implemented by hard links, with
>the Emacs binary finding its "pre-"initialisation file by checking the
>name it was invoked by.  Or something like that.
>
>> This is maybe a bit more complicated to implement, but it can satisfy
>> both cases somehow.
>
>> There is a point where old projects need to adapt themselves to the
>> running times, .....
>
>You have to be careful that this doesn't mean dumbing down.
>
OK, but it doesn't mean that everything should be frozen and unchanged
because it works as it is. Maybe is can be better, or in general the
users prefer that way (there should be a reason); and the project is not
only for it's developers.

Have you ever think why there are so many sublime text users?

>> .... not only importing functionalities, but also updating
>> functionalities they already have in order to improve them. But we need
>> to think in the normal users which are majority in any project.
>
>As a counterexample to your argument, look at the inconsistent series of
>messes that recent versions of Firefox have become.
>
Yes, But Firefox lost like the 70% of its users in 5 years because they
offered the same experience but the rest of the world moved on, so they
just tried to fix the issues they had with speed and memory usage. They
also have the chrome competition and they depend of web architectures
and interfaces that evolves constantly. So the comparison is not
parallel with emacs from my point of view.

But, as a consequence of latest changes, many chrome, chromium, and
Opera users moved back to Firefox again. Plugins started to be
maintained again, there are some more contributors now. If they had made
the changes gradually among the years maybe some users keep there but
also the changes had been not so drastic and the users had time to
adapt. In general the project has more live now, in spite of the
problems associated with any big change. And actually Firefox works
better now than before Quantum, specially in mobile.
>-- 
>Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2018-09-09 22:33 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-08  3:49 delete-selection-mode as default (WAS: Some developement questions) Bingo
2018-09-08  7:23 ` Eli Zaretskii
2018-09-08  8:33   ` Bingo
2018-09-08  9:26     ` Eli Zaretskii
2018-09-09 13:13       ` Alan Mackenzie
2018-09-09 14:53         ` Drew Adams
2018-09-09 15:12         ` Eli Zaretskii
2018-09-09 17:59         ` Ergus
2018-09-09 19:12           ` Alan Mackenzie
2018-09-09 22:33             ` Ergus [this message]
2018-09-09 23:34               ` Drew Adams
2018-09-11  4:22 ` Richard Stallman
2018-10-14 16:07   ` Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default) Karl Fogel
2018-10-14 18:42     ` Emacs undo behavior frustrating for new users Stefan Monnier
2018-10-15  4:59       ` Karl Fogel
2018-10-15  6:11         ` Noel Taylor
2018-10-15  5:43     ` Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default) Richard Stallman
2018-10-15  7:28       ` Van L
2018-10-16  6:44         ` Richard Stallman
2018-10-17 10:09           ` Nathan Moreau
2018-10-17 10:38             ` Emacs undo behavior frustrating for new users Andreas Schwab
2018-10-18  7:23               ` Richard Stallman
2018-10-17 12:00             ` Garreau, Alexandre
2018-10-17 14:05               ` Nathan Moreau
2018-10-17 14:20                 ` Garreau, Alexandre
2018-10-17 14:33               ` Yuri Khan
2018-10-17 16:06                 ` Eli Zaretskii
2018-10-18  7:23                 ` Richard Stallman
2018-10-15  8:26       ` Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default) Yuri Khan
2018-10-16  6:44         ` Richard Stallman
2018-10-16  7:22           ` Yuri Khan
2018-10-17  7:05             ` Richard Stallman
2018-10-20  8:15           ` Marcin Borkowski
2018-10-20 18:33             ` Elias Mårtenson
2018-10-15  7:54     ` Joost Kremers
2018-10-15  9:27       ` Joost Kremers
2018-10-15 12:01       ` Emacs undo behavior frustrating for new users Óscar Fuentes
2018-10-15 13:28         ` Joost Kremers
2018-10-16 12:27           ` Stefan Monnier
2018-10-17  7:05             ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2018-09-08  3:46 delete-selection-mode as default (WAS: Some developement questions) Bingo
2018-09-07  0:32 Noam Postavsky
2018-09-07  0:35 ` Drew Adams
2018-09-07  6:47 ` Eli Zaretskii
2018-09-07  9:40   ` Phil Sainty
2018-09-07 13:41     ` Eli Zaretskii
2018-09-08 11:37       ` Phil Sainty
2018-09-08 14:04         ` Eli Zaretskii
2018-09-07 15:35     ` Drew Adams
2018-09-07 16:16       ` Yuri Khan
2018-09-07 19:01   ` tomas
2018-09-07 19:23     ` Drew Adams
2018-09-07 20:28       ` tomas
2018-09-07 20:33     ` Noam Postavsky
2018-09-07 21:31       ` tomas
2018-09-09 13:45   ` Alan Mackenzie
2018-09-09 14:22     ` Clément Pit-Claudel
2018-09-09 15:12     ` Drew Adams
2018-09-09 20:39   ` Joost Kremers
2018-09-09 22:24     ` Drew Adams
2018-09-10  3:08       ` Phil Sainty
2018-09-10  3:17         ` Drew Adams
2018-09-10  5:15       ` Bingo
2018-09-10 18:16       ` Alan Mackenzie
2018-09-10 18:35         ` Clément Pit-Claudel
2018-09-10 19:19           ` Alan Mackenzie
2018-09-10 20:36         ` Drew Adams
2018-09-10  7:05     ` Eli Zaretskii
2018-09-11  4:22       ` Richard Stallman
2018-09-11  7:48         ` Eli Zaretskii
2018-09-12  0:33           ` Richard Stallman
2018-09-11  8:08         ` Eli Zaretskii
2018-09-12  0:33           ` Richard Stallman
2018-09-12 14:07             ` Eli Zaretskii
2018-09-08  5:13 ` Richard Stallman
2018-09-08 14:54   ` Drew Adams
2018-09-09  1:23     ` Ergus
2018-09-08 17:25   ` Clément Pit-Claudel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180909223317.h4bfzx4yjxeopfwq@Ergus \
    --to=spacibba@aol.com \
    --cc=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=right.ho@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).