emacs-devel
[Top][All Lists]
Advanced

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

Re: delete-selection-mode as default


From: hw
Subject: Re: delete-selection-mode as default
Date: Sun, 09 Sep 2018 07:15:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Clément Pit-Claudel <address@hidden> writes:

> On 2018-09-07 10:39, hw wrote:
>>> On 2018-09-07 05:18, hw wrote:
>>>> When a selection is active, why would anyone assume that typing
>>>> an arbitrary letter is supposed to replace the entire selection,
>>>> or to disable it?
>
>>> Out of experience, mostly.  When almost every other program you
>>> use besides Emacs behaves that way, it's easy to assume that Emacs
>>> will behave the same way.
>
>> It's not my experience because when I want a selection deleted, I
>> delete it.  If it gets deleted otherwise, that's a mistake or maybe
>> even a bug when no undo is available.
>
> You seem to be conflating experience and desirable behavior.

You could say that --- as long as I don't press the wrong key, I'm
getting desirable behaviour.

>> I call it a design flaw because if whoever made it this way had
>> given any thought to it, it would at least be customizable
>
> Fortunately, some of those who "made it that way" did think about it
> :)  For example, Microsoft Word has an option called "Typing Replaces
> Selected Text."

That's a good thing.

> Unfortunately, I couldn't find a similar setting in OpenOffice, nor in
> LibreOffice. Gtk entries and textviews do not seem to provide a
> similar setting, either, but I wouldn't assume that they didn't give
> any thought to it.

Why not?

>> Software supporting users in making mistakes and making the mistakes
>> even worse suffers from design flaws unless doing so is the very
>> purpose of the software.
>
> I'm having trouble following the reasoning.  

Hm, let my try to explain:

The reasoning assumes that one important benefit of software is the
possibility to prevent mistakes, for example by validating the input
made by a user and by questioning or rejecting it when it is suspicious.

You can design software such that it provides this benefit and such that
it does not.  You can also design software such that it makes it more
likely that mistakes happen and such that it makes the effects of
mistakes worse.  In case it was not your intention to design your
software so that it makes it more likely that mistakes will happen, or
that it makes mistakes worse, but your software does that, your software
has a design flaw.

As for selections, this means that you can make your software so that
not every random keystroke makes them disappear, or you can make your
software so that the selection basically disappears with every random
keystroke.

Since random, accidental keystrokes sometimes happen, your software ---
assuming its purpose is not to make mistakes worse --- has a greater
benefit to the user and no design flaw when it protects the user from
such mistakes by not letting the selection disappear.

It can't very well protect the user from random, accidental keystrokes,
but it can make the mistake worse by making the selection disappear when
they occur.  If it does that, it has a design flaw.

Of course, there can be a problem when the user does not want to be
protected, or when it becomes troublesome to use the software because it
is overprotective.

In case of Emacs, a user can make a setting that makes the effect of
mistakes worse.  Some users are asking to make this the default while
others are against it.

>> I suspect that one important reason for the dangerous and careless
>> dealing with selections you find in many other programs is that the
>> developers couldn't be bothered to find a better way.
>
> I understand that feeling, but I don't see much to support it.  From
> the same observations, you could just as well conclude that no one
> cared enough about the behavior offered by Emacs to send patches to
> OpenOffice, Gtk, or many of the other libre IDEs and text editors.

I don't understand how multiple possible reasons for the impossibility
of bothering the developers would not all the more support the suspicion
that they couldn't be bothered.



reply via email to

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