From: Lennart Borgman <lennart.borgman@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: mathias@mnet-mail.de, David Kastrup <dak@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel@gnu.org
Subject: Re: Tweaking t-m-m to make room for d-s-m
Date: Fri, 26 Mar 2010 22:30:46 +0100 [thread overview]
Message-ID: <e01d8a51003261430w744b703y32d972e02b487a4b@mail.gmail.com> (raw)
In-Reply-To: <5F1D87251C98412EADC1187ABFCC3E8D@us.oracle.com>
On Fri, Mar 26, 2010 at 10:18 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> Couldn't C-x SPC be used to activate the region (without changing
>> >> point and mark)? It seems unused and is easier to type then
>> >> Alan's suggestion. -- Mathias
>> >
>> > C-z
>>
>> I think that would be a very bad idea since C-z seems to be used as
>> undo in most editing environments.
>
> And C-z is currently `suspend-frame' in Emacs.
And you have said this is not an important use since there are
alternative key bindings.
> CUA is so very different from Emacs that I see no need to consider such
> conflicts. Emacs does not sync with CUA's C-c, C-x, C-v, ESC,... Why should we
> treat CUA's C-z with special respect?
It is new users that should be treated with respect. All of them know
these key bindings. All of them use them. (If they are not computer
illiterates.)
> Arguments that Emacs should do something by default _only_ because vi (e.g.
> Viper) or CUA does it are non-starters, with me at least.
The vim community has accepted them. To me that means that they (as a
community) have accepted that they are important.
Emacs has not accepted them. I fairly certain the problem is backward
compatibility in Emacs. Nothing else at all. (Of course backward
compatibility is important but it is not the whole story.)
But I do not expect CUA keys to be accepted now, I just want to avoid
adding new troubles. Using C-z for something new (except `undo') would
be new trouble IMO.
> There is a logic behind the CUA keys, yes. Those who came up with CUA didn't do
> so without thought. But it is a logic that takes as its starting point that the
> set of editing operations is just about summed up by those few operations: cut,
> copy, paste, undo. Under such an assumption it is not a bad idea to put all of
> those frequently used operations together within easy reach.
>
> But Emacs's use of keyboard keys blows the "half-dozen editing operations"
> scenario out of the water.
I would rather say it looks like CUA blows Emacs out of the water ;-)
But that is not what I want.
> AFAICS, the _only_ reason for Emacs to conform to CUA
> would be to have a better fit with the outside world. For me, that is not a
> sufficient reason.
If you just say "conform" you may miss the essentials of it. It is
about user convenience, not about some strictness called "conform" or
"better fit".
next prev parent reply other threads:[~2010-03-26 21:30 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87sk7pzqsp.fsf@ambire.localdomain>
2010-03-24 20:20 ` d-s-m default: nil Ulf Jasper
2010-03-24 20:26 ` Deniz Dogan
2010-03-25 0:24 ` d-s-m default: Nil + explanation! (was: d-s-m default) Memnon Anon
2010-03-25 4:22 ` Lennart Borgman
2010-03-25 8:24 ` d-s-m default: Nil + explanation! David Kastrup
2010-03-25 13:03 ` Lennart Borgman
2010-03-25 13:18 ` David Kastrup
2010-03-25 13:27 ` Lennart Borgman
2010-03-25 14:21 ` Davis Herring
2010-03-25 14:42 ` Lennart Borgman
2010-03-25 15:04 ` Drew Adams
2010-03-25 16:27 ` Tweaking t-m-m to make room for d-s-m Stefan Monnier
2010-03-25 17:51 ` Alan Mackenzie
2010-03-26 7:04 ` Juri Linkov
2010-03-25 23:56 ` Drew Adams
2010-03-26 2:36 ` Stefan Monnier
2010-03-26 8:28 ` mathias
2010-03-26 17:53 ` Drew Adams
2010-03-26 20:18 ` Lennart Borgman
2010-03-26 21:18 ` Drew Adams
2010-03-26 21:30 ` Lennart Borgman [this message]
2010-03-26 22:05 ` Christophe Poncy
2010-03-26 22:07 ` Lennart Borgman
2010-03-26 22:23 ` Drew Adams
2010-03-26 22:33 ` Lennart Borgman
2010-03-26 22:44 ` Drew Adams
2010-03-26 22:59 ` Lennart Borgman
2010-03-26 23:15 ` Drew Adams
2010-03-26 22:30 ` Christophe Poncy
2010-03-26 22:13 ` Drew Adams
2010-03-26 22:32 ` Lennart Borgman
2010-03-26 23:11 ` Drew Adams
2010-03-26 23:23 ` Lennart Borgman
2010-03-26 23:35 ` Drew Adams
2010-03-27 22:49 ` Richard Stallman
2010-03-27 23:27 ` Lennart Borgman
2010-03-27 23:37 ` Deniz Dogan
2010-03-27 23:53 ` Lennart Borgman
2010-03-28 0:28 ` Deniz Dogan
2010-03-29 23:38 ` Richard Stallman
2010-03-30 0:08 ` Lennart Borgman
2010-03-30 1:16 ` Christoph
2010-03-30 5:31 ` Richard Stallman
2010-03-30 6:38 ` Lennart Borgman
2010-03-30 9:47 ` Eli Zaretskii
2010-03-30 18:17 ` Chad Brown
2010-03-30 19:19 ` Lluís
2010-03-25 20:48 ` d-s-m default: t Noah Friedman
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=e01d8a51003261430w744b703y32d972e02b487a4b@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=dak@gnu.org \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=mathias@mnet-mail.de \
--cc=monnier@iro.umontreal.ca \
/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).