CUA mode cursor color

CUA mode cursor color

[Miles Bader]

I turned on CUA mode to check it out, and noticed that in addition to
the behavior I expected -- C-x/C-c/C-v cut 'n' paste -- it also changed
my cursor color.

After searching a bit, I found the following in cua-mode.el:

   ;; CUA mode indications
   ;; --------------------
   ;; You can choose to let CUA use different cursor colors to indicate
   ;; overwrite mode and read-only buffers.

[This is apparently on by default too.]

Is there a reason this is part of CUA mode?  Even if it's a nice feature
(and I suppose it is, I was just surprised by it), it seems orthogonal
to the main functionality of CUA mode.

Why not move this stuff into a separate mode -- then people who don't
want CUA mode can use it, and people who just want CUA mode won't have
to go investigate why their cursor color keeps changing.

-Miles

p.s. I was very impressed by how smoothly cua-mode manages to integrate
the seemingly incompatible CUA keybindings into emacs!
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: CUA mode cursor color

[Miles Bader]

A few more comments about CUA mode:

  1. Using `M-x cua-mode' doesn't print a message in the mode-line,
     whereas using the menu option does.  Why not always print a message
     (many other mode toggles do, and they probably all should), and make
     the menu option and `M-x cua-mode' exactly the same?

  2. If you have transient-mark-mode enabled, turning on cua-mode and
     then turning it off again leaves transient-mark-mode disabled; it
     would be much better to leave it in whatever state it was in
     originally.  I'm not sure the best way to implement this.

  3. In the NEWS file, it says:

         With cua, the region can be set and extended using shifted
         movement keys (like pc-selection-mode) and typed text replaces
         the active region (like delete-selection-mode).  Do not enable
         these modes with cua-mode.

     It would be nice if `pc-selection-mode' and `delete-selection-mode'
     simply used the same code that cua-mode does, so that they are more
     compatible (after all, it's not unlikely that a potential user of
     CUA mode already has one or both of them enabled, and might not see
     the warning in NEWS).

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: CUA mode cursor color

[Ehud Karni]

On 13 May 2002 10:16:51 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:
> 
> I turned on CUA mode to check it out, and noticed that in addition to
> the behavior I expected -- C-x/C-c/C-v cut 'n' paste -- it also changed
> my cursor color.
> 
> After searching a bit, I found the following in cua-mode.el:
> 
>    ;; CUA mode indications
>    ;; --------------------
>    ;; You can choose to let CUA use different cursor colors to indicate
>    ;; overwrite mode and read-only buffers.
> 
> Why not move this stuff into a separate mode -- then people who don't
> want CUA mode can use it, and people who just want CUA mode won't have
> to go investigate why their cursor color keeps changing.

I second that.

I don't use CUA mode, and I have my own implementation of cursor colors
(my implementation is in lisp). I noticed that the hollow cursor (in an
inactive buffer) changes its color to the active cursor color.

Can anybody fix this and make the cursor-color a buffer local ?

Ehud.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.simonwiesel.co.il          Better  Safe  Than  Sorry

Re: CUA mode cursor color

[Stefan Monnier]

>      It would be nice if `pc-selection-mode' and `delete-selection-mode'
>      simply used the same code that cua-mode does, so that they are more
>      compatible (after all, it's not unlikely that a potential user of
>      CUA mode already has one or both of them enabled, and might not see
>      the warning in NEWS).

Just like the issue with cursor color, cua-mode needs to be othogonalized
and better integrated into the rest of Emacs.  I'd really like to see
some of cua-rect's code&behavior to be part of the defaults.
E.g. C-x r SPC with transient-mark-mode ON should highlight the
rectangle and C-w/M-w should then operate on that rectangle.


	Stefan

Re: CUA mode cursor color

[Juanma Barranquero]

On 13 May 2002 10:35:58 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:

>   3. In the NEWS file, it says:
> 
>          With cua, the region can be set and extended using shifted
>          movement keys (like pc-selection-mode) and typed text replaces
>          the active region (like delete-selection-mode).  Do not enable
>          these modes with cua-mode.

windmove.el should be added as well to that warning. Its default
keybinding uses shift-{left,right,down,up} to switch windows.

                                                           /L/e/k/t/u

Re: CUA mode cursor color

[Richard Stallman]

    Why not move this stuff into a separate mode -- then people who don't
    want CUA mode can use it, and people who just want CUA mode won't have
    to go investigate why their cursor color keeps changing.

I agree.

Re: CUA mode cursor color

[Richard Stallman]

      1. Using `M-x cua-mode' doesn't print a message in the mode-line,
	 whereas using the menu option does.  Why not always print a message
	 (many other mode toggles do, and they probably all should), and make
	 the menu option and `M-x cua-mode' exactly the same?

There is a possible problem with making these toggles display a
message inthe echo area: Lisp programs may want to call them, and
often it is inappropriate to print messages in those cases.

Long ago, every minor mode was supposed to be controlled by a
variable.  Lisp programs could set or bind the variable, so there was
no reason to call a toggle function.  But this is not true in general
any more.

At present, we have turn-on-X-mode functions for some minor modes, and
variables you can set or bind for other minor modes.  And there may be
some cases which have neither one.  It is a confusing situation.
I wonder if we can straighten it out.

Re: CUA mode cursor color

[Richard Stallman]

      2. If you have transient-mark-mode enabled, turning on cua-mode and
	 then turning it off again leaves transient-mark-mode disabled; it
	 would be much better to leave it in whatever state it was in
	 originally.  I'm not sure the best way to implement this.

It would be nice, but I think it is impossible to find a way to handle
this that gives in all cases the result that you would consider
correct.  It is a problem similar to the "restore the previous window
state" problem: every possible method is right for some scenarios but
not for all.

	 It would be nice if `pc-selection-mode' and `delete-selection-mode'
	 simply used the same code that cua-mode does, so that they are more
	 compatible (after all, it's not unlikely that a potential user of
	 CUA mode already has one or both of them enabled, and might not see
	 the warning in NEWS).

Is it feasible for CUA to use pc-selection-mode and delete-selection-mode?
That would be nice, but I'd guess there would be some sort of problem.

Another approach would be to replace pc-selection-mode and
delete-selection-mode with new code designed to work with CUA (perhaps
copied partially from CUA).

delsel.el is a very small file.  Please don't replace it with something
that has to load all of CUA.

Re: CUA mode cursor color

[Richard Stallman]

    E.g. C-x r SPC with transient-mark-mode ON should highlight the
    rectangle and C-w/M-w should then operate on that rectangle.

Built-in rectangle region support would be a very good thing to add.

Re: CUA mode cursor color

[Stefan Monnier]

>       1. Using `M-x cua-mode' doesn't print a message in the mode-line,
> 	 whereas using the menu option does.  Why not always print a message
> 	 (many other mode toggles do, and they probably all should), and make
> 	 the menu option and `M-x cua-mode' exactly the same?
> 
> There is a possible problem with making these toggles display a
> message inthe echo area: Lisp programs may want to call them, and
> often it is inappropriate to print messages in those cases.

If you use define-minor-mode, then the resulting code emits
a message if called interactively.  That should work for menubar
invocation as well as for M-x without impacting direct calls
from Lisp programs.

> At present, we have turn-on-X-mode functions for some minor modes, and
> variables you can set or bind for other minor modes.  And there may be
> some cases which have neither one.  It is a confusing situation.
> I wonder if we can straighten it out.

The way I see it, the only standard part is (minor-mode 1) to turn
it on and (minor-mode -1) to turn it off.

I dislike the turn-on-X-mode things because they're just redundant.
Luckily, they can be ignored.


	Stefan

Re: CUA mode cursor color

[Sam Steingold]

> * In message <200205131710.g4DHA1t07920@rum.cs.yale.edu>
> * On the subject of "Re: CUA mode cursor color "
> * Sent on Mon, 13 May 2002 13:10:00 -0400
> * Honorable "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
>
> I dislike the turn-on-X-mode things because they're just redundant.

IIUC, they are needed for hooks: if you put turn-on-X-mode into a hook,
you know you will get the X-mode, but if you put X-mode (which just
toggles) there, you might or might not get it, depending on whether
X was turned on in the mode definition or in another function added to
the hook.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
Don't use force -- get a bigger hammer.

Re: CUA mode cursor color

[Stefan Monnier]

> > I dislike the turn-on-X-mode things because they're just redundant.
> IIUC, they are needed for hooks: if you put turn-on-X-mode into a hook,
> you know you will get the X-mode, but if you put X-mode (which just
> toggles) there, you might or might not get it, depending on whether
> X was turned on in the mode definition or in another function added to
> the hook.

(add-hook 'foo-hook (lambda () (mode-X 1)))

only takes 7 more chars than your alternative.
Furthermore, although I know that some people are staunchly opposed
to it, I think that calling (X-mode) with no argument non-interactively
should behave exactly like turn-on-X-mode so that people can just
say (add-hook 'foo-hook 'mode-X) and so that people who already
(incorrectly) do that don't get into trouble.


	Stefan

Re: CUA mode cursor color

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I turned on CUA mode to check it out, and noticed that in addition to
> the behavior I expected -- C-x/C-c/C-v cut 'n' paste -- it also changed
> my cursor color.
> 
> After searching a bit, I found the following in cua-mode.el:
> 
>    ;; CUA mode indications
>    ;; --------------------
>    ;; You can choose to let CUA use different cursor colors to indicate
>    ;; overwrite mode and read-only buffers.
> 
> [This is apparently on by default too.]

Oops.  That's unintentional -- it should be off by default.  I'll fix that.


> 
> Is there a reason this is part of CUA mode?  Even if it's a nice feature
> (and I suppose it is, I was just surprised by it), it seems orthogonal
> to the main functionality of CUA mode.

There are two reasons:

- the rectangle code uses different cursor colors to indicate padding
  on/off.

- the cursor color and blink frequency changes when the global mark is
  active.

Personally, I found it difficult to separate this from a general
control of the cursor color based on insert/overwrite/read-only
status.

> 
> Why not move this stuff into a separate mode -- then people who don't
> want CUA mode can use it, and people who just want CUA mode won't have
> to go investigate why their cursor color keeps changing.

If someone like to work on this, feel welcome to rip out the code from
cua-base.el (or write something else).

Remember to make it possible for other packages to link their own
cursor color controls into it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode cursor color

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I turned on CUA mode to check it out, and noticed that in addition to
> the behavior I expected -- C-x/C-c/C-v cut 'n' paste -- it also changed
> my cursor color.
> 
> After searching a bit, I found the following in cua-mode.el:
> 
>    ;; CUA mode indications
>    ;; --------------------
>    ;; You can choose to let CUA use different cursor colors to indicate
>    ;; overwrite mode and read-only buffers.
> 
> [This is apparently on by default too.]

Oops.  That's unintentional -- it should be off by default.  I'll fix that.


> 
> Is there a reason this is part of CUA mode?  Even if it's a nice feature
> (and I suppose it is, I was just surprised by it), it seems orthogonal
> to the main functionality of CUA mode.

There are two reasons:

- the rectangle code uses different cursor colors to indicate padding
  on/off.

- the cursor color and blink frequency changes when the global mark is
  active.

Personally, I found it difficult to separate this from a general
control of the cursor color based on insert/overwrite/read-only
status.

> 
> Why not move this stuff into a separate mode -- then people who don't
> want CUA mode can use it, and people who just want CUA mode won't have
> to go investigate why their cursor color keeps changing.

If someone like to work on this, feel welcome to rip out the code from
cua-base.el (or write something else).

Remember to make it possible for other packages to link their own
cursor color controls into it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode cursor color

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I turned on CUA mode to check it out, and noticed that in addition to
> the behavior I expected -- C-x/C-c/C-v cut 'n' paste -- it also changed
> my cursor color.
> 
> After searching a bit, I found the following in cua-mode.el:
> 
>    ;; CUA mode indications
>    ;; --------------------
>    ;; You can choose to let CUA use different cursor colors to indicate
>    ;; overwrite mode and read-only buffers.
> 
> [This is apparently on by default too.]

Oops.  That's unintentional -- it should be off by default.  I'll fix that.


> 
> Is there a reason this is part of CUA mode?  Even if it's a nice feature
> (and I suppose it is, I was just surprised by it), it seems orthogonal
> to the main functionality of CUA mode.

There are two reasons:

- the rectangle code uses different cursor colors to indicate padding
  on/off.

- the cursor color and blink frequency changes when the global mark is
  active.

Personally, I found it difficult to separate this from a general
control of the cursor color based on insert/overwrite/read-only
status.

> 
> Why not move this stuff into a separate mode -- then people who don't
> want CUA mode can use it, and people who just want CUA mode won't have
> to go investigate why their cursor color keeps changing.

If someone like to work on this, feel welcome to rip out the code from
cua-base.el (or write something else).

Remember to make it possible for other packages to link their own
cursor color controls into it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode cursor color

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> A few more comments about CUA mode:
> 
>   1. Using `M-x cua-mode' doesn't print a message in the mode-line,
>      whereas using the menu option does.  Why not always print a message
>      (many other mode toggles do, and they probably all should), and make
>      the menu option and `M-x cua-mode' exactly the same?

Will fix that.

> 
>   2. If you have transient-mark-mode enabled, turning on cua-mode and
>      then turning it off again leaves transient-mark-mode disabled; it
>      would be much better to leave it in whatever state it was in
>      originally.  I'm not sure the best way to implement this.

Good idea.  I'll do that.

> 
>   3. In the NEWS file, it says:
> 
>          With cua, the region can be set and extended using shifted
>          movement keys (like pc-selection-mode) and typed text replaces
>          the active region (like delete-selection-mode).  Do not enable
>          these modes with cua-mode.
> 

I have added code which disables these modes when cua-mode is enabled
and reenable them if cua-mode is disabled.

>      It would be nice if `pc-selection-mode' and `delete-selection-mode'
>      simply used the same code that cua-mode does, so that they are more
>      compatible (after all, it's not unlikely that a potential user of
>      CUA mode already has one or both of them enabled, and might not see
>      the warning in NEWS).

This is true -- but there are other packages in emacs which overlap
in functionality, so I guess it is ok to have these as separate
packages. 

But it should not be possible to enable them if cua-mode is enabled.

One way to accomplish thati is directly in the delete-selection-mode
and pc-selection-mode functions, but I don't know if that is really
possible with define-minor-mode.

Another possibility would be to defadvice those functions in cua-base,
but can you defadvice a function which isn't (auto)loaded yet [I
definitely don't want to load it just to defadvice it].

Any suggestions?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode cursor color

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> >      It would be nice if `pc-selection-mode' and `delete-selection-mode'
> >      simply used the same code that cua-mode does, so that they are more
> >      compatible (after all, it's not unlikely that a potential user of
> >      CUA mode already has one or both of them enabled, and might not see
> >      the warning in NEWS).
> 
> Just like the issue with cursor color, cua-mode needs to be othogonalized
> and better integrated into the rest of Emacs.  I'd really like to see
> some of cua-rect's code&behavior to be part of the defaults.
> E.g. C-x r SPC with transient-mark-mode ON should highlight the
> rectangle and C-w/M-w should then operate on that rectangle.

I'd like cua-rect.el to be the default too :-)

PS:  What do you think about the integrated register support?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode cursor color

[Kim F. Storm]

"Ehud Karni" <ehud@unix.simonwiesel.co.il> writes:

> On 13 May 2002 10:16:51 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:
> > 
> > I turned on CUA mode to check it out, and noticed that in addition to
> > the behavior I expected -- C-x/C-c/C-v cut 'n' paste -- it also changed
> > my cursor color.
> > 
> > After searching a bit, I found the following in cua-mode.el:
> > 
> >    ;; CUA mode indications
> >    ;; --------------------
> >    ;; You can choose to let CUA use different cursor colors to indicate
> >    ;; overwrite mode and read-only buffers.
> > 
> > Why not move this stuff into a separate mode -- then people who don't
> > want CUA mode can use it, and people who just want CUA mode won't have
> > to go investigate why their cursor color keeps changing.
> 
> I second that.
> 
> I don't use CUA mode, and I have my own implementation of cursor colors
> (my implementation is in lisp).

cua's cursor color control is also in lisp.

> I noticed that the hollow cursor (in an
> inactive buffer) changes its color to the active cursor color.
> 
> Can anybody fix this and make the cursor-color a buffer local ?

This sounds like a good idea...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode cursor color

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Another possibility would be to defadvice those functions in cua-base,
> but can you defadvice a function which isn't (auto)loaded yet [I
> definitely don't want to load it just to defadvice it].

Also, you shouldn't use defadvice in code that's part of emacs.

-Miles
-- 
We live, as we dream -- alone....

Re: CUA mode cursor color

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>       Why not always print a message (many other mode toggles do, and
> 	they probably all should), and make the menu option and `M-x
> 	cua-mode' exactly the same?
> 
> There is a possible problem with making these toggles display a
> message inthe echo area: Lisp programs may want to call them, and
> often it is inappropriate to print messages in those cases.

Stefen's suggestion, to do the same as modes defined `define-minor-mode',
and print a message if (interactive-p) is true, seems reasonable.

-Miles
-- 
Run away!  Run away!

Re: CUA mode cursor color

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:

>       If you have transient-mark-mode enabled, turning on cua-mode and
> 	then turning it off again leaves transient-mark-mode disabled;
> 	it would be much better to leave it in whatever state it was in
> 	originally.
> 
> It would be nice, but I think it is impossible to find a way to handle
> this that gives in all cases the result that you would consider
> correct.

Maybe it's a hard problem in general, but it doesn't seem hard to do a
very good job in this case:

  cua-mode can record whether transient-mark-mode was enabled when it
  was turned on, by setting variable `cua-mode-tmm-was-enabled' to t.
  Then when cua-mode is turned off, only disable transient-mark-mode if
  `cua-mode-tmm-was-enabled' is nil (otherwise, just do nothing).

This only fails in the most bizarre of cases; for instance:
if t-m-m is disabled, and the user turns on cua-mode, and then turns off
t-m-m and then turns t-m-m back on, and somehow expects it to then
`stick' if he subsequently turns off cua-mode.  This seems like a very
unlikely scenario.

A bigger problem would be if multiple modes (including cua-mode) try to
turn on t-m-m for their own usage; then things would probably get hairy.
Currently this doesn't seem to be the case (and if this happens, we
could just design some mechanism to deal with it, e.g., ref-counting
uses of t-m-m).

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: CUA mode cursor color

[Alex Schroeder]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> I dislike the turn-on-X-mode things because they're just redundant.
> Luckily, they can be ignored.

They are simpler to add to hooks than (lambda () (X-mode 1)).

Alex
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: CUA mode cursor color

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> - the rectangle code uses different cursor colors to indicate padding
>   on/off.
> 
> - the cursor color and blink frequency changes when the global mark is
>   active.

I gotta say, putting so many different meanings onto cursor-color seems
pretty cryptic...

> Personally, I found it difficult to separate this from a general
> control of the cursor color based on insert/overwrite/read-only
> status.

Well, as you say below, a separate mode could provide hooks that other
modes could call to attach their own colors too (though I'd tend to
discourage this in all but the most obvious cases).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: CUA mode cursor color

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> (add-hook 'foo-hook (lambda () (mode-X 1)))
>
> only takes 7 more chars than your alternative.

It's bad for people (users) who use Custom.

kai
-- 
Silence is foo!

Re: CUA mode cursor color

[Stefan Monnier]

> > (add-hook 'foo-hook (lambda () (mode-X 1)))
> > only takes 7 more chars than your alternative.
> It's bad for people (users) who use Custom.

Huh?  In what scenario?


	Stefan

Re: CUA mode cursor color

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> > It's bad for people (users) who use Custom.
> 
> Huh?  In what scenario?

I presume he's talking about places where it lets you add to hooks, and
that something like turn-on-auto-fill is `straightforward' whereas
`(lambda ()...)' is `confusing'.  There's probably something to that.

On the other hand most people will probably (incorrectly) use
`auto-fill-mode' in such situations anyway...

[personally I think your proposal to change the meaning of a
non-interactive `nil' argument to be `on' instead of `toggle' is
actually the best solution...]

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: CUA mode cursor color

[Kai Großjohann]

Miles Bader <miles@gnu.org> writes:

> "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
>> > It's bad for people (users) who use Custom.
>> 
>> Huh?  In what scenario?
>
> I presume he's talking about places where it lets you add to hooks, and
> that something like turn-on-auto-fill is `straightforward' whereas
> `(lambda ()...)' is `confusing'.  There's probably something to that.

That's what I meant.

> On the other hand most people will probably (incorrectly) use
> `auto-fill-mode' in such situations anyway...

Quite possibly.

> [personally I think your proposal to change the meaning of a
> non-interactive `nil' argument to be `on' instead of `toggle' is
> actually the best solution...]

Not a bad idea.

kai
-- 
Silence is foo!

Re: CUA mode cursor color

[Richard Stallman]

    If you use define-minor-mode, then the resulting code emits
    a message if called interactively.  That should work for menubar
    invocation as well as for M-x without impacting direct calls
    from Lisp programs.

We could make that the convention and change all the toggles
to do it that way.

    I dislike the turn-on-X-mode things because they're just redundant.
    Luckily, they can be ignored.

One reason they are useful is that you can call them easily
from hooks.  In the context of a hook, you can't pass an argument.
To use the toggle, you'd have to wrap it in a lambda.

Re: CUA mode cursor color

[Richard Stallman]

    Stefen's suggestion, to do the same as modes defined `define-minor-mode',
    and print a message if (interactive-p) is true, seems reasonable.

Is interactive-p the right method?  Usually it is the wrong predicate,
because it returns nil for commands run from a keyboard macro, and in
most cases those commands should behave like commands run directly
from the keyboard.  For this specific purpose, though, that behavior
might be the right behavior.  Does everyone agree this is the
predicate to test?

If so, would someone like to modify these modes?

Re: CUA mode cursor color

[Richard Stallman]

    This only fails in the most bizarre of cases; for instance:
    if t-m-m is disabled, and the user turns on cua-mode, and then turns off
    t-m-m and then turns t-m-m back on, and somehow expects it to then
    `stick' if he subsequently turns off cua-mode.  This seems like a very
    unlikely scenario.

What if t-m-m was enabled, and the user enables cua-mode, disables
t-m-m, then disables cua-mode?  Should that reenable t-m-m?

Is the suggestion that cua-mode would only disable t-m-m, never
reenable it?  I guess that is safe enough.

Re: CUA mode cursor color

[Richard Stallman]

    I'd like cua-rect.el to be the default too :-)

Could you tell me what feature it provides?

Re: CUA mode cursor color

[Richard Stallman]

    > I dislike the turn-on-X-mode things because they're just redundant.
    > Luckily, they can be ignored.

    They are simpler to add to hooks than (lambda () (X-mode 1)).

That is especially true for beginners.

Re: CUA mode cursor color

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I'd like cua-rect.el to be the default too :-)
> 
> Could you tell me what feature it provides?

- Rectangle highlighting

- rectangles are not confined to actual line lengths, e.g.
  if the buffer contains lines like this (X marks the position
  of the cursor

             aaaaaaaaa
            bbbbbbbbbbbbbbb
         cccccccccccc
              dddddX

  it is possible (straight-forward) to mark a rectangle like this
  (where the +'s marks the corners of the rectangle

           + aaaaaaaaa +
            bbbbbbbbbbbbbbb
         cccccccccccc
           +  dddddX   +

  i.e. the rectangle can be wider than the length of the line
  where the cursor is located (the lower right corner above).

- rectangles are killed, copied and yanked using C-w, M-w, and C-y.

- to upcase/lowercase a rectangle, use M-u/M-l

- to "open" or "close" a rectangle, use M-o/M-c

- M-r does replace-regexp in the rectangle

For more information, see the commentary in emulation/cua-base.el

To try it out, just enable CUA mode on the Options menu, and
mark a rectangle using S-RET.

Re: CUA mode cursor color

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     This only fails in the most bizarre of cases; for instance:
>     if t-m-m is disabled, and the user turns on cua-mode, and then turns off
>     t-m-m and then turns t-m-m back on, and somehow expects it to then
>     `stick' if he subsequently turns off cua-mode.  This seems like a very
>     unlikely scenario.
> 
> What if t-m-m was enabled, and the user enables cua-mode, disables
> t-m-m, then disables cua-mode?  Should that reenable t-m-m?

If you enable cua-mode via the Options menu, notice that the menu item
for transient mark mode becomes inactive, ie.  the user cannot easily
change the setting of transient-mark-mode while cua-mode is
enabled...

BTW, cua-mode selectively enables and disables t-m-m depending on
its state, e.g. if you mark a rectangle, t-m-m is disabled, since
cua does its own rectangle highlighting.

> 
> Is the suggestion that cua-mode would only disable t-m-m, never
> reenable it?  I guess that is safe enough.

I think it is safer to restore the value of t-m-m that was active
before cua-mode was enabled.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode cursor color

[Richard Stallman]

    If you enable cua-mode via the Options menu, notice that the menu item
    for transient mark mode becomes inactive, ie.  the user cannot easily
    change the setting of transient-mark-mode while cua-mode is
    enabled...

He could do it with M-x transient-mark-mode.  So perhaps you should
change that command so that it gets an error if CUA mode is enabled.
It seems like a good idea to do that.

With that change, it is clearly a good idea to restore the value of
transient-mark-mode when exiting cua-mode.