[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On being web-friendly and why info must die
From: |
David Kastrup |
Subject: |
Re: On being web-friendly and why info must die |
Date: |
Mon, 08 Dec 2014 18:09:51 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>> For this reason it would make sense to make CUA keys the default, and
>> provide a compatibility switch for Emacs old timers who are used to
>> the current bindings.
>
> cua-mode is a clever and reasonably clean hack, but
> a hack nevertheless. So enabling it by default is not really an option.
>
> And note that under Mac OS X, there's no need for it, since Mac OS
> X uses another modifier than "control" for those C-x C-c C-v.
>
> I'm not opposed to a long term plan to possibly change C-x, C-c, and
> C-v.
Well, I don't want things like
"In order to move to the other end of the currently active region, press
C-x, and then press C-x within 200ms. If you are not fast enough, the
region will be erased instead." in the manual for the default behavior.
And yes, I am not making this one up:
cua-prefix-override-inhibit-delay is a variable defined in `cua-base.el'.
Its value is 0.2
Documentation:
If non-nil, time in seconds to delay before overriding prefix key.
If there is additional input within this time, the prefix key is
used as a normal prefix key. So typing a key sequence quickly will
inhibit overriding the prefix key.
As a special case, if the prefix keys repeated within this time, the
first prefix key is discarded, so typing a prefix key twice in quick
succession will also inhibit overriding the prefix key.
If the value is nil, use a shifted prefix key to inhibit the override.
You can customize this variable.
So before the C-c, C-x, C-v bindings can get their CUA defaults, there
must be some serious key sequence reorganization for Emacs.
--
David Kastrup
- Re: On being web-friendly and why info must die, (continued)
- Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/06
- Re: On being web-friendly and why info must die, David Kastrup, 2014/12/07
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/07
- Re: On being web-friendly and why info must die, David Kastrup, 2014/12/07
- Info and HTML, Ivan Shmakov, 2014/12/07
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/06
Re: On being web-friendly and why info must die, Filipp Gunbin, 2014/12/08
- Re: On being web-friendly and why info must die, Tom, 2014/12/08
- Re: On being web-friendly and why info must die, Eric S. Raymond, 2014/12/08
- Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/08
- Re: On being web-friendly and why info must die,
David Kastrup <=
- Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/08
- Re: On being web-friendly and why info must die, David Kastrup, 2014/12/08
- Re: On being web-friendly and why info must die, Lars Magne Ingebrigtsen, 2014/12/08
- Re: On being web-friendly and why info must die, David Kastrup, 2014/12/08
Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/08
Re: On being web-friendly and why info must die, Paul Eggert, 2014/12/08
Re: On being web-friendly and why info must die, Filipp Gunbin, 2014/12/08
Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/09
Re: On being web-friendly and why info must die, Ludovic Courtès, 2014/12/11