[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs learning curve
From: |
Davis Herring |
Subject: |
Re: Emacs learning curve |
Date: |
Thu, 22 Jul 2010 07:20:10 -0700 (PDT) |
User-agent: |
SquirrelMail/1.4.8-5.el5_4.10.lanl3 |
> Is not this a reason for making CUA mode default? As long as it is not
> the default it will be a second class citizen and obstacles like this
> will remains. And those makes it quite a bit harder for new users.
If it is in fact the case that "As long as [a keymap] is not the default
... obstacles like this will remain[]", then it would still be true (but
about the current global map) if CUA were the default, and so obstacles
would still remain. (You were making a point very much like this in a
more recent message.) So how can your argument favor either as the
default?
Of course, I think I know the answer. You think that it is not the keymap
conflicts, but the lack of CUA itself, that makes it "quite a bit harder
for new users". So then the obstacles (keymap conflicts) are bad, but
only because they interfere with the obvious, necessary adoption of
CUA-as-default. But look at the resulting logic:
1. Keymap conflicts make it hard/problematic to change the default.
2. If CUA became the default, the keymap conflicts would have been
addressed. (Because they had to be!)
3. It would then no longer be problematic to change the default.
4. Therefore, we should adopt CUA, because it's not problematic to do so.
Step 3 never happens, because the benefit it provides occurs too late.
"If the problem were already solved, it would be easy, so let's do it!"
My sincerest apologies if I misunderstand your thinking. But if I
understand it correctly, please don't construct a circular argument and
then hide it by connecting keymap conflicts (which we're all unhappy
about) directly to "quite a bit harder for new users", which is not a
point everyone agrees on.
Davis
--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.
- Re: Emacs learning curve, (continued)
- Re: Emacs learning curve, Ivan Kanis, 2010/07/22
- Re: Emacs learning curve, David Kastrup, 2010/07/22
- Re: Emacs learning curve, Wojciech Meyer, 2010/07/22
- Re: Emacs learning curve, Stephen Eilert, 2010/07/22
- Re: Emacs learning curve, David Kastrup, 2010/07/23
- Re: Emacs learning curve, Fren Zeee, 2010/07/23
- Re: Emacs learning curve, Dirk-Jan C . Binnema, 2010/07/23
- Re: Emacs learning curve, Alfred M. Szmidt, 2010/07/23
- Re: Emacs learning curve, David Kastrup, 2010/07/22
- Re: Emacs learning curve, Lennart Borgman, 2010/07/22
- Re: Emacs learning curve,
Davis Herring <=
- Re: Emacs learning curve, Lennart Borgman, 2010/07/22
- Re: Emacs learning curve, Alfred M. Szmidt, 2010/07/22
- A more modest proposal (Was: Emacs learning curve), Daniel Colascione, 2010/07/23
- Re: A more modest proposal, David Kastrup, 2010/07/23
- Re: A more modest proposal (Was: Emacs learning curve), Jan Djärv, 2010/07/23
- Re: A more modest proposal (Was: Emacs learning curve), Daniel Colascione, 2010/07/23
- Re: A more modest proposal, Thien-Thi Nguyen, 2010/07/23
- Re: A more modest proposal (Was: Emacs learning curve), Jan Djärv, 2010/07/23
- Re: A more modest proposal, Miles Bader, 2010/07/23
- Re: A more modest proposal, Jan Djärv, 2010/07/23