[Top][All Lists]

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

Re: delete-selection-mode as default

From: Eli Zaretskii
Subject: Re: delete-selection-mode as default
Date: Fri, 14 Sep 2018 17:33:17 +0300

> From: Yuri Khan <address@hidden>
> Date: Fri, 14 Sep 2018 20:41:46 +0700
> Cc: address@hidden, address@hidden, 
>       Joost Kremers <address@hidden>, Noam Postavsky <address@hidden>, 
>       Emacs developers <address@hidden>, Eli Zaretskii <address@hidden>, Drew 
> Adams <address@hidden>, 
>       Phillip Lord <address@hidden>
> *The* core concept of Emacs as I understand it is its infinite
> customizability, and this is pretty much the main reason I stick with
> it.

There are limits to customizing Emacs.  Beyond those limits, what you
have is the basic ideas on which Emacs is based; if you want to change
them, you will have to write a different editor.

The region is one such basic idea.  If you want it to behave exactly
as selections in other editors, you are not talking about Emacs.  We
can (and do) provide approximations to what other editors do with
selections, but they are just that: approximations.

So I suggest not to ignore what Alan says, because I think there's a
hard nut of truth there, which we should endorse if we want to have a
common language.

IMO, the basic conundrum of what we have now with transient-mark-mode
and delete-selection-mode is that we are trying to cover turf that
cannot be covered by a single feature.  As result, large groups of
users will become unhappy, no matter what we do.

The region is currently used for 3 purposes: navigation, invoking
commands on a region of text, and delete-selection-mode.  (If someone
thinks that delete-selection-mode is a variant of "invoking commands
on a region of text", they are mistaken, and this long discussion is
one proof of that mistake.)  It should be clear from this discussion
that there are fundamental tensions between these 3 purposes.  The
first two can be reconciled by using the "active" vs "inactive"
region, something we already have.  This distinction is needed because
an Emacs buffer will almost always have a region, and therefore users
need some knob to control whether a command should act on the region
or on the entire buffer.  (It is possible that we need some new
command to "activate" the region, because the current method are IMO
unsatisfactory: they require navigation, which is totally gratuitous.)

The third use of the region, the one needed for delete-selection-mode,
is IMO impossible to reconcile with the other two.  Instead of trying
to reconcile them with some trick, we should consider introducing a
new "state" of the region, which will be activated by a special
command, or could be optionally activated by "C-x C-x" etc., given
some optional setting.  IOW, let the users "arm" the region for
delete-selection type of commands, similarly to how they currently
"activate" it for the other purpose.  Then the user could decide what
exactly they want the region to provide, and the basic conundrum is

> With transient-mark-mode being the Emacs default, I’m inclined to
> consider it a bug that certain commands act on the inactive region
> when t-m-m is enabled, and possibly a flaw that (interactive "r")
> makes it so easy to define such commands.

It's not a bug, it's a feature: commands that make no sense without
the region, like "upcase-region", should not need me to activate the
region for them to do what I expect them.

Other commands, which make sense both when there is and there isn't a
region, need an indication of what the user wants them to do, and
whether the region is active is that indication.

The problem is that we now want to introduce yet another, 3rd meaning
of the region, which is not identical to either of the other two.

reply via email to

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