emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: delete-selection-mode as default (WAS: Some developement questions)


From: Alan Mackenzie
Subject: Re: delete-selection-mode as default (WAS: Some developement questions)
Date: Sun, 9 Sep 2018 19:12:53 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

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: address@hidden
> >> > From: Bingo <address@hidden>

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]