d-s-m default: nil

d-s-m default: nil

[Ulf Jasper]

Re: d-s-m default: nil

[Deniz Dogan]

2010/3/24 Ulf Jasper <ulf.jasper@web.de>:
>
>
>

Couldn't agree more.

-- 
Deniz Dogan

d-s-m default: Nil + explanation! (was: d-s-m default)

[Memnon Anon]

Hi,

I wanted to give a small explanation, why I think Nil is the better
default. 

I am fairly new to emacs (started mid 2008) and I was well aware that
this would not be an easy task; but orgmode sounded so great.
Since then, I find myself more and more influenced by this single
program: Using emacs had a profound influence on how I perceive my
computer, maybe only equaled by my switch from Dos 6 to Win95, i.e.
"command line" style to fancy new "Everything is a GUI" concept.

I think changing to D-S-M as a default is throwing dust into the eyes of
the new users: Emacs is different. And without a minimal willingness to
read the documentation, one will certainly fail.

In fact, *imho* the fact that so many (new) users are complaining is an
indication for a gap in the documentation. Probably, a new Info Node is
needed, prominently placed and accessible from the splash screen,
listing and explaining:

        a) Why a certain feature acts different to "common" practice in
          other programs, giving some rational why this feature is
          implemented and what is the advantage to a user.
        
        b) Showing an easy way (customize interface) how to change this
           "emacsy" behaviour to the usage pattern the user is
           accustumed to, in case he is not convinced or wants to start
           working with emacs and puts exploring this facette later.

There is so much information out there on the web (and I spent a great
deal of time to hunt 'em down), but a lot of (most?) resources don't
give an explanation, why this is actually superior, why one would want
to take the effort to retrain oneself.

Example: Scrollbar on the left side.
I turned the scrollbars of at once, so I never really realized the
default is different to accustomed placement. But I would certainly have
thought "This is *weird*! Do they have to do everything differently?" 
Is there anywhere in the info pages clearly stated that having the
scrollbar on the left side might be unusual, but actually offers better
ergonomic? [Mhhh, one sentence in a footnote.] But hey, "This is the
emacs way!". Yes, but without a sound reason, no one (today) is going to
retrain most of what he is used to without (at least) some reason.

So, I think it is a good thing if a new user encounters unexpected
behaviour: This makes him aware that there are different ways.
*But*: There should be an (faq?) Info-Node especially destined to 
catch these cases, prominently placed on the splash screen! 
The user will know from the start: If something is odd, most probably,
an answer and possibly a "fix" is where I can easily find it.

When I started to leave orgmode and have a look at the outer "emacs"
world, 23 was already on my machine, with t-m-m on by default. I had
read about "using mark to navigate", but until today, whenever I set a
mark, there was a region, so to me, setting the mark made only sense
when I wanted to set and act on a region. Due to this thread 
(thanks David Kastrup!), I kept wondering: "Why would anyone be
disturbed by t-m-m? Why navigate by mark?" and reread the old thread 
of 2008 and the info pages on mark: There is a *global* mark ring! 
*wow*! That feature would not have been very usefull for my earliest
days, but now, with lots of open buffers, this sounds great!
So, I will test using the mark more for the next days and use 
'C-Spc C-Spc' whenever I will want to operate on the active region.

I really do not think that "being different" is what makes new emacs 
users shy away. If they had a single entry point as described above that
provide them a) the concept/idea of the default and b) an easy
explanation how to change to "common practice", it does not matter,
if 'd-s-m t' is default or not. 

btw: I am suscribed to emacs.devel, emacs.help, Planet Emacs and follow
     the Recent Changes of the emacswiki fairly recently, but I have
     never before this thread heard of d-s-m. Thats why I so strongly 
     stress a prominent place. 

This explanation turned out not so small, after all ...
Thanks for listening ;)

Memnon

Re: d-s-m default: Nil + explanation! (was: d-s-m default)

[Lennart Borgman]

On Thu, Mar 25, 2010 at 1:24 AM, Memnon Anon
<gegendosenfleisch@googlemail.com> wrote:
> Hi,
>
> I wanted to give a small explanation, why I think Nil is the better
> default.

Thanks for giving your opinion.


> I think changing to D-S-M as a default is throwing dust into the eyes of
> the new users: Emacs is different. And without a minimal willingness to
> read the documentation, one will certainly fail.

I see no reason that they should have to read something before they
can do even the simplest editing.

I believe many potential new users will just move on if they have to
start that way. They do not want to waste time for such simple things
before they know it might be worth it.


> In fact, *imho* the fact that so many (new) users are complaining is an
> indication for a gap in the documentation.

I think they are complaining that it takes to much time to just get started.

When they want to do something special their willingness to read is
probably much higher.

Re: d-s-m default: Nil + explanation!

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Mar 25, 2010 at 1:24 AM, Memnon Anon
> <gegendosenfleisch@googlemail.com> wrote:
>> Hi,
>>
>> I wanted to give a small explanation, why I think Nil is the better
>> default.
>
> Thanks for giving your opinion.
>
>
>> I think changing to D-S-M as a default is throwing dust into the eyes of
>> the new users: Emacs is different. And without a minimal willingness to
>> read the documentation, one will certainly fail.
>
> I see no reason that they should have to read something before they
> can do even the simplest editing.

There is no point in reverting to polemics until we have even decided
what we are talking about.

For example, there was one proposal that the equivalent of
delete-selection-mode was enabled for all marking operations (mouse,
shift-selection) that new user would be tempted to use, coming from
other editing environments.

This proposal was basically shouted down with "I want
delete-selection-mode for all and won't accept less", and with polemics
of the "even the simplest editing" kind.

Any attempts of mine to narrow down the issue to separately decidable
(and configurable) issues have been ignored: one or two postings later
we are back to polemics.

-- 
David Kastrup

Re: d-s-m default: Nil + explanation!

[Lennart Borgman]

On Thu, Mar 25, 2010 at 9:24 AM, David Kastrup <dak@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Thu, Mar 25, 2010 at 1:24 AM, Memnon Anon
>> <gegendosenfleisch@googlemail.com> wrote:
>>> Hi,
>>>
>>> I wanted to give a small explanation, why I think Nil is the better
>>> default.
>>
>> Thanks for giving your opinion.
>>
>>
>>> I think changing to D-S-M as a default is throwing dust into the eyes of
>>> the new users: Emacs is different. And without a minimal willingness to
>>> read the documentation, one will certainly fail.
>>
>> I see no reason that they should have to read something before they
>> can do even the simplest editing.
>
> There is no point in reverting to polemics until we have even decided
> what we are talking about.

I do not think what I said is just polemics. I tried to describe how
users can be expected to behave today. This is an important point.

I do not have time to dig into research of this question now, but if
you know some it would be great (and I would be very surprised if I
was wrong in this particular case).


> Any attempts of mine to narrow down the issue to separately decidable
> (and configurable) issues have been ignored: one or two postings later
> we are back to polemics.

I have pointed to that it looks lik better integration with cua-mode
is needed, but I have got no reply to that.

Re: d-s-m default: Nil + explanation!

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Mar 25, 2010 at 9:24 AM, David Kastrup <dak@gnu.org> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> I see no reason that they should have to read something before they
>>> can do even the simplest editing.
>>
>> There is no point in reverting to polemics until we have even decided
>> what we are talking about.
>
> I do not think what I said is just polemics.

So you seriously believe that currently it is not possible for a
prospective user to do even the simplest editing in Emacs.

-- 
David Kastrup

Re: d-s-m default: Nil + explanation!

[Lennart Borgman]

On Thu, Mar 25, 2010 at 2:18 PM, David Kastrup <dak@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Thu, Mar 25, 2010 at 9:24 AM, David Kastrup <dak@gnu.org> wrote:
>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>
>>>> I see no reason that they should have to read something before they
>>>> can do even the simplest editing.
>>>
>>> There is no point in reverting to polemics until we have even decided
>>> what we are talking about.
>>
>> I do not think what I said is just polemics.
>
> So you seriously believe that currently it is not possible for a
> prospective user to do even the simplest editing in Emacs.

Yes I do.

In simple editing I include that the visible region behaves as they do
in other editing environment. That is something I have seen people
using very frequently.

But the CUA keys are not used equally often, but those who are used to
edit much normally use them much.

If I am kind I am not including CUA keys for basic editing ;-)

Re: d-s-m default: Nil + explanation!

[Davis Herring]

>> So you seriously believe that currently it is not possible for a
>> prospective user to do even the simplest editing in Emacs.
>
> Yes I do.
>
> In simple editing I include that the visible region behaves as they do
> in other editing environment. That is something I have seen people
> using very frequently.

But is that "the simplest editing" or merely "simple editing"?  The former
is more objective than the latter, because most of us would agree on an
approximate order of complexity among editing operations, but it is quite
arbitrary where to draw the line between "simple" operations and the
others.

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: d-s-m default: Nil + explanation!

[Lennart Borgman]

On Thu, Mar 25, 2010 at 3:21 PM, Davis Herring <herring@lanl.gov> wrote:
>>> So you seriously believe that currently it is not possible for a
>>> prospective user to do even the simplest editing in Emacs.
>>
>> Yes I do.
>>
>> In simple editing I include that the visible region behaves as they do
>> in other editing environment. That is something I have seen people
>> using very frequently.
>
> But is that "the simplest editing" or merely "simple editing"?  The former
> is more objective than the latter, because most of us would agree on an
> approximate order of complexity among editing operations, but it is quite
> arbitrary where to draw the line between "simple" operations and the
> others.

I do not think it is very arbitrary. I see people erasing/overwriting
the visible region all the time. And I see them selecting it with both
mouse and keyboard.

RE: d-s-m default: Nil + explanation!

[Drew Adams]

> This proposal was basically shouted down with "I want
> delete-selection-mode for all and won't accept less", and 
> with polemics of the "even the simplest editing" kind.

Hm. You keep saying that. And you've tried to give the impression that it is I
whom you are quoting, that I've insisted on d-s-mode for all.

That's not my position, and it never has been. _No one_ has supported such a
position. It's just another of your straw men. You are quoting no one, trying to
rewrite la petite histoire, populating it with monsters of your imagination.

And no one has shouted you down. Is it OK for anyone to disagree with you?

My position is:

 I'm OK with leaving the default as it is, though I
 think it would help more people if we implemented
 Juri's proposal.

I made it clear that while I think d-s-mode as the default might be a good idea,
it is better to leave d-s-mode unmolested, as an option, and _not_ to make it
the default, than would be to mess up d-s-mode in a misguided attempt to "fix"
it.

And I was clear that if lots of pain would be inflicted on users if d-s-mode
were the default, then we should not make it the default. And:

 I think we've already effectively moved on, saying that
 d-s-mode as is is not quite the right default.

I agreed explicitly with Richard (and others) that:

 If we change the default, we don't have to use
 `delete-selection-mode'. We could use something different
 for this purpose if it is more suitabe."

So please stop with the straw men and crying victim. No bullies have shouted you
down.  AFAIK, your proposal is still being considered. If (_IF_) in the end it
doesn't get quite the response you'd like, that's not because anyone has shouted
you down.

Tweaking t-m-m to make room for d-s-m

[Stefan Monnier]

> For example, there was one proposal that the equivalent of
> delete-selection-mode was enabled for all marking operations (mouse,
> shift-selection) that new user would be tempted to use, coming from
> other editing environments.

Here is how I see the situation:
- The DEL part of d-s-m would be acceptable right now
  (i.e. generalizing mouse-region-delete-keys to non-mouse-activated
  regions).
- The self-insert part of d-s-m is more problematic.  The main problem
  being the regions that are active "because of t-m-m" rather than
  because the user wanted to activate the region.

AFAIK the first point is decided and I'm just waiting for someone to
code it up.  [ The main reason why I like it is that I dislike the
current implementation of mouse-region-delete-keys. ]

For the second point, it's a real problem.  Enabling self-insert d-s-m
without addressing the problem will lead to frequent annoyances for some
usage patterns.  So, yes, we're back to discussing how to make t-m-m
work right, so that the region is active iff the user wants it.

Your suggestion to address that problem makes sense: make C-SPC not
activate the region (but let everything else activate it), so that the
region is only active when the user really intended to activate it.
This reverts some part of the "enable t-m-m by default".

I'm not completely sure it's a good solution, but it's one that I did
consider back when we discussed enabling t-m-m (and I was happy not to
have to resort to it ;-).

One of the problems left with it is what to do for C-x C-x.  Basically,
we'd want two commands: one that swap point and mark, and one that
activates the region.  Currently C-x C-x does both.  If we change C-x
C-x to not activate the region any more, than that makes the C-SPC
change more painful because then only C-u C-x C-x would be able to
activate the region when you forgot to use C-SPC C-SPC and just hit
C-SPC instead.  OTOH if we don't change C-x C-x, then users who want to
navigate to the mark get the region activated when they didn't want it.
One point of attack might be to use C-x C-x C-x instead of C-u C-x C-x
(a lot easier to type), but that's risky (hackish implementation almost
unavoidable, plus conflicts with C-x C-x followed by some other
C-x <foo> command)..

This C-x C-x issue can also be solved if we can come up with a short
key-binding that activates the region (in which case C-x C-x doesn't
need to activate the region).  Notice that we also have a need for
a short key-binding to deactivate the region (one that has fewer
side-effects than C-g, e.g. can be embedded in a keyboard macro).
So maybe the answer to all this is to find a "short" key-binding that
can toggle the region's active status.


        Stefan

Re: Tweaking t-m-m to make room for d-s-m

[Alan Mackenzie]

Hi, Stefan,

On Thu, Mar 25, 2010 at 12:27:50PM -0400, Stefan Monnier wrote:

[ .... ]

> This C-x C-x issue can also be solved if we can come up with a short
> key-binding that activates the region (in which case C-x C-x doesn't
> need to activate the region).  Notice that we also have a need for
> a short key-binding to deactivate the region (one that has fewer
> side-effects than C-g, e.g. can be embedded in a keyboard macro).
> So maybe the answer to all this is to find a "short" key-binding that
> can toggle the region's active status.

How about C-x C-y bound to `toggle-active-region'?  C-x C-y appears to be
unused (at least, according to the Emacs manual), is very "close" to C-x
C-x, and is non-difficult to type.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Tweaking t-m-m to make room for d-s-m

[Juri Linkov]

> How about C-x C-y bound to `toggle-active-region'?  C-x C-y appears to be
> unused (at least, according to the Emacs manual), is very "close" to C-x
> C-x, and is non-difficult to type.

Is it non-difficult to type on a QWERTZ keyboard
where "y" is very close to "x"?

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> Here is how I see the situation:
> - The DEL part of d-s-m would be acceptable right now
>   (i.e. generalizing mouse-region-delete-keys to non-mouse-activated
>   regions).
> - The self-insert part of d-s-m is more problematic.  The main problem
>   being the regions that are active "because of t-m-m" rather than
>   because the user wanted to activate the region.
>
> AFAIK the first point is decided and I'm just waiting for someone to
> code it up.  [ The main reason why I like it is that I dislike the
> current implementation of mouse-region-delete-keys. ]
> 
> For the second point, it's a real problem.  Enabling self-insert
> d-s-m without addressing the problem will lead to frequent 
> annoyances for some usage patterns.  So, yes, we're back to
> discussing how to make t-m-m work right, so that the region is
> active iff the user wants it.

So much for the famous user poll. ;-)
 
> make C-SPC not activate the region (but let everything else
> activate it), so that the region is only active when the user
> really intended to activate it.

Inappropriate assumption about user intention. Why assume that a user never
intends to activate the region when s?he sets the mark using C-SPC? Sometimes I
do and sometimes I don't.

Setting the mark sets a navigation point, but it also sets one end of the region
(by definition). If you want to select everything from here to there, and there
is no ready command that does that (as does `C-M-@' for sexps, for example),
then you want to set the mark here, move point there, and have the region
activated. That's not an uncommon intention.

Currently, you can avoid activating the region by using C-SPC C-SPC instead of
C-SPC. And if you activate it and change your mind, you can use C-g to
deactivate it. Not good enough?

If you think C-SPC C-SPC is too much trouble, then switch the two: Let C-SPC set
the mark without activating the region and C-SPC C-SPC set mark and activate. I
could live with that, and I'll bet other d-s-moders could too.

If t-m-mode is off, C-SPC C-SPC currently activates the region temporarily (i.e.
without turning on t-m-mode). This change would just mean that C-SPC C-SPC
always activates.

But we can do better: Let users decide individually, by adding an option that
says whether a single or a double C-SPC activates the region. The default could
be either (double, if you like). That way, John Default can use C-SPC to set
mark without activating and use C-SPC C-SPC to set and activate. And Jane
Customize can use C-SPC to set and activate and C-SPC C-SPC to set without
activating.

Even better: The option could be defined so that one possible choice separates
the navigational use from the region use completely. One of the possible values
would thus mean that the key that sets mark and activates the region would not
push it to the mark ring.

For example, let the option value be a cons of two commands, the car being for
C-SPC and the cdr for C-SPC C-SPC. The commands could be chosen from these:

a. set mark and push to mark-ring  (do not activate)
b. set mark and activate  (do not push to mark-ring)
c. set mark, activate, and push to mark-ring

A value of (a . b) would mean C-SPC sets mark for navigation only and C-SPC
C-SPC uses it only for selection. A value of (c . a) would give today's
behavior; (a . c) would swap today's keys.

> One of the problems left with it is what to do for C-x C-x.

Why not leave it as is? If t-m-mode is on, it activates; if off, it doesn't. The
real concern, I think, is what happens when one uses C-SPC (see above).

Or if C-x C-x C-g is really too much trouble, then add an option for this too.

> we'd want two commands: one that swap point and mark, and one that
> activates the region.  Currently C-x C-x does both.

Only if t-m-mode is on.

> if we don't change C-x C-x, then users who want to
> navigate to the mark get the region activated when they 
> didn't want it.

Just use C-g (or whatever new key we choose for deactivation).

And if someone never uses the active region, then by definition she never needs
t-m-mode, and s?he can just turn it off.

> This C-x C-x issue can also be solved if we can come up with a short
> key-binding that activates the region (in which case C-x C-x doesn't
> need to activate the region).  Notice that we also have a need for
> a short key-binding to deactivate the region (one that has fewer
> side-effects than C-g, e.g. can be embedded in a keyboard macro).
> So maybe the answer to all this is to find a "short" key-binding that
> can toggle the region's active status.

Sure, why not? That would combine well with my suggestion above about C-SPC vs
C-SPC C-SPC. Let users choose the general behavior they want, and give them a
key to toggle the current active/inactive state. And set the default behavior to
whatever you want.

Do I have a great key in mind for activate/deactivate? Dunno. How about `C-z' or
`C-x C-z'? Does `suspend-frame' really need to be bound to both of those?

Re: Tweaking t-m-m to make room for d-s-m

[Stefan Monnier]

>> make C-SPC not activate the region (but let everything else
>> activate it), so that the region is only active when the user
>> really intended to activate it.
[...]
> If you think C-SPC C-SPC is too much trouble, then switch the two: Let
> C-SPC set the mark without activating the region and C-SPC C-SPC set
> mark and activate.  I could live with that, and I'll bet other
> d-s-moders could too.

That's exactly what I meant by "make C-SPC not activate the region".

> But we can do better: Let users decide individually, by adding an
> option that says whether a single or a double C-SPC activates
> the region.

I'm not interested in discussing what options we should provide: that's
a trivial issue compared to the issue of what should be the default.

>> One of the problems left with it is what to do for C-x C-x.
> Why not leave it as is?

That means it activates the region, which is a problem if the user just
wants to swap point and mark but not activate the region.

> Or if C-x C-x C-g is really too much trouble, then add an option for
> this too.

Again, options are of no help here.  We're discussing the default.

>> we'd want two commands: one that swap point and mark, and one that
>> activates the region.  Currently C-x C-x does both.
> Only if t-m-mode is on.

Did I say we're discussing the default?

>> if we don't change C-x C-x, then users who want to
>> navigate to the mark get the region activated when they 
>> didn't want it.
> Just use C-g (or whatever new key we choose for deactivation).

Emacs should first do no harm.  I.e. the region should only be activated
when the user really intended to, since it may then be deleted
by a mere DEL or a self-inserting key.

> And if someone never uses the active region, then by definition she
> never needs t-m-mode, and s?he can just turn it off.

...[mumble]....default...


        Stefan

Re: Tweaking t-m-m to make room for d-s-m

[mathias]

IMHO this is the best proposal I've seen in this thread.

Zitat von Stefan Monnier <monnier@IRO.UMontreal.CA>:

> This C-x C-x issue can also be solved if we can come up with a short
> key-binding that activates the region (in which case C-x C-x doesn't
> need to activate the region).  Notice that we also have a need for
> a short key-binding to deactivate the region (one that has fewer
> side-effects than C-g, e.g. can be embedded in a keyboard macro).
> So maybe the answer to all this is to find a "short" key-binding that
> can toggle the region's active status.

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

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> 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

That would be just as handy for this as C-g is today.

Keep one of `C-x C-z' or `C-z' for `suspend-frame', and use the other to toggle
region activeness. I don't see why we need to sacrifice two such useful (and
easy-to-type) keys for `suspend-frame'.

Look at all of the other simple `C-' keys. They are all still used often, and
they are all still pretty good choices.

But C-z for `suspend-frame' (instead of some other key) is just a vestige, left
over from a time when there was not much competition for that key. It was no
doubt picked because of its similarity to C-z in UNIX to put a job in bg. Not a
big deal to change that key now, IMO.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

>> 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.

BTW I searched a bit to see if this was defined in CUA. A little bit
surprised I found that most pages mentioning CUA seems to be Emacs
related. Am I wrong to assume that this means that Emacs is the last
main editing environment that does not use CUA by default? I just did
a test with gvim and found that it seems to support:

- CUA keys and C-z (in insert mode)
- shift select
- self insert keys replaces visible selection

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> >> 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. So what? Why is one conflict over
what C-z means better than the other? Or would you forbid Emacs from using C-z
altogether? No, I know, you would prefer C-z and all the rest to be CUA by
default. ;-)

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?

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.

Wrt delete-selection mode, I was clear that I would not support it as the
default for Emacs if the only reason were that new users expect it. I explicitly
cited CUA as a counter-example. I support d-s-mode mainly because I think it is
useful for Emacs users generally, and certainly not just because it coincides
with what new users expect. Not so, CUA.

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. 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.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

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".

Re: Tweaking t-m-m to make room for d-s-m

[Christophe Poncy]

On 03/26/2010 10:30 PM, Lennart Borgman wrote:
> It is new users that should be treated with respect. All of them know
> these key bindings. All of them use them.

FWIW, it's not my case, i use Firemacs on IceCat (free software under 
the Modified BSD license) :

http://www.gnu.org/software/gnuzilla/addons.html
http://www.mew.org/~kazu/proj/firemacs/en/

And i'm learning conkeror, the emacs way of web browsing ;)

-- 
« It does not matter how slowly you go as long as you do not stop. » 
(Confucius)

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Fri, Mar 26, 2010 at 11:05 PM, Christophe Poncy <cp@canaxis.org> wrote:
> On 03/26/2010 10:30 PM, Lennart Borgman wrote:
>>
>> It is new users that should be treated with respect. All of them know
>> these key bindings. All of them use them.
>
> FWIW, it's not my case, i use Firemacs on IceCat (free software under the
> Modified BSD license) :
>
> http://www.gnu.org/software/gnuzilla/addons.html
> http://www.mew.org/~kazu/proj/firemacs/en/
>
> And i'm learning conkeror, the emacs way of web browsing ;)


I guess you know the CUA style key bindings etc? And that you know how
to use them and have done it, or?

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> I guess you know the CUA style key bindings etc? And that you know how
> to use them and have done it, or?

FWIW, I know and use CUA bindings much of the day, most days - in Framemaker and
Windows, in particular. I still prefer not to use cua-mode in Emacs. Emacs is
not Framemaker, Word, Windows, DOS,...

Do I bother to switch back and forth like that just because I got in the Emacs
habit? I can't prove the contrary. I admit that I knew Emacs before the others,
and I haven't tried to use Emacs in Viper mode or CUA mode. But I like to think
that I do this switch-dance because Emacs keys fit better with Emacs.

Call it delusion, if you like. Still, it shows that it is possible to walk and
chew gum at the same time. And it's even possible for Emacs newbies to do it -
of that I'm certain. I've even seen them riding bicycles.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Fri, Mar 26, 2010 at 11:23 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> FWIW, I know and use CUA bindings much of the day, most days - in Framemaker and
> Windows, in particular. I still prefer not to use cua-mode in Emacs. Emacs is
> not Framemaker, Word, Windows, DOS,...
>
> Do I bother to switch back and forth like that just because I got in the Emacs
> habit? I can't prove the contrary. I admit that I knew Emacs before the others,
> and I haven't tried to use Emacs in Viper mode or CUA mode. But I like to think
> that I do this switch-dance because Emacs keys fit better with Emacs.

Why not try cua-mode? I was very doubtful myself from the beginning,
but it works surpricingly well IMO.

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> > Do I bother to switch back and forth like that just because 
> > I got in the Emacs habit? I can't prove the contrary. I admit
> > that I knew Emacs before the others, and I haven't tried to
> > use Emacs in Viper mode or CUA mode. But I like to think
> > that I do this switch-dance because Emacs keys fit better 
> > with Emacs.
> 
> Why not try cua-mode?

FWIW, in my own case, about the only time I'm bitten by the switch is that I
sometimes finding myself using `C-s' in Emacs as a reflex to save my work. Or
vice versa: I hit `C-x C-s' in Framemaker and get the message "Nothing to cut".

Oh, and sometimes I hit `C-v' to paste and end up going down a page in Emacs.
But most of the time, even half-asleep on autopilot I get by OK. And for some
reason I never seem to get tripped up by C-c, C-x, or C-z.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Fri, Mar 26, 2010 at 11:44 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>
>> Why not try cua-mode?
>
> Or vice versa: I hit `C-x C-s' in Framemaker and get the message "Nothing to cut".


I often try C-s in Firefox and find the result quite irritating cause
it takes some time for the file save dialog to appear.


> But most of the time, even half-asleep on autopilot I get by OK. And for some
> reason I never seem to get tripped up by C-c, C-x, or C-z.


With the region hilighted you may make those mistakes more often of course.

On the other side with cua-mode on you have to learn using C-S-c and
C-S-x when the region is hilighted. This may be hard in the beginning.
Personally, because I use Viper, I have only been hit by C-x here, but
it happened to me many times. (Maybe since I tend to use computers
when I am tired.)

BTW, is there any strong reason not to bind C-z to `undo' by default in Emacs?

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> > for some reason I never seem to get tripped up by C-c, C-x, or C-z.
> 
> With the region hilighted you may make those mistakes more
> often of course.

Huh? I do have the region highlighted. In Emacs as in other apps.

Re: Tweaking t-m-m to make room for d-s-m

[Christophe Poncy]

On 03/26/2010 11:07 PM, Lennart Borgman wrote:
> On Fri, Mar 26, 2010 at 11:05 PM, Christophe Poncy<cp@canaxis.org>  wrote:
>> On 03/26/2010 10:30 PM, Lennart Borgman wrote:
>>>
>>> It is new users that should be treated with respect. All of them know
>>> these key bindings. All of them use them.
>>
>> FWIW, it's not my case, i use Firemacs on IceCat (free software under the
>> Modified BSD license) :
>>
>> http://www.gnu.org/software/gnuzilla/addons.html
>> http://www.mew.org/~kazu/proj/firemacs/en/
>>
>> And i'm learning conkeror, the emacs way of web browsing ;)
>
>
> I guess you know the CUA style key bindings etc? And that you know how
> to use them and have done it, or?
>

Yes, I know them, but i don't use them for web browsing.

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> >> > 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.

Yes, I mentioned that there is another default binding, C-x C-z.

Either C-z or C-x C-z could be used as the activate/deactivate region toggle.
The former is simpler. Hitting C-z is as easy as hitting C-g (what we do today
to deactivate).

(Oh - is C-z undo in CUA?  Is C-g cancel in Emacs? Hm. Is that a somewhat happy
coincidence? Inquiring minds do not want to know.)

> > 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.)

Treating new users with respect means helping them learn the best ways to be
productive with Emacs. I happen to think that includes d-s-mode but not
cua-mode.

We can respectfully agree to disagree about that. But please do not think you
have a monopoly on respect for new users. Sometimes respect means advising
against what someone feels comfortable with. Call it tough love. ;-)

> > 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.

Yes, and so have some GNU/Linux GUIs accepted them, and lots of other
applications - most even. You are no doubt correct in saying that Emacs stands
pretty much alone in not adopting CUA (or similar).

(There are some non-Emacs applications that have accepted Emacs's main editing
keys. But that is beside the point.)

> 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.)

Since you use Viper, it is understandable that you would get that an alternative
set of bindings for Emacs is possible. Can't argue with that. It is possible.

But I'm not convinced that the only rationale for the current Emacs bindings is
the sorry weight of legacy.

> 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.

Why? Isn't it just as troublesome that C-z means `resume-frame'? The trouble you
would fend off is already here, I fear. It is too late to reserve C-z for
possible future CUA use. Someone got to C-z before you (on Day One).

And if one day Emacs does become CUA by default, do you really think changing
C-z from activate/deactivate the mark to `cut' will be the most difficult part?

> > 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 ;-)

I was referring to the large number of keyboard keys that Emacs uses on a daily
basis. When you have only a few operations to bind, it's easy to give them the
keys that are the handiest to type. 

> 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".

You used the word "accept" (above). Accept/conform/fit/kowtow/appease/support -
pick whatever term you like.

It is about user convenience in _using Emacs_, not just about user convenience
in getting comfortable just being in the same room with Emacs.

It's not only about cozying up to newbies. It's about helping them to become
productive Emacs users.

I, for one, am not convinced that CUA or Viper is the best way to promote Emacs
productivity. But my sample data is small. Just one opinion.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Fri, Mar 26, 2010 at 11:13 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
>> It is new users that should be treated with respect. All of them know
>> these CUA key bindings. All of them use them. (If they are not computer
>> illiterates.)
>
> But please do not think you
> have a monopoly on respect for new users.


I am glad I do not have that ;-)

I just wanted to make the real subject a bit more visible.


> But I'm not convinced that the only rationale for the current Emacs bindings is
> the sorry weight of legacy.


If  it were not for the CUA keys the Emacs bindings were a good
choice. (But I really do recommend sticky keys for those that use
them.)

It is not hard at all to understand the choices. But if CUA keys had
been used before Emacs then I guess Emacs key bindings would have
included them and looked quite a bit different.

I am still all for adding "skins" for this type of change.


> Why? Isn't it just as troublesome that C-z means `resume-frame'?


resume-frame hardly needs such an important (easy to type) key
binding. undo is far more common.


> I, for one, am not convinced that CUA or Viper is the best way to promote Emacs
> productivity.


CUA *and* Viper ;-)

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> If  it were not for the CUA keys the Emacs bindings were a good
> choice...
> 
> It is not hard at all to understand the choices. But if CUA keys had
> been used before Emacs then I guess Emacs key bindings would have
> included them and looked quite a bit different.

There's where I disagree; that is, my guess is different from yours. I tried to
address this by pointing out the large number of keys Emacs makes use of.

Do you really think that, given that need (e.g. for easy to type prefix keys),
Emacs would waste half a dozen of the simplest keys - keys that could and
rightfully should be prefix keys - on operations like cut, copy, paste, find,
and save?

I cannot imagine that if designed today Emacs would make such a design choice.
Those that think CUA mode and Viper are the best ways to use Emacs no doubt see
things differently.

I can say that if I _were_ convinced of that then I would have no trouble
supporting a redesign of the keys we use. If the _only_ reason to keep the
traditional Emacs keys were the silly weight of legacy, then I'd drop my support
for that tradition in a heartbeat.

Since you use CUA mode and Viper, you don't experience the advantage of the
standard Emacs key choices, so that particular comparison is a wash for you. The
gain of fitting in with the rest of the CUA world then tilts the balance - it
becomes the most important consideration.

[BTW - Yes, I recognize that the need for simple prefix keys is an argument for
using `C-z' that way too. And I would support that change - I've even proposed
it in the past, I believe. Until then, C-z for activate/deactivate sounds good
to me.]

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Sat, Mar 27, 2010 at 12:11 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> If  it were not for the CUA keys the Emacs bindings were a good
>> choice...
>>
>> It is not hard at all to understand the choices. But if CUA keys had
>> been used before Emacs then I guess Emacs key bindings would have
>> included them and looked quite a bit different.
>
> Do you really think that, given that need (e.g. for easy to type prefix keys),
> Emacs would waste half a dozen of the simplest keys - keys that could and
> rightfully should be prefix keys - on operations like cut, copy, paste, find,
> and save?

Yes I do. Emacs have single key bindings for the same things as CUA
(except for undo). It is just that they are different.

RE: Tweaking t-m-m to make room for d-s-m

[Drew Adams]

> > Do you really think that, given that need (e.g. for easy to 
> > type prefix keys), Emacs would waste half a dozen of the
> > simplest keys - keys that could and rightfully should be
> > prefix keys - on operations like cut, copy, paste, find,
> > and save?
> 
> Yes I do. Emacs have single key bindings for the same things as
> CUA (except for undo). It is just that they are different.

Oops. You're right about that.

(Tries to extract foot from mouth...)

Re: Tweaking t-m-m to make room for d-s-m

[Richard Stallman]

    > And C-z is currently `suspend-frame' in Emacs.

On a terminal, C-z suspends Emacs and is an important command,.

On window systems, C-z iconifies the frame because I could not think
of any useful operation that was similar in spirit to suspending Emacs.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Sat, Mar 27, 2010 at 11:49 PM, Richard Stallman <rms@gnu.org> wrote:
>    > And C-z is currently `suspend-frame' in Emacs.
>
> On a terminal, C-z suspends Emacs and is an important command,.

Thanks, I forgot. But is there any good reason to use C-z also on
window systems? Why not let it be undo there since that is the most
common use (as far as I know)?

Re: Tweaking t-m-m to make room for d-s-m

[Deniz Dogan]

2010/3/28 Lennart Borgman <lennart.borgman@gmail.com>:
> On Sat, Mar 27, 2010 at 11:49 PM, Richard Stallman <rms@gnu.org> wrote:
>>    > And C-z is currently `suspend-frame' in Emacs.
>>
>> On a terminal, C-z suspends Emacs and is an important command,.
>
> Thanks, I forgot. But is there any good reason to use C-z also on
> window systems? Why not let it be undo there since that is the most
> common use (as far as I know)?
>
>
>

Emacs users on Windows systems may like the fact that the bindings are
consistent, so that they can use the same .emacs independent of the
operating system.

-- 
Deniz Dogan

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Sun, Mar 28, 2010 at 12:37 AM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote:
> 2010/3/28 Lennart Borgman <lennart.borgman@gmail.com>:
>> On Sat, Mar 27, 2010 at 11:49 PM, Richard Stallman <rms@gnu.org> wrote:
>>>    > And C-z is currently `suspend-frame' in Emacs.
>>>
>>> On a terminal, C-z suspends Emacs and is an important command,.
>>
>> Thanks, I forgot. But is there any good reason to use C-z also on
>> window systems? Why not let it be undo there since that is the most
>> common use (as far as I know)?
>>
>>
>>
>
> Emacs users on Windows systems may like the fact that the bindings are
> consistent, so that they can use the same .emacs independent of the
> operating system.


Yes, of course. But what do you mean? Is that in an argument against
using C-z for `undo´? Is there any kind of conflict?

If so then perhaps it could be resolved by having one set of key
bindings for terminal users and one for GUI users? (An idea we have
been discussing before.)

Re: Tweaking t-m-m to make room for d-s-m

[Deniz Dogan]

2010/3/28 Lennart Borgman <lennart.borgman@gmail.com>:
> Yes, of course. But what do you mean? Is that in an argument against
> using C-z for `undo´? Is there any kind of conflict?
>

I'm sorry, I misread your original message. I thought you were talking
about MS Windows-specific key bindings...

-- 
Deniz Dogan

Re: Tweaking t-m-m to make room for d-s-m

[Richard Stallman]

    Thanks, I forgot. But is there any good reason to use C-z also on
    window systems? Why not let it be undo there since that is the most
    common use (as far as I know)?

Undo can be done under X windows using C-/, which is just as easy
to type as C-z.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Tue, Mar 30, 2010 at 1:38 AM, Richard Stallman <rms@gnu.org> wrote:
>    Thanks, I forgot. But is there any good reason to use C-z also on
>    window systems? Why not let it be undo there since that is the most
>    common use (as far as I know)?
>
> Undo can be done under X windows using C-/, which is just as easy
> to type as C-z.


No, I do not think so for several reasons:

- It is not as easy to type for `undo' if your are used to using C-z for that.

- It is not necessarily as easy to type on an international keyboard.

Re: Tweaking t-m-m to make room for d-s-m

[Christoph]

On 3/29/2010 6:08 PM, Lennart Borgman wrote:
> On Tue, Mar 30, 2010 at 1:38 AM, Richard Stallman<rms@gnu.org>  wrote:
>    
>>
>> Undo can be done under X windows using C-/, which is just as easy
>> to type as C-z.
>>      
> No, I do not think so for several reasons:
>
> - It is not as easy to type for `undo' if your are used to using C-z for that.
>    
Oh yes, once in a while you see me cursing at the computer thinking I 
accidently closed it but I just hit C-z...
> - It is not necessarily as easy to type on an international keyboard
I can confirm this. On a German keyboard layout I actually use C-_ over 
C-\, which is way easier. On the other hand, the Y and Z are also 
switched, so C-z is imho only nice on a US layout.

Christoph

Re: Tweaking t-m-m to make room for d-s-m

[Richard Stallman]

    - It is not as easy to type for `undo' if your are used to using C-z for that.

C-z has never been an undo command in Emacs
so Emacs users are not used to typing C-z for that.

Re: Tweaking t-m-m to make room for d-s-m

[Lennart Borgman]

On Tue, Mar 30, 2010 at 7:31 AM, Richard Stallman <rms@gnu.org> wrote:
>    - It is not as easy to type for `undo' if your are used to using C-z for that.
>
> C-z has never been an undo command in Emacs
> so Emacs users are not used to typing C-z for that.

That conclusion is not valid.

I think most Emacs users are today at least using also a web browser
where C-z means undo while editing.

Re: Tweaking t-m-m to make room for d-s-m

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 30 Mar 2010 08:38:18 +0200
> Cc: mathias@mnet-mail.de, dak@gnu.org, monnier@iro.umontreal.ca,
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> 
> On Tue, Mar 30, 2010 at 7:31 AM, Richard Stallman <rms@gnu.org> wrote:
> >    - It is not as easy to type for `undo' if your are used to using C-z for that.
> >
> > C-z has never been an undo command in Emacs
> > so Emacs users are not used to typing C-z for that.
> 
> That conclusion is not valid.
> 
> I think most Emacs users are today at least using also a web browser
> where C-z means undo while editing.

Which doesn't necessarily mean they want it in Emacs.  At least for
me, C-z scrolls the window by one line:

 (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))

I use this in Emacs by far more often than `undo'.

Re: Tweaking t-m-m to make room for d-s-m

[Chad Brown]

>>>    - It is not as easy to type for `undo' if your are used to using C-z for that.
>>> 
>>> C-z has never been an undo command in Emacs
>>> so Emacs users are not used to typing C-z for that.
>> 
>> That conclusion is not valid.
>> 
>> I think most Emacs users are today at least using also a web browser
>> where C-z means undo while editing.
> 
> Which doesn't necessarily mean they want it in Emacs.  At least for
> me, C-z scrolls the window by one line:
> 
> (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))
> 
> I use this in Emacs by far more often than `undo'.

Can we at least agree that default keybindings are more likely intended
for new users than for dedicated emacs hackers?  

Personally, I bind control-z to a keymap of customized bindings/functions,
but that doesn't mean that I don't see at least *some* value in making it
match typical keybindings in basically every OS/UI currently used.

I would suggest that this change is too deep for an emacs 23 point release,
though.  If we can get a workable `upgrade system' (currently being
discussed in another thread) for dealing with new features in place for
emacs 24, that seems like a better time to consider defaults like CUA
bindings, don't you think?

*Chad

Re: Tweaking t-m-m to make room for d-s-m

[Lluís]

> No, I do not think so for several reasons:

> - It is not as easy to type for `undo' if your are used to using C-z for that.

> - It is not necessarily as easy to type on an international keyboard.

I think the latter is a real pain on most "keyboard-intensive" editors, as much
of their bindings were designed with an english keyboard in mind.

Thus I think that trying to get away from "special" characters (which I think
show the greater "position variance" across layouts) in commonly used commands
is a good thing if you want to homogenize "comfort" across different keyboard
layouts.

Of course, such kinds of changes are always disruptive, but probably also
decrease the chance of users changing those to bindings that might collide with
other already-existing modules.

--
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

d-s-m default: t

[Noah Friedman]

Provided you intend to make this change for Emacs 24, not Emacs 23.