change cursor type when idle

change cursor type when idle

[Drew Adams]

Another possible (minor) feature to consider for after the release: As an
option, let users switch cursor type automatically when Emacs is idle.

I've been using this for a while, and I like it. I like a bar cursor for
editing, but the bar cursor is hard to locate, when I'm not already looking
at it or near it. So, I use an idle timer to change it to a (blinking) box
cursor while Emacs is idle. I find this helps quite a bit - without it, it's
hard to use a bar cursor, IMO.

Users can choose not to use this, and they can toggle it on and off. They
can also change the number of seconds to wait before the automatic
cursor-type change (2 sec, by default).

Re: change cursor type when idle

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

> Another possible (minor) feature to consider for after the release: As an
> option, let users switch cursor type automatically when Emacs is idle.
>
> I've been using this for a while, and I like it. I like a bar cursor for
> editing, but the bar cursor is hard to locate, when I'm not already looking
> at it or near it. So, I use an idle timer to change it to a (blinking) box
> cursor while Emacs is idle. I find this helps quite a bit - without it, it's
> hard to use a bar cursor, IMO.
>
> Users can choose not to use this, and they can toggle it on and off. They
> can also change the number of seconds to wait before the automatic
> cursor-type change (2 sec, by default).

Brilliant idea!

Here's one way to do it.

If people don't like a blinking cursor normally, they just have to define
blink-cursor-delay to the same value as blink-cursor-idle-cursor-delay.


*** frame.el	22 Aug 2006 08:59:52 +0200	1.239
--- frame.el	28 Aug 2006 11:49:02 +0200	
***************
*** 1244,1249 ****
--- 1244,1259 ----
    :type 'number
    :group 'cursor)
  
+ (defcustom blink-cursor-idle-cursor-delay 5.0
+   "*Seconds of idle time after which cursor changes shape."
+   :type 'number
+   :group 'cursor)
+ 
+ (defcustom blink-cursor-idle-cursor-type 'box
+   "*Type of cursor which idle cursor changes shape into."
+   :type 'number
+   :group 'cursor)
+ 
  (defvar blink-cursor-idle-timer nil
    "Timer started after `blink-cursor-delay' seconds of Emacs idle time.
  The function `blink-cursor-start' is called when the timer fires.")
***************
*** 1253,1258 ****
--- 1263,1271 ----
  This timer calls `blink-cursor-timer-function' every
  `blink-cursor-interval' seconds.")
  
+ (defvar blink-cursor-saved-cursor-type nil
+   "Saved type of cursor if changed.")
+ 
  (defun blink-cursor-start ()
    "Timer function called from the timer `blink-cursor-idle-timer'.
  This starts the timer `blink-cursor-timer', which makes the cursor blink
***************
*** 1261,1267 ****
    (when (null blink-cursor-timer)
      ;; Set up the timer first, so that if this signals an error,
      ;; blink-cursor-end is not added to pre-command-hook.
!     (setq blink-cursor-timer
  	  (run-with-timer blink-cursor-interval blink-cursor-interval
  			  'blink-cursor-timer-function))
      (add-hook 'pre-command-hook 'blink-cursor-end)
--- 1274,1281 ----
    (when (null blink-cursor-timer)
      ;; Set up the timer first, so that if this signals an error,
      ;; blink-cursor-end is not added to pre-command-hook.
!     (setq blink-cursor-saved-cursor-type nil
! 	  blink-cursor-timer
  	  (run-with-timer blink-cursor-interval blink-cursor-interval
  			  'blink-cursor-timer-function))
      (add-hook 'pre-command-hook 'blink-cursor-end)
***************
*** 1269,1274 ****
--- 1283,1296 ----
  
  (defun blink-cursor-timer-function ()
    "Timer function of timer `blink-cursor-timer'."
+   (if (and (not blink-cursor-saved-cursor-type)
+ 	   blink-cursor-idle-cursor-type
+ 	   (not (equal cursor-type blink-cursor-idle-cursor-type))
+ 	   (numberp blink-cursor-idle-cursor-delay)
+ 	   (>= (float-time (or (current-idle-time) '(0 0)))
+ 	      blink-cursor-idle-cursor-delay))
+       (setq blink-cursor-saved-cursor-type cursor-type
+ 	    cursor-type blink-cursor-idle-cursor-type))
    (internal-show-cursor nil (not (internal-show-cursor-p))))
  
  (defun blink-cursor-end ()
***************
*** 1277,1282 ****
--- 1299,1308 ----
  When run, it cancels the timer `blink-cursor-timer' and removes
  itself as a pre-command hook."
    (remove-hook 'pre-command-hook 'blink-cursor-end)
+   (when blink-cursor-saved-cursor-type
+     (if (eq blink-cursor-idle-cursor-type cursor-type)
+ 	(setq cursor-type blink-cursor-saved-cursor-type))
+     (setq blink-cursor-saved-cursor-type nil))
    (internal-show-cursor nil t)
    (when blink-cursor-timer
      (cancel-timer blink-cursor-timer)

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

RE: change cursor type when idle

[Drew Adams]

    > Another possible (minor) feature to consider for after the
    > release: As an option, let users switch cursor type
    > automatically when Emacs is idle.
    >
    > I've been using this for a while, and I like it. I like a bar
    > cursor for editing, but the bar cursor is hard to locate,
    > when I'm not already looking at it or near it. So, I use an
    > idle timer to change it to a (blinking) box cursor while
    > Emacs is idle. I find this helps quite a bit - without it,
    > it's hard to use a bar cursor, IMO.
    >
    > Users can choose not to use this, and they can toggle it on
    > and off. They can also change the number of seconds to wait
    > before the automatic cursor-type change (2 sec, by default).

    Brilliant idea!  Here's one way to do it.

    If people don't like a blinking cursor normally, they just have
    to define blink-cursor-delay to the same value as
    blink-cursor-idle-cursor-delay.

In my own implementation, this feature is separate from whether or not the
cursor should blink, which I think is a little better. I just use a timer
that, if the current cursor type is not `box', saves that type as the
`last-cursor-type', changes the type to `box', and reads an event. When an
event arrives, the same function pushes it to `unread-command-events' and,
if there is a `last-cursor-type', restores that as the current cursor type.

As I mentioned, it's good to also have 1) a toggle for this and 2) make the
whole thing an option.

Re: change cursor type when idle

[Lennart Borgman]

Drew Adams wrote:
> In my own implementation, this feature is separate from whether or not the
> cursor should blink, which I think is a little better. I just use a timer
>   
But isn't there people who can not stand blinking (cursors)?

Re: change cursor type when idle

[David Hansen]

On Mon, 28 Aug 2006 17:30:11 +0200 Lennart Borgman wrote:

> Drew Adams wrote:
>> In my own implementation, this feature is separate from whether or not the
>> cursor should blink, which I think is a little better. I just use a timer
>>   
> But isn't there people who can not stand blinking (cursors)?

Yes there is!

RE: change cursor type when idle

[Drew Adams]

    > In my own implementation, this feature is separate from
    > whether or not the cursor should blink, which I think
    > is a little better. I just use a timer

    But isn't there people who can not stand blinking (cursors)?

Yes, that was my point. The two features should be independent: 1) whether
or not the cursor blinks, 2) whether or not the cursor changes to a box when
Emacs is idle. There is no logical connection between these.

Re: change cursor type when idle

[Lennart Borgman]

Drew Adams wrote:
>     > In my own implementation, this feature is separate from
>     > whether or not the cursor should blink, which I think
>     > is a little better. I just use a timer
>
>     But isn't there people who can not stand blinking (cursors)?
>
> Yes, that was my point. The two features should be independent: 1) whether
> or not the cursor blinks, 2) whether or not the cursor changes to a box when
> Emacs is idle. There is no logical connection between these.
>   
Fine! Sorry, I misread it. Should we then just leave it to the user what 
cursor should be shown when Emacs is idle (color, shape etc)?

RE: change cursor type when idle

[Drew Adams]

    >     > In my own implementation, this feature is separate from
    >     > whether or not the cursor should blink, which I think
    >     > is a little better. I just use a timer
    >
    >     But isn't there people who can not stand blinking (cursors)?

    > Yes, that was my point. The two features should be
    > independent: 1) whether or not the cursor blinks, 2) whether
    > or not the cursor changes to a box when Emacs is idle. There
    > is no logical connection between these.

    Fine! Sorry, I misread it. Should we then just leave it to the
    user what cursor should be shown when Emacs is idle (color,
    shape etc)?

IMO, yes. However, in my own code, I just use `box' for the idle cursor. It
doesn't make much sense to use another cursor for the idle state, but I
suppose we might as well leave that up to the user: have an option for the
idle cursor type, whose default value would be `box'.

I hadn't thought of changing the color as well, but that is a possibility.
I'm not sure it's important, but perhaps it would be, if the cursor color
did not stand out and you wanted it to do so when Emacs is idle.

I actually also use code that (optionally) changes the cursor type,
depending on whether the mode is overwrite (bar) or read-only (box), and
changes the cursor color, depending on whether or not you are using an input
method (thx to a suggestion from Juri). I mention this only to point out
that users might also change the cursor type or color independently of the
idle/active state of Emacs, so we don't want to trample on such
functionality.

(And I take advantage of this opportunity to again support Juri's suggestion
to add command `set-cursor-type' to Emacs.)

Re: change cursor type when idle

[Juri Linkov]

> I actually also use code that (optionally) changes the cursor type,
> depending on whether the mode is overwrite (bar) or read-only (box), and
> changes the cursor color, depending on whether or not you are using an input
> method (thx to a suggestion from Juri). I mention this only to point out
> that users might also change the cursor type or color independently of the
> idle/active state of Emacs, so we don't want to trample on such
> functionality.

I like your proposed feature, but I have one doubt.  Usually I use the
bar cursor, and sometimes it is hard to locate it in dense text areas.
Changing its type to a box cursor (and/or its color) would help,
but any delay before changing it (e.g. 2 sec) seems arbitrary.
I need to make the cursor more visible not after some delay, but
only when I need to locate it.  I usually use cursor movement keys
to move the cursor foreward-backward to find its location, but
this is not convenient.

> (And I take advantage of this opportunity to again support Juri's
> suggestion to add command `set-cursor-type' to Emacs.)

I guess `set-cursor-type' is not yet in Emacs, because there are more
than one way to change the cursor type (via the `default-cursor-type'
and `cursor-type' variables, and via the frame parameter), so it's
not clear which one to use in the implementation.  Is it so?

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

RE: change cursor type when idle

[Drew Adams]

    > I actually also use code that (optionally) changes the cursor type,
    > depending on whether the mode is overwrite (bar) or read-only
    > (box), and changes the cursor color, depending on whether or not
    > you are using an input method (thx to a suggestion from Juri).
    > I mention this only to point out that users might also change the
    > cursor type or color independently of the idle/active state of
    > Emacs, so we don't want to trample on such functionality.

    I like your proposed feature, but I have one doubt.  Usually I use the
    bar cursor, and sometimes it is hard to locate it in dense text areas.
    Changing its type to a box cursor (and/or its color) would help,
    but any delay before changing it (e.g. 2 sec) seems arbitrary.
    I need to make the cursor more visible not after some delay, but
    only when I need to locate it.

Ah, I see... The version that lights up and screams "Here!" *ONLY* when you
in fact need to locate it is an expensive option ;-). Mind-reading is never
cheap, if it's accurate.

Seriously, yes, 2 sec is arbitrary, and you can choose another period that
you might prefer. For me, 1 sec is usually too short, and 3 is usually too
long.

    I usually use cursor movement keys
    to move the cursor foreward-backward to find its location, but
    this is not convenient.

Agreed. Been there; done that. My guess is that anyone who has tried to use
the bar cursor has ended up doing that.

    > (And I take advantage of this opportunity to again support Juri's
    > suggestion to add command `set-cursor-type' to Emacs.)

    I guess `set-cursor-type' is not yet in Emacs, because there are more
    than one way to change the cursor type (via the `default-cursor-type'
    and `cursor-type' variables, and via the frame parameter), so it's
    not clear which one to use in the implementation.  Is it so?

I can't answer why. If that's the only reason, then let's decide.

I set the `cursor-type' property of the selected frame, in my version. If
it's important to be able to set the default type sometimes, then why not
let the command do that with a prefix arg? End of story (no?).

Re: change cursor type when idle

[Juri Linkov]

>     I like your proposed feature, but I have one doubt.  Usually I use the
>     bar cursor, and sometimes it is hard to locate it in dense text areas.
>     Changing its type to a box cursor (and/or its color) would help,
>     but any delay before changing it (e.g. 2 sec) seems arbitrary.
>     I need to make the cursor more visible not after some delay, but
>     only when I need to locate it.
>
> Ah, I see... The version that lights up and screams "Here!" *ONLY* when you
> in fact need to locate it is an expensive option ;-). Mind-reading is never
> cheap, if it's accurate.

What about adding a new function `read-mind'? (after the release) ;-)

> Seriously, yes, 2 sec is arbitrary, and you can choose another period that
> you might prefer. For me, 1 sec is usually too short, and 3 is usually too
> long.

Most often a long idle period means that I started reading displayed text,
and don't need to see the cursor.  I use `avoid.el' to move the mouse
pointer away from text, and like to do the same for the cursor.
So I rather like to hide the cursor after an idle period than to make it
more visible.  I see no other way to tell Emacs to show the cursor when need
than to press some keys.

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

RE: change cursor type when idle

[Drew Adams]

    Most often a long idle period means that I started reading
    displayed text,
    and don't need to see the cursor.  I use `avoid.el' to move the mouse
    pointer away from text, and like to do the same for the cursor.
    So I rather like to hide the cursor after an idle period than to make it
    more visible.  I see no other way to tell Emacs to show the
    cursor when need
    than to press some keys.

Maybe in your case you should hide the cursor when idle, and bind a key to
show it (big, bright, and blaring).

The thing about the cursor getting lost in dense text, and your not wanting
to see it when you read text, are complicated by the existence of multiple
windows/buffers/frames.

Re: change cursor type when idle

[Mathias Dahl]

> only when I need to locate it.  I usually use cursor movement keys
> to move the cursor foreward-backward to find its location, but
> this is not convenient.

How about doing something similar to what `mouse-avoidance-mode' does,
but the other way around? For example, after being idle for X seconds,
let the mouse cursor zoom to the location of the cursor.

Just an idea; locating the cursor is not a big issue for me.

RE: change cursor type when idle

[Drew Adams]

    > only when I need to locate it.  I usually use cursor movement keys
    > to move the cursor foreward-backward to find its location, but
    > this is not convenient.

    How about doing something similar to what `mouse-avoidance-mode' does,
    but the other way around? For example, after being idle for X seconds,
    let the mouse cursor zoom to the location of the cursor.

    Just an idea; locating the cursor is not a big issue for me.

It's a joke, right? Argh!

Make the _eye_ zoom to the cursor location, not the mouse - that's the
feature to design. ;-)

Re: change cursor type when idle

[Kevin Rodgers]

Drew Adams wrote:
>     > only when I need to locate it.  I usually use cursor movement keys
>     > to move the cursor foreward-backward to find its location, but
>     > this is not convenient.
> 
>     How about doing something similar to what `mouse-avoidance-mode' does,
>     but the other way around? For example, after being idle for X seconds,
>     let the mouse cursor zoom to the location of the cursor.
> 
>     Just an idea; locating the cursor is not a big issue for me.
> 
> It's a joke, right? Argh!
> 
> Make the _eye_ zoom to the cursor location, not the mouse - that's the
> feature to design. ;-)

The text around the cursor should ripple like a pond where a pebble has
been dropped.  :-)

-- 
Kevin

Re: change cursor type when idle

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Drew Adams wrote:
>> In my own implementation, this feature is separate from whether or not the
>> cursor should blink, which I think is a little better. I just use a timer
>>   
> But isn't there people who can not stand blinking (cursors)?

Nobody forces them to use it.

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

Re: change cursor type when idle

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> If people don't like a blinking cursor normally, they just have to define
> blink-cursor-delay to the same value as blink-cursor-idle-cursor-delay.

Here is a version that does this correctly.

If people just wants the cursor type to change after, say, 3 seconds, but
don't want a blinking cursor, do:

(setq cursor-type 'bar
      blink-cursor-delay 3.0
      blink-cursor-idle-cursor-delay blink-cursor-delay
      blink-cursor-interval 10e7)
      


*** frame.el	22 Aug 2006 08:59:52 +0200	1.239
--- frame.el	28 Aug 2006 23:37:26 +0200	
***************
*** 1244,1249 ****
--- 1244,1261 ----
    :type 'number
    :group 'cursor)
  
+ (defcustom blink-cursor-idle-cursor-delay 5.0
+   "*Seconds of idle time after which cursor changes shape."
+   :type 'number
+   :version "22.1"
+   :group 'cursor)
+ 
+ (defcustom blink-cursor-idle-cursor-type 'box
+   "*Type of cursor which idle cursor changes shape into."
+   :type 'number
+   :version "22.1"
+   :group 'cursor)
+ 
  (defvar blink-cursor-idle-timer nil
    "Timer started after `blink-cursor-delay' seconds of Emacs idle time.
  The function `blink-cursor-start' is called when the timer fires.")
***************
*** 1253,1258 ****
--- 1265,1273 ----
  This timer calls `blink-cursor-timer-function' every
  `blink-cursor-interval' seconds.")
  
+ (defvar blink-cursor-saved-cursor-type nil
+   "Saved type of cursor if changed.")
+ 
  (defun blink-cursor-start ()
    "Timer function called from the timer `blink-cursor-idle-timer'.
  This starts the timer `blink-cursor-timer', which makes the cursor blink
***************
*** 1261,1275 ****
    (when (null blink-cursor-timer)
      ;; Set up the timer first, so that if this signals an error,
      ;; blink-cursor-end is not added to pre-command-hook.
!     (setq blink-cursor-timer
  	  (run-with-timer blink-cursor-interval blink-cursor-interval
! 			  'blink-cursor-timer-function))
      (add-hook 'pre-command-hook 'blink-cursor-end)
!     (internal-show-cursor nil nil)))
  
! (defun blink-cursor-timer-function ()
    "Timer function of timer `blink-cursor-timer'."
!   (internal-show-cursor nil (not (internal-show-cursor-p))))
  
  (defun blink-cursor-end ()
    "Stop cursor blinking.
--- 1276,1299 ----
    (when (null blink-cursor-timer)
      ;; Set up the timer first, so that if this signals an error,
      ;; blink-cursor-end is not added to pre-command-hook.
!     (setq blink-cursor-saved-cursor-type nil
! 	  blink-cursor-timer
  	  (run-with-timer blink-cursor-interval blink-cursor-interval
! 			  'blink-cursor-timer-function t))
      (add-hook 'pre-command-hook 'blink-cursor-end)
!     (blink-cursor-timer-function nil)))
  
! (defun blink-cursor-timer-function (&optional toggle)
    "Timer function of timer `blink-cursor-timer'."
!   (if (and (not blink-cursor-saved-cursor-type)
! 	   blink-cursor-idle-cursor-type
! 	   (not (equal cursor-type blink-cursor-idle-cursor-type))
! 	   (numberp blink-cursor-idle-cursor-delay)
! 	   (>= (float-time (or (current-idle-time) '(0 0)))
! 	       blink-cursor-idle-cursor-delay))
!       (setq blink-cursor-saved-cursor-type cursor-type
! 	    cursor-type blink-cursor-idle-cursor-type)
!     (internal-show-cursor nil (and toggle (not (internal-show-cursor-p))))))
  
  (defun blink-cursor-end ()
    "Stop cursor blinking.
***************
*** 1277,1282 ****
--- 1301,1310 ----
  When run, it cancels the timer `blink-cursor-timer' and removes
  itself as a pre-command hook."
    (remove-hook 'pre-command-hook 'blink-cursor-end)
+   (when blink-cursor-saved-cursor-type
+     (if (eq blink-cursor-idle-cursor-type cursor-type)
+ 	(setq cursor-type blink-cursor-saved-cursor-type))
+     (setq blink-cursor-saved-cursor-type nil))
    (internal-show-cursor nil t)
    (when blink-cursor-timer
      (cancel-timer blink-cursor-timer)

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

Re: change cursor type when idle

[Luc Teirlinck]

Kim Storm wrote:

   Here is a version that does this correctly.

>From looking at your code, unless I missed something, it seems like
your new feature would be turned on _by default_.  If so, this would
be unacceptable.

If a user has set blink-cursor-mode to nil, then no code should
override this and make the cursor blink anyway after a few seconds
idle time.  Forcing the user to customize more than one variable to
make the cursor stop blinking would be user harassment.  Similarly,
if the user changed the cursor type, no code should override that by
default behind the user's back either.

   If people just wants the cursor type to change after, say, 3 seconds, but
   don't want a blinking cursor, do:

   (setq cursor-type 'bar
	 blink-cursor-delay 3.0
	 blink-cursor-idle-cursor-delay blink-cursor-delay
	 blink-cursor-interval 10e7)

Forcing the user to customize no less than four variables to achieve
something this simple does not seem good design to me.

Sincerely,

Luc.

Re: change cursor type when idle

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
>
>    Here is a version that does this correctly.
>
>>From looking at your code, unless I missed something, it seems like
> your new feature would be turned on _by default_.  If so, this would
> be unacceptable.

It would be default when you enable blink-cursor-mode.

But you would never notice if you use a box cursor.

>
> If a user has set blink-cursor-mode to nil, then no code should
> override this and make the cursor blink anyway after a few seconds
> idle time.  

Why do you think it would?
It is driven by blink-cursor-mode's timer, so if you disable
blinking cursors, you wont be affected.

>             Forcing the user to customize more than one variable to
> make the cursor stop blinking would be user harassment.  Similarly,
> if the user changed the cursor type, no code should override that by
> default behind the user's back either.

It's a feature that only affects users with a blinking bar or hbar cursor.

>
>    If people just wants the cursor type to change after, say, 3 seconds, but
>    don't want a blinking cursor, do:
>
>    (setq cursor-type 'bar
> 	 blink-cursor-delay 3.0
> 	 blink-cursor-idle-cursor-delay blink-cursor-delay
> 	 blink-cursor-interval 10e7)
>
> Forcing the user to customize no less than four variables to achieve
> something this simple does not seem good design to me.

It's only three ... you shouldn't count cursor-type here.

But I agree it could be made simpler (in some way)...

In any case, we should wait until after the release to
install (something like) this.


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

RE: change cursor type when idle

[Drew Adams]

    It's a feature that only affects users with a blinking bar or
    hbar cursor.

Why? What does changing the cursor type when Emacs is idle have to do with
blinking?

    But I agree it could be made simpler (in some way)...

I explained how I did it, which is one simpler way. And I'm sure there are
other simple ways, better than mine. Maybe I'm missing something, but I
don't see why there is any connection with blinking.

Even just using the name "blink" will make users think this feature has
something to do with cursor blinking (which it doesn't, logically), so users
not wanting blinking might miss out on this.

Why not keep it simple and implement this feature (in whatever way) on its
own?

Re: change cursor type when idle

[Richard Stallman]

    Another possible (minor) feature to consider for after the release: As an
    option, let users switch cursor type automatically when Emacs is idle.

I will add it to TODO.

RE: change cursor type when idle

[Drew Adams]

> From: Richard Stallman Sent: Monday, August 28, 2006 3:10 PM
>     Another possible (minor) feature to consider for after the
>     release: As an option, let users switch cursor type
>     automatically when Emacs is idle.
>
> I will add it to TODO.

What is the status of this? `cursor-chg.el' is a library that does this. It
defines command `toggle-cursor-type-when-idle', which toggles this behavior.

It also defines a minor mode, `change-cursor-mode', which optionally does
either of the following:

. changes the cursor shape on overwrite or when a buffer is read-only

. changes the cursor color when you use an input method

How about adding this library (modulo integration changes, such as removing
Emacs-20 compatibility code)?

Description: http://www.emacswiki.org/cgi-bin/wiki/ChangingCursorDynamically

Code: http://www.emacswiki.org/cgi-bin/emacs/cursor-chg.el

Re: change cursor type when idle

[Richard Stallman]

It would be nice for someone to install this in the trunk.

RE: change cursor type when idle

[Drew Adams]

AFAICT, this was never installed.

> -----Original Message-----
> From: Richard Stallman Sent: Monday, July 02, 2007 12:48 PM
> 
> It would be nice for someone to install this in the trunk.


> -----Original Message-----
> From: Drew Adams Sent: Sunday, July 01, 2007 1:25 PM
> 
> > From: Richard Stallman Sent: Monday, August 28, 2006 3:10 PM
> >     Another possible (minor) feature to consider for after the
> >     release: As an option, let users switch cursor type
> >     automatically when Emacs is idle.
> >
> > I will add it to TODO.
> 
> What is the status of this? `cursor-chg.el' is a library that 
> does this. It defines command `toggle-cursor-type-when-idle',
> which toggles this behavior.
> 
> It also defines a minor mode, `change-cursor-mode', which 
> optionally does either of the following:
> 
> . changes the cursor shape on overwrite or when a buffer is read-only
> 
> . changes the cursor color when you use an input method
> 
> How about adding this library (modulo integration changes, 
> such as removing Emacs-20 compatibility code)?
> 
> Description: 
> http://www.emacswiki.org/cgi-bin/wiki/ChangingCursorDynamically
> 
> Code: http://www.emacswiki.org/cgi-bin/emacs/cursor-chg.el

Re: change cursor type when idle

[Thien-Thi Nguyen]

() "Drew Adams" <drew.adams@oracle.com>
() Sun, 10 Feb 2008 23:48:04 -0800

   > Description: 
   > http://www.emacswiki.org/cgi-bin/wiki/ChangingCursorDynamically
   > 
   > Code: http://www.emacswiki.org/cgi-bin/emacs/cursor-chg.el

   AFAICT, this was never installed.

I will be happy to install it after i determine:
 a/ Where under lisp/ should it be installed?
 b/ The code in its final form (modulo backward-compat bits, etc).

Please provide a/ and b/ (either to this list or by private email),
so that we may proceed.

thi

Re: change cursor type when idle

[Richard Stallman]

The right place for this would be in the `lisp' directory
since none of the subdirectories fits it.

Re: change cursor type when idle

[Richard Stallman]

Would people please read this and comment on the code?

> It also defines a minor mode, `change-cursor-mode', which 
> optionally does either of the following:
> 
> . changes the cursor shape on overwrite or when a buffer is read-only
> 
> . changes the cursor color when you use an input method

> Code: http://www.emacswiki.org/cgi-bin/emacs/cursor-chg.el

Re: change cursor type when idle

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Would people please read this and comment on the code?

 - There's too much code, the compatibility code should go
 - Too many knobs to turn
 - What's the point of changing the cursor when emacs is idle?
 - What's the point in changing the cursor in a read-only buffer?
 - Someone that uses input methods should comment if changing the cursor
   for when doing that is useful.
 - Changing the cursor in overwrite mode seems like a good idea, other
   editors do it too.
 - IMO we should only consider adding this if we are willing to turn it
   on by default.  If it's not considered useful enough to be on by
   default, then it seems like fluff that it's not worth documenting.

  > > It also defines a minor mode, `change-cursor-mode', which 
  > > optionally does either of the following:
  > > 
  > > . changes the cursor shape on overwrite or when a buffer is read-only
  > > 
  > > . changes the cursor color when you use an input method
  > 
  > > Code: http://www.emacswiki.org/cgi-bin/emacs/cursor-chg.el

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 3:30 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

>  - What's the point of changing the cursor when emacs is idle?

Make it more discreet, for example.

>  - What's the point in changing the cursor in a read-only buffer?

From `cua-read-only-cursor-color':
*Cursor color used in read-only buffers, if non-nil.
Only used when `cua-enable-cursor-indications' is non-nil.

>  - Changing the cursor in overwrite mode seems like a good idea, other
>    editors do it too.

From `cua-overwrite-cursor-color':
*Cursor color used when overwrite mode is set, if non-nil.
Only used when `cua-enable-cursor-indications' is non-nil.

Doesn't what Drew is proposing have a bit of overlap with cua-mode? Or
am I missing something?

             Juanma

Re: change cursor type when idle

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On Feb 12, 2008 3:30 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > >  - What's the point of changing the cursor when emacs is idle?
  > 
  > Make it more discreet, for example.

In what way does the user benefit from that?

  > >  - What's the point in changing the cursor in a read-only buffer?
  > 
  > >From `cua-read-only-cursor-color':
  > *Cursor color used in read-only buffers, if non-nil.
  > Only used when `cua-enable-cursor-indications' is non-nil.

Wonder if anyone knows about this one... 

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 4:10 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

>   > Make it more discreet, for example.
>
> In what way does the user benefit from that?

I can perfectly imagine a setup in which you have a block, blinking
cursor but you would make it a hollow, non-blinking one when you're
using another window (frame, program) so it does not draw your
attention.

> Wonder if anyone knows about this one...

Most cua-mode users surely do. cua-mode is very interesting even if
you don't want the cua-style keys (I don't, but the cursor and
rectangle support are great).

             Juanma

Re: change cursor type when idle

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On Feb 12, 2008 4:10 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > >   > Make it more discreet, for example.
  > >
  > > In what way does the user benefit from that?
  > 
  > I can perfectly imagine a setup in which you have a block, blinking
  > cursor but you would make it a hollow, non-blinking one when you're
  > using another window (frame, program) so it does not draw your
  > attention.

If you are using another window, the emacs frame is not selected, hence
the cursor does not blink. 

  > > Wonder if anyone knows about this one...
  > 
  > Most cua-mode users surely do. 

Doubtful. A quick web search turns out 5 hits, only 3 of which change
the default.  Not a useful feature, IMO.

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 5:20 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> If you are using another window, the emacs frame is not selected, hence
> the cursor does not blink.

Fair enough (I had forgotten that). But the reverse is true; perhaps
you're manually coping from Emacs to another window and you *do* want
the cursor to be more noticeable.

> Doubtful. A quick web search turns out 5 hits, only 3 of which change
> the default.  Not a useful feature, IMO.

Not sure I understand you, but if you're saying that the current
cua-*-cursor-color support is not a useful feature, that's simply
ridiculous.

             Juanma

Re: change cursor type when idle

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On Feb 12, 2008 5:20 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Doubtful. A quick web search turns out 5 hits, only 3 of which change
  > > the default.  Not a useful feature, IMO.
  > 
  > Not sure I understand you, but if you're saying that the current
  > cua-*-cursor-color support is not a useful feature, that's simply
  > ridiculous.

Hold your horses.  You trimmed too much of the context of my reply, I
was referring to exactly one such color: `cua-read-only-cursor-color'.
It's easy enough to know that the buffer is read only, you can't type in
it.  Does changing the cursor color add any extra useful visual clue?

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 5:43 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Hold your horses.  You trimmed too much of the context of my reply,

Sorry. Was not my intention.

> I
> was referring to exactly one such color: `cua-read-only-cursor-color'.
> It's easy enough to know that the buffer is read only, you can't type in
> it.  Does changing the cursor color add any extra useful visual clue?

Yes, it does for me. I often have two almost identical buffers open,
and switch from one to the other. But I want one of them to be
read-only, and the visual clue is helpful (not to prevent trying to
write into the read-only one, but to speed switching among them). I
have in fact this in my .emacs:

(setq cua-normal-cursor-color    '(box . "white")
      cua-overwrite-cursor-color '(hollow . "red")
      cua-read-only-cursor-color '(hollow . "yellow"))

             Juanma

Re: change cursor type when idle

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On Feb 12, 2008 5:43 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > I
  > > was referring to exactly one such color: `cua-read-only-cursor-color'.
  > > It's easy enough to know that the buffer is read only, you can't type in
  > > it.  Does changing the cursor color add any extra useful visual clue?
  > 
  > Yes, it does for me. I often have two almost identical buffers open,
  > and switch from one to the other. But I want one of them to be
  > read-only, and the visual clue is helpful (not to prevent trying to
  > write into the read-only one, but to speed switching among them). I
  > have in fact this in my .emacs:

Sorry, but IMHO such a feature (cua-read-only-cursor-color, or the
similar one in Drew's package) does not seem useful for the majority of
emacs users.  But given that it's already in cua-mode, we can't do much
about it.

  > (setq cua-normal-cursor-color    '(box . "white")
  >       cua-overwrite-cursor-color '(hollow . "red")
          ^^^^^^^^^^^
IMHO this  is useful, and it should be in generic code.

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 7:07 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Sorry, but IMHO such a feature (cua-read-only-cursor-color, or the
> similar one in Drew's package) does not seem useful for the majority of
> emacs users.  [...]
>
>   > (setq cua-normal-cursor-color    '(box . "white")
>   >       cua-overwrite-cursor-color '(hollow . "red")
>           ^^^^^^^^^^^
> IMHO this  is useful, and it should be in generic code.

I would like to hear any objective arguments about the usefulness of
an overwrite-mode cursor and the non-usefulness of a read-only-mode
cursor.

             Juanma

RE: change cursor type when idle

[Drew Adams]

I must say I'm a bit surprised by all the heat this has generated.

FWIW -

It's fine with me if this isn't added to Emacs, or if you trim part of it
out and add only some of it. I really don't care. It will still be available
on Emacs Wiki, for anyone who really wants it.

For the record, I got the idea from Juri. Perhaps he got it from CUA mode; I
don't know. 

Personally, I find it useful. In particular, being able to use a bar cursor
for editing, but having it switch to a box cursor temporarily after an idle
period, helps me locate the cursor again. Others are welcome to feel
differently.

Either way, I think it's a minor feature - hardly worth all the pyrotechnic
entertainment. ;-)

Re: change cursor type when idle

[Juri Linkov]

> I must say I'm a bit surprised by all the heat this has generated.
>
> FWIW -
>
> It's fine with me if this isn't added to Emacs, or if you trim part of it
> out and add only some of it. I really don't care. It will still be available
> on Emacs Wiki, for anyone who really wants it.
>
> For the record, I got the idea from Juri. Perhaps he got it from CUA mode;
> I don't know.

I only use different cursor types for overwrite mode because this is the
standard behavior in many other programs, and different cursor types for the
active input method because it has the same benefits as for overwrite mode,
i.e. it takes too much efforts to recover from typing in wrong mode or
wrong input method.

I have no opinion on the usefulness of the read-only-mode cursor and the
cursor type when idle, since I don't use them.

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

Re: change cursor type when idle

[Juri Linkov]

BTW, I can reproduce this old bug both in cua mode from CVS and
with the file submitted by Drew:

http://lists.gnu.org/archive/html/emacs-devel/2005-11/msg00424.html

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

Re: change cursor type when idle

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On Feb 12, 2008 7:07 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Sorry, but IMHO such a feature (cua-read-only-cursor-color, or the
  > > similar one in Drew's package) does not seem useful for the majority of
  > > emacs users.  [...]
  > >
  > >   > (setq cua-normal-cursor-color    '(box . "white")
  > >   >       cua-overwrite-cursor-color '(hollow . "red")
  > >           ^^^^^^^^^^^
  > > IMHO this  is useful, and it should be in generic code.
  > 
  > I would like to hear any objective arguments about the usefulness of
  > an overwrite-mode cursor and the non-usefulness of a read-only-mode
  > cursor.

overwrite-mode cursor:
  - this wheel has been invented elsewhere and has been in wide use in
  many editors for a long time.
  - bad things happen if you don't notice that you've accidentally
  pressed "Insert" and continue typing. A visual clue is an extra aid
  for the user.

read-only-mode cursor:
  - I am not familiar with a similar feature elsewhere.
  - The fact that you can't input text is a good enough indication that
  the buffer if read-only. Changing the cursor in this case needs added
  code and documentation.   _I_ can see no benefit to the users from this.

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 7:44 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

>   - this wheel has been invented elsewhere and has been in wide use in
>   many editors for a long time.
vs.
>   - I am not familiar with a similar feature elsewhere.

That's hardly a compelling argument. For one, there are literally
thousands of editors; if even a fraction of them has implemented it
the read-only cursor, that would seem to indicate that some people
find it useful, as I do; OTOH, most editors I used before Emacs didn't
have a read-only mode, so the argument doesn't really apply. Perhaps
that means that read-only mode is not that useful, or it would have
been in wide use in many editors for a long time...

>   - bad things happen if you don't notice that you've accidentally
>   pressed "Insert" and continue typing. A visual clue is an extra aid
>   for the user.
vs.
>   - The fact that you can't input text is a good enough indication that
>   the buffer if read-only. Changing the cursor in this case needs added
>   code and documentation.   _I_ can see no benefit to the users from this.

In my setup, if I start typing blindly in a read-only buffer, I
certainly lose what I'm typing, because I receive no audible alert.
That's as "bad thing" to me like accidentally overwriting a file, if
undo is available. And if it is not, read only mode or not typing
blind would be advisable :)

             Juanma

RE: change cursor type when idle

[Drew Adams]

>  - There's too much code, the compatibility code should go

It already went. I sent Thi the update (off list), as he requested.

>  - Too many knobs to turn

Be specific. "Too many" begs explanation.

>  - What's the point of changing the cursor when emacs is idle?
>  - What's the point in changing the cursor in a read-only buffer?
>  - Someone that uses input methods should comment if changing 
>    the cursor for when doing that is useful.
>  - Changing the cursor in overwrite mode seems like a good idea, other
>    editors do it too.

Juanma replied to these questions. Each can be useful in come contexts. None
should be mandated for users, of course.

I'd add that change when Emacs is idle can be useful to help you see where
the cursor is. Idle Emacs can mean your attention is not currently at point.
(This change is only from bar cursor to box.)

>  - IMO we should only consider adding this if we are willing 
>    to turn it on by default.

Which? All?

I have the options on, myself, so I have nothing against having them on by
default. Users of my library oneonone.el also have similar options on by
default. 

As mentioned in the Commentary, some of this is based on ideas from others
(Juri, in particular), and there are some other libraries that do something
similar. That is an indication that it can be useful. And Juanma mentions
that CUA has something similar, which also indicates that this can be
useful.

Wrt overlap with CUA:

I don't know when this was added to CUA; I wasn't aware of that when I wrote
this, which was in November 2005.

If a merge or refactoring with CUA code is in order, then I would think it
would be for CUA to use the code from a separate library, as opposed to
making users who want only the cursor changes use cua-mode.

>    If it's not considered useful enough to be on by
>    default, then it seems like fluff that it's not worth documenting.
 

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 4:19 PM, Drew Adams <drew.adams@oracle.com> wrote:

> I don't know when this was added to CUA; I wasn't aware of that when I wrote
> this, which was in November 2005.

C:\...\lisp> grep-changelog --reverse --text=cua-.*cursor
2002-05-13  Kim F. Storm  <storm@cua.dk>

	* emulation/cua-base.el (cua-enable-cursor-indications): Default off.
	(cua-mode): Print Enabled/Disabled messages if interactive.
	Disable delete-selection-mode and pc-selection-mode when cua-mode
	is enabled; reenable if cua-mode is turned off.
	Remember setting of transient-mark-mode when cua-mode is enabled;
	restore if cua-mode is disabled.

2002-10-07  Kim F. Storm  <storm@cua.dk>

	* emulation/cua-base.el (cua-normal-cursor-color):
	Fixed initialization to make "Erase Customization" work.

2004-04-14  Kim F. Storm  <storm@cua.dk>

	* emulation/cua-base.el (cua-read-only-cursor-color)
	(cua-overwrite-cursor-color, cua-global-mark-cursor-color): Doc fix.

2004-04-30  Kim F. Storm  <storm@cua.dk>

	* emulation/cua-base.el: Add support for changing cursor types;
	based on patch from Michael Mauger.
	(cua-normal-cursor-color, cua-read-only-cursor-color)
	(cua-overwrite-cursor-color, cua-global-mark-cursor-color):
	Customization cursor type and/or cursor color.
	(cua--update-indications): Handle cursor type changes.
	(cua-mode): Update cursor indications if enabled.

[etc]

But I think when was the code written is now irrelevant, as cua-mode
is already in 22.X.

> If a merge or refactoring with CUA code is in order, then I would think it
> would be for CUA to use the code from a separate library, as opposed to
> making users who want only the cursor changes use cua-mode.

It would perhaps make sense to move the cursor-related stuff from
cua-base to a new cua-cursor, like the global mark and rectangle
support are, or even to a non-cua library (compatibility should be
maintained, though, so we'll end with a bunch of cua-*-cursor-*
aliases).  But anyway, your "using cua-mode" is a bit misleading; you
can use cua-mode features without using CUA keys or the like.

             Juanma

Re: change cursor type when idle

[Dan Nicolaescu]

"Drew Adams" <drew.adams@oracle.com> writes:

  > >  - There's too much code, the compatibility code should go
  > 
  > It already went. I sent Thi the update (off list), as he requested.

  > >  - Too many knobs to turn
  > 
  > Be specific. "Too many" begs explanation.

8 defcustoms, 1 minor mode, one toggle-* function seem a bit
excessive for the intended target of this package.


  > >  - What's the point of changing the cursor when emacs is idle?
  > >  - What's the point in changing the cursor in a read-only buffer?
  > >  - Someone that uses input methods should comment if changing 
  > >    the cursor for when doing that is useful.
  > >  - Changing the cursor in overwrite mode seems like a good idea, other
  > >    editors do it too.
  > 
  > Juanma replied to these questions. Each can be useful in come contexts. None
  > should be mandated for users, of course.

I don't think he did, not in a way that would justify adding this to emacs.

  > I'd add that change when Emacs is idle can be useful to help you see where
  > the cursor is. Idle Emacs can mean your attention is not currently at point.
  > (This change is only from bar cursor to box.)

_I_ am totally unconvinced changing the cursor when is useful, not just
featuritis. You might be able to convince other people though...

  > >  - IMO we should only consider adding this if we are willing 
  > >    to turn it on by default.
  > 
  > Which? All?

Yes, all that it's considered useful. I motivated this:

  > >    If it's not considered useful enough to be on by
  > >    default, then it seems like fluff that it's not worth documenting.

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 5:11 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> I don't think he did, not in a way that would justify adding this to emacs.

I don't try to convince you; I'm quite happy with the current cursor
support. But people often do feel very strongly about these kind of
things; calling it "featuritis" seems like assuming that you know
better than them.

             Juanma

Re: change cursor type when idle

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Feb 12, 2008 5:11 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>
>> I don't think he did, not in a way that would justify adding this to
>> emacs.
>
> I don't try to convince you; I'm quite happy with the current cursor
> support. But people often do feel very strongly about these kind of
> things; calling it "featuritis" seems like assuming that you know
> better than them.

Given that he just explained to Drew that his purported use case is
already covered by the default cursor behavior for unselected frames, it
appears like indeed he _does_ know better.  At least in some respect.

-- 
David Kastrup

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 5:27 PM, David Kastrup <dak@gnu.org> wrote:

> Given that he just explained to Drew that his purported use case is
> already covered by the default cursor behavior for unselected frames, it
> appears like indeed he _does_ know better.  At least in some respect.

No, he did in fact explain it to me. That means either that he knows
better than I do about cursor support on Emacs, or that I forgot a
simple case while discussing possible uses (perhaps both). But that's
hardly relevant: arguing that what Drew wants is too complex for the
benefit, or that it is already supported, can be done in an objective
way. But saying that it is not useful is just handwaving, as it is
obvious that there are users who do find it useful. Usefulness, and in
particular usefulness with respect to visual things, varies
tremendously from person to person. I use a black background, no-icons
allowed desktop, but my Emacs is what (borrowing the words of someone
on this list, I don't remember who) could only be called "angry fruit
salad". Both things are optima for my uses.

             Juanma

Re: change cursor type when idle

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On Feb 12, 2008 5:11 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > I don't think he did, not in a way that would justify adding this to emacs.
  > 
  > I don't try to convince you; I'm quite happy with the current cursor
  > support. But people often do feel very strongly about these kind of
  > things; calling it "featuritis" seems like assuming that you know
  > better than them.

Please refrain from ad hominem attacks on this list.

RMS asked for opinions. I simply gave mine.

Re: change cursor type when idle

[Juanma Barranquero]

On Feb 12, 2008 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> calling it "featuritis" seems like assuming that you know
>   > better than them.
>
> Please refrain from ad hominem attacks on this list.

I will, if I ever start doing it. That's not an ad hominem attack.

             Juanma

Re: change cursor type when idle

[Richard Stallman]

    If a merge or refactoring with CUA code is in order, then I would think it
    would be for CUA to use the code from a separate library, as opposed to
    making users who want only the cursor changes use cua-mode.

That is clearly true.  This feature is unrelated to the key binding
changes of CUA mode, so they ought to be separated and made
independent features.

Re: change cursor type when idle

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     If a merge or refactoring with CUA code is in order, then I would think it
>     would be for CUA to use the code from a separate library, as opposed to
>     making users who want only the cursor changes use cua-mode.
>
> That is clearly true.  This feature is unrelated to the key binding
> changes of CUA mode, so they ought to be separated and made
> independent features.

The reason it is tied into cua-mode in the first place is that I
needed to have separate cursor styles for rectangle marking and the
global-mark feature.  

It was then trivial to add a few extra hooks to show different
cursors also for read-only and overwrite-mode.  Separating them
would be harder - as there need to be prioritized between the
different cursor types (e.g. the rectangle selection cursor takes
priority over the read-only and overwrite-mode cursors).

In principle, I fully agree that cua-mode should be completely
separated into different packages, but unfortunately, the features
provided by cua-mode need some rather deep interactions, so it
is hard to actually split them (more than I have already done).

Since it works just fine as it is, I prefer to keep things as they
are now - rather than insisting on separating stuff at the cost of
reduced functionality and interoperatibility (e.g. copying a marked
rectangle to the global-mark works fine now - since the global-mark
and the rectangle functions know about each other...).

And since you can just use cua-mode without the cua-bindings, I don't
really see why having the "cua-" prefix is such a problem to (some)
people.

I wish someone would volounteer to write a cua.texi manual describing
all the features.

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

Re: change cursor type when idle

[Stefan Monnier]

> Since it works just fine as it is, I prefer to keep things as they
> are now - rather than insisting on separating stuff at the cost of
> reduced functionality and interoperatibility (e.g. copying a marked
> rectangle to the global-mark works fine now - since the global-mark
> and the rectangle functions know about each other...).

> And since you can just use cua-mode without the cua-bindings, I don't
> really see why having the "cua-" prefix is such a problem to (some)
> people.

Indeed, there are various levels of "separation".  It seems that CUA has
several features that can currently be used independently (although
their implementation still interact).  That's good.  It means that from
the user's point of view, they are independent, and should thus be
documented as such.

> I wish someone would volounteer to write a cua.texi manual describing
> all the features.

Even just a few starting hints would be good: how to enable each major
feature (e.g. the cursor stuff, the rectangle stuff, ...).


        Stefan

CUA-mode features and documenation (was: Re: change cursor type when idle)

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Even just a few starting hints would be good: how to enable each major
> feature (e.g. the cursor stuff, the rectangle stuff, ...).

The commentary in cua-base.el contains a few hints :-)

Some details of the info may be slightly inaccurate though.


---------------- 8< ----------- cut here -------------

This is the CUA package which provides a complete emulation of the
standard CUA key bindings (Motif/Windows/Mac GUI) for selecting and
manipulating the region where S-<movement> is used to highlight &
extend the region.

CUA style key bindings for cut and paste
----------------------------------------

This package allows the C-z, C-x, C-c, and C-v keys to be
bound appropriately according to the Motif/Windows GUI, i.e.
C-z	-> undo
C-x	-> cut
C-c	-> copy
C-v	-> paste

The tricky part is the handling of the C-x and C-c keys which
are normally used as prefix keys for most of emacs' built-in
commands.  With CUA they still do!!!

Only when the region is currently active (and highlighted since
transient-mark-mode is used), the C-x and C-c keys will work as CUA
keys
	C-x -> cut
	C-c -> copy
When the region is not active, C-x and C-c works as prefix keys!

This probably sounds strange and difficult to get used to - but
based on my own experience and the feedback from many users of
this package, it actually works very well and users adapt to it
instantly - or at least very quickly.  So give it a try!
.. and in the few cases where you make a mistake and accidentally
delete the region - you just undo the mistake (with C-z).

If you really need to perform a command which starts with one of
the prefix keys even when the region is active, you have three options:
- press the prefix key twice very quickly (within 0.2 seconds),
- press the prefix key and the following key within 0.2 seconds, or
- use the SHIFT key with the prefix key, i.e. C-X or C-C

This behaviour can be customized via the
cua-prefix-override-inhibit-delay variable.

In addition to using the shifted movement keys, you can also use
[C-space] to start the region and use unshifted movement keys to extend
it. To cancel the region, use [C-space] or [C-g].

If you prefer to use the standard emacs cut, copy, paste, and undo
bindings, customize cua-enable-cua-keys to nil.


Typing text replaces the region
-------------------------------

When the region is active, i.e. highlighted, the text in region is
replaced by the text you type.

The replaced text is saved in register 0 which can be inserted using
the key sequence M-0 C-v (see the section on register support below).

If you have just replaced a highlighted region with typed text,
you can repeat the replace with M-v.  This will search forward
for a streach of text identical to the previous contents of the
region (i.e. the contents of register 0) and replace it with the
text you typed to replace the original region.	Repeating M-v will
replace the next matching region and so on.

Example:  Suppose you have a line like this
  The redo operation will redo the last redoable command
which you want to change into
  The repeat operation will repeat the last repeatable command
This is done by highlighting the first occurrence of "redo"
and type "repeat" M-v M-v.

Note: Since CUA-mode duplicates the functionality of the
delete-selection-mode, that mode is automatically disabled when
CUA-mode is enabled.


CUA mode indications
--------------------
You can choose to let CUA use different cursor colors to indicate
overwrite mode and read-only buffers.  For example, the following
setting will use a RED cursor in normal (insertion) mode in
read-write buffers, a YELLOW cursor in overwrite mode in read-write
buffers, and a GREEN cursor read-only buffers:

 (setq cua-normal-cursor-color "red")
 (setq cua-overwrite-cursor-color "yellow")
 (setq cua-read-only-cursor-color "green")


CUA register support
--------------------
Emacs' standard register support is also based on a separate set of
"register commands".

CUA's register support is activated by providing a numeric
prefix argument to the C-x, C-c, and C-v commands. For example,
to copy the selected region to register 2, enter [M-2 C-c].
Or if you have activated the keypad prefix mode, enter [kp-2 C-c].

And CUA will copy and paste normal region as well as rectangles
into the registers, i.e. you use exactly the same command for both.

In addition, the last highlighted text that is deleted (not
copied), e.g. by [delete] or by typing text over a highlighted
region, is automatically saved in register 0, so you can insert it
using [M-0 C-v].

CUA rectangle support
---------------------
Emacs' normal rectangle support is based on interpreting the region
between the mark and point as a "virtual rectangle", and using a
completely separate set of "rectangle commands" [C-x r ...] on the
region to copy, kill, fill a.s.o. the virtual rectangle.

cua-mode's superior rectangle support uses a true visual
representation of the selected rectangle, i.e. it highlights the
actual part of the buffer that is currently selected as part of the
rectangle.  Unlike emacs' traditional rectangle commands, the
selected rectangle always as straight left and right edges, even
when those are in the middle of a TAB character or beyond the end
of the current line.  And it does this without actually modifying
the buffer contents (it uses display overlays to visualize the
virtual dimensions of the rectangle).

This means that cua-mode's rectangles are not limited to the actual
contents of the buffer, so if the cursor is currently at the end of a
short line, you can still extend the rectangle to include more columns
of longer lines in the same rectangle.	And you can also have the
left edge of a rectangle start in the middle of a TAB character.
Sounds strange? Try it!

To start a rectangle, use [C-return] and extend it using the normal
movement keys (up, down, left, right, home, end, C-home,
C-end). Once the rectangle has the desired size, you can cut or
copy it using C-x and C-c (or C-w and M-w), and you can
subsequently insert it - as a rectangle - using C-v (or C-y).  So
the only new command you need to know to work with cua-mode
rectangles is C-return!

Normally, when you paste a rectangle using C-v (C-y), each line of
the rectangle is inserted into the existing lines in the buffer.
If overwrite-mode is active when you paste a rectangle, it is
inserted as normal (multi-line) text.

If you prefer the traditional rectangle marking (i.e. don't want
straight edges), [M-p] toggles this for the current rectangle,
or you can customize cua-virtual-rectangle-edges.

And there's more: If you want to extend or reduce the size of the
rectangle in one of the other corners of the rectangle, just use
[return] to move the cursor to the "next" corner.  Or you can use
the [M-up], [M-down], [M-left], and [M-right] keys to move the
entire rectangle overlay (but not the contents) in the given
direction.

[C-return] cancels the rectangle
[C-space] activates the region bounded by the rectangle

If you type a normal (self-inserting) character when the rectangle is
active, the character is inserted on the "current side" of every line
of the rectangle.  The "current side" is the side on which the cursor
is currently located. If the rectangle is only 1 column wide,
insertion will be performed to the left when the cursor is at the
bottom of the rectangle.  So, for example, to comment out an entire
paragraph like this one, just place the cursor on the first character
of the first line, and enter the following:
    C-return M-} ; ; <space>  C-return

cua-mode's rectangle support also includes all the normal rectangle
functions with easy access:

[M-a] aligns all words at the left edge of the rectangle
[M-b] fills the rectangle with blanks (tabs and spaces)
[M-c] closes the rectangle by removing all blanks at the left edge
      of the rectangle
[M-f] fills the rectangle with a single character (prompt)
[M-i] increases the first number found on each line of the rectangle
      by the amount given by the numeric prefix argument (default 1)
      It recognizes 0x... as hexadecimal numbers
[M-k] kills the rectangle as normal multi-line text (for paste)
[M-l] downcases the rectangle
[M-m] copies the rectangle as normal multi-line text (for paste)
[M-n] fills each line of the rectangle with increasing numbers using
      a supplied format string (prompt)
[M-o] opens the rectangle by moving the highlighted text to the
      right of the rectangle and filling the rectangle with blanks.
[M-p] toggles virtual straight rectangle edges
[M-P] inserts tabs and spaces (padding) to make real straight edges
[M-q] performs text filling on the rectangle
[M-r] replaces REGEXP (prompt) by STRING (prompt) in rectangle
[M-R] reverse the lines in the rectangle
[M-s] fills each line of the rectangle with the same STRING (prompt)
[M-t] performs text fill of the rectangle with TEXT (prompt)
[M-u] upcases the rectangle
[M-|] runs shell command on rectangle
[M-'] restricts rectangle to lines with CHAR (prompt) at left column
[M-/] restricts rectangle to lines matching REGEXP (prompt)
[C-?] Shows a brief list of the above commands.

[M-C-up] and [M-C-down] scrolls the lines INSIDE the rectangle up
and down; lines scrolled outside the top or bottom of the rectangle
are lost, but can be recovered using [C-z].

CUA Global Mark
---------------
The final feature provided by CUA is the "global mark", which
makes it very easy to copy bits and pieces from the same and other
files into the current text.  To enable and cancel the global mark,
use [S-C-space].  The cursor will blink when the global mark
is active.  The following commands behave differently when the global
mark is set:
<ch>  All characters (including newlines) you type are inserted
      at the global mark!
[C-x] If you cut a region or rectangle, it is automatically inserted
      at the global mark, and the global mark is advanced.
[C-c] If you copy a region or rectangle, it is immediately inserted
      at the global mark, and the global mark is advanced.
[C-v] Copies a single character to the global mark.
[C-d] Moves (i.e. deletes and inserts) a single character to the
      global mark.
[backspace] deletes the character before the global mark, while
[delete] deltes the character after the global mark.

[S-C-space] Jumps to and cancels the global mark.
[C-u S-C-space] Cancels the global mark (stays in current buffer).

[TAB] Indents the current line or rectangle to the column of the
      global mark.

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

Re: CUA-mode features and documenation (was: Re: change cursor type when idle)

[Dan Nicolaescu]

storm@cua.dk (Kim F. Storm) writes:

  > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > 
  > > Even just a few starting hints would be good: how to enable each major
  > > feature (e.g. the cursor stuff, the rectangle stuff, ...).
  > 
  > The commentary in cua-base.el contains a few hints :-)

What this does not document is `cua-selection-mode', which, IMHO, we
should promote as a replacement for pc-selection-mode.  
cua-selection-mode does not change the meaning of C-x / C-v, but it does
offer the delete-selection-mode + Shif-ARROW_KEY selects region behavior
that is now used by the vast majority of desktop applications (including
Gnome, KDE).

Re: CUA-mode features and documenation

[Juri Linkov]

> What this does not document is `cua-selection-mode', which, IMHO, we
> should promote as a replacement for pc-selection-mode.
> cua-selection-mode does not change the meaning of C-x / C-v, but it does
> offer the delete-selection-mode + Shif-ARROW_KEY selects region behavior
> that is now used by the vast majority of desktop applications (including
> Gnome, KDE).

I think `cua-selection-mode' is so useful that it should be added to the
`Options' menu instead of `Active Region Highlighting'.

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

Re: CUA-mode features and documenation

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > > What this does not document is `cua-selection-mode', which, IMHO, we
  > > should promote as a replacement for pc-selection-mode.
  > > cua-selection-mode does not change the meaning of C-x / C-v, but it does
  > > offer the delete-selection-mode + Shif-ARROW_KEY selects region behavior
  > > that is now used by the vast majority of desktop applications (including
  > > Gnome, KDE).
  > 
  > I think `cua-selection-mode' is so useful that it should be added to the
  > `Options' menu instead of `Active Region Highlighting'.

Seconded.

Re: CUA-mode features and documenation

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I think `cua-selection-mode' is so useful that it should be added to the
> `Options' menu instead of `Active Region Highlighting'.

_Instead_ of?  I think you've been smoking too much Xah Lee...

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: CUA-mode features and documenation

[Juri Linkov]

>> I think `cua-selection-mode' is so useful that it should be added to the
>> `Options' menu instead of `Active Region Highlighting'.
>
> _Instead_ of?  I think you've been smoking too much Xah Lee...

I am not an extremist but it seems that having two similar menu items
will be too confusing.  I think `cua-selection-mode' is closer to what
most users expect from this type of thing nowadays.

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

Re: CUA-mode features and documenation

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> _Instead_ of?  I think you've been smoking too much Xah Lee...
>
> I am not an extremist but it seems that having two similar menu items
> will be too confusing.  I think `cua-selection-mode' is closer to what
> most users expect from this type of thing nowadays.

Most users expect MS word.  That's not what Emacs is.

transient-mark-mode is a popular and straight-forward feature that
highlights (heh!) Emacs' native command set, and I don't think we should
bury such things.

-Miles

-- 
Opposition, n. In politics the party that prevents the Goverment from running
amok by hamstringing it.

Re: CUA-mode features and documenation

[Lennart Borgman (gmail)]

Miles Bader wrote:
> Juri Linkov <juri@jurta.org> writes:
>>> _Instead_ of?  I think you've been smoking too much Xah Lee...
>> I am not an extremist but it seems that having two similar menu items
>> will be too confusing.  I think `cua-selection-mode' is closer to what
>> most users expect from this type of thing nowadays.
> 
> Most users expect MS word.  That's not what Emacs is.
> 
> transient-mark-mode is a popular and straight-forward feature that
> highlights (heh!) Emacs' native command set, and I don't think we should
> bury such things.

Is it not reasonable to assume that most new users expects and wants the 
behaviour that cua-selection-mode gives?

Can you explain what is lost if cua-selection-mode is used instead of 
transient-mark-mode?

Re: CUA-mode features and documenation

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> Is it not reasonable to assume that most new users expects and wants the
> behaviour that cua-selection-mode gives?

I have no idea.  I presume that many new-to-emacs users might be used to
such a command set; on the other hand I presume many existing emacs
users (upgrading to a new version) would not.  We cater to both.

> Can you explain what is lost if cua-selection-mode is used instead of
> transient-mark-mode?

I haven't used cua-selection-mode enough to have a good idea of the
practical (user-visible) difference (e.g. if there are serious
incompatibilities), but cua-selection-mode (1) rebinds a bunch of very
basic commands, (2) adds a post-command hook.

Those two things aren't to be taken lightly, I think.  The second is
particularly worrying.

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: CUA-mode features and documenation

[Richard Stallman]

    Is it not reasonable to assume that most new users expects and wants the 
    behaviour that cua-selection-mode gives?

That is not the only relevant factor.

What _exactly_ is this behavior?  I do not use CUA mode.

Re: CUA-mode features and documenation

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Is it not reasonable to assume that most new users expects and wants the 
  >     behaviour that cua-selection-mode gives?
  > 
  > That is not the only relevant factor.
  > 
  > What _exactly_ is this behavior?  I do not use CUA mode.

Please note that the discussion was about cua-selection-mode, not cua-mode. 
They are different: cua-selection-mode does not change the meaning of C-c/C-v/C-x. 

What cua-selection-mode provides is the:
- transient-mark-mode
- delete-selection-mode
- S-ARROW_KEY extends the region 
(Probably some more, but this is the main functionality).

This behavior is the default nowadays on the desktop, including in
Gtk+/Gnome and KDE (also in XEmacs).


BTW, before the pretest for 22.1 you were trying transient-mark-mode in
order to enable it by default. What was the result of that experiment?

Re: CUA-mode features and documenation

[Richard Stallman]

      > That is not the only relevant factor.
      > 
      > What _exactly_ is this behavior?  I do not use CUA mode.

    Please note that the discussion was about cua-selection-mode, not cua-mode. 
Yes, but I don't use CUA mode, so I would not know what any of it does.

    What cua-selection-mode provides is the:
    - transient-mark-mode
    - delete-selection-mode
    - S-ARROW_KEY extends the region 
    (Probably some more, but this is the main functionality).

This might be a superior for Delete Selection mode.
If we want to promote it that way, we should choose a better
name that CUA Selection mode, because most people won't know
what "CUA" means.

But I don't think it should be the default, any more than
Delete Selection mode should be.

RE: CUA-mode features and documenation

[Drew Adams]

>     What cua-selection-mode provides is the:
>     - transient-mark-mode
>     - delete-selection-mode

Delete selection mode already provides (uses) transient mark mode. So CUA
selection mode apparently adds only this:

>     - S-ARROW_KEY extends the region 

And maybe this (?):

>     (Probably some more, but this is the main functionality).

> This might be a superior for Delete Selection mode.

What do you mean by "a superior [?] for D S mode"? Do you mean that it would
be good to add those S-<arrowkey> bindings to D S mode or to replace D S
mode by CUA selection mode?

If so, I disagree. I use D S mode, and I don't want the S-<arrowkey>
bindings.

Anyway, in D S mode, you can already use S-<arrowkey>s the same way, but
only when the region is active. I think Kim should have said that in CUA
selection mode S-<arrowkey> *activates the region* and extends it, whereas
in delete selection mode it extends the active region.

IOW, AFAICT, CUA selection mode just lets you skip hitting C-SPC before
using S-<arrowkey>. I prefer the D S behavior, myself: S-<arrowkey> extends
the active region, but doesn't also set mark. (You can then use S-<arrowkey>
for something else when the region is not active.)

I think we need to keep giving users a choice about this (having
S-<arrowkey> set mark if the region is inactive). That could be done by
keeping both D S mode and CUA selection mode, or (simpler?) by adding a user
option and keeping only one of them.

I don't know about the "probably some more" stuff - perhaps we should look
into that. If there is in fact no more, then just adding an option to D S
mode for S-<arrowkey> to set mark (if inactive) would be sufficient. We
could then drop CUA selection mode.

Question (not proposal): Assuming we keep CUA selection mode, would it be
clearer to change its name, to avoid confusion with CUA mode? I imagine that
CUA selection mode is a perfectly accurate name, in that it presumably
implements the selection part of IBM's Common User Access
(http://en.wikipedia.org/wiki/Common_User_Access).

Even so, (1) the name might lead to some confusion with CUA mode, and (2)
it's not obvious to most people what "CUA" is. That ignorance is probably OK
for CUA mode, since you need to read the doc anyway to find out what it's
all about (lots of features), and "Common User Access" refers to more than
just selection. But for CUA selection mode, we might look for a better name.

Note that "delete selection" mode is also not the ideal name for what it
does. It is really a "replace selection" mode. You can type to replace the
active region, and deletion is just replacement by nothing. But then, even
"replace selection" doesn't convey the ability to extend the active region
using S-<arrowkey>.

Looking at various Emacs Wiki entries, I suspect there is a fair amount of
confusion for newbies among (1) transient mark mode, (2) delete selection
mode, (3) PC selection mode, and (4) CUA selection mode. But I guess that's
the nature of the beast - Emacs provides a world of optional behaviors, even
out of the box. Vive la difference !

> If we want to promote it that way, we should choose a better
> name that CUA Selection mode, because most people won't know
> what "CUA" means.

Ah, what I asked.

> But I don't think it should be the default, any more than
> Delete Selection mode should be.

(I have no strong opinion about the default, but I think either CUA
selection mode or delete selection mode behavior would be a good default
behavior for newbies.)

To move forward, perhaps someone can speak to the "probably some more", and
we can then discuss how we might combine CUA selection mode and delete
selection mode (with options, so we don't lose existing behavior).

Re: CUA-mode features and documenation

[Richard Stallman]

    >     (Probably some more, but this is the main functionality).

    > This might be a superior for Delete Selection mode.

I omitted lost the word "replacement", sorry.

This might be a superior replacement for Delete Selection mode.

    What do you mean by "a superior [?] for D S mode"? Do you mean that it would
    be good to add those S-<arrowkey> bindings to D S mode or to replace D S
    mode by CUA selection mode?

Those sound like two ways to implement the same thing.
Right now the question is what to do, not how.

    Anyway, in D S mode, you can already use S-<arrowkey>s the same way, but
    only when the region is active. I think Kim should have said that in CUA
    selection mode S-<arrowkey> *activates the region* and extends it, whereas
    in delete selection mode it extends the active region.

If that's the only difference, maybe it should be a user option
variable.

Re: CUA-mode features and documenation

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

> I think we need to keep giving users a choice about this (having
> S-<arrowkey> set mark if the region is inactive). That could be done by
> keeping both D S mode and CUA selection mode, or (simpler?) by adding a user
> option and keeping only one of them.

You completely lost me there ...  

If you commonly use C-SPC to start the region, why would you _ever_
use the shifted arrow keys to extend the region, when the unshifted
arrow keys extends it just as well (that's how the region normally
works) ??

So if you are not in the habit of using shift-select, you can use
cua-selection-mode just like delete-seletion-mode.


> I don't know about the "probably some more" stuff - perhaps we should look
> into that. If there is in fact no more, then just adding an option to D S
> mode for S-<arrowkey> to set mark (if inactive) would be sufficient. We
> could then drop CUA selection mode.

Huh?  "just adding" ?   That's not trivial!

Since delete-seletion-mode functionality is already integrated in cua-mode,
while shift-select support is absent from delete-seletion-mode, it would be
more natural to make delete-seletion-mode be a sub-mode of cua-mode, rather
than the opposite (it just needs an option cua-enable-shift-select - default on).

>
> Question (not proposal): Assuming we keep CUA selection mode, would it be
> clearer to change its name, to avoid confusion with CUA mode? I imagine that
> CUA selection mode is a perfectly accurate name, in that it presumably
> implements the selection part of IBM's Common User Access
> (http://en.wikipedia.org/wiki/Common_User_Access).

Why rename something which is a "perfecty accurate name" ?

> Looking at various Emacs Wiki entries, I suspect there is a fair amount of
> confusion for newbies among (1) transient mark mode, (2) delete selection
> mode, (3) PC selection mode, and (4) CUA selection mode.

The confusion must be because experienced users try to convince the newbies
NOT to enable full cua-mode (with the C-x C-c mappings)...

To avoid confusion - just enable cua-mode (in full) and Emacs behaves like

>> If we want to promote it that way, we should choose a better
>> name that CUA Selection mode, because most people won't know
>> what "CUA" means.

Call it delete-selection-mode then !

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

RE: CUA-mode features and documenation

[Drew Adams]

> > I think we need to keep giving users a choice about this (having
> > S-<arrowkey> set mark if the region is inactive). That could be
> > done by keeping both D S mode and CUA selection mode, or (simpler?) 
> > by adding a user option and keeping only one of them.
> 
> You completely lost me there ...  
> 
> If you commonly use C-SPC to start the region, why would you _ever_
> use the shifted arrow keys to extend the region, when the unshifted
> arrow keys extends it just as well (that's how the region normally
> works) ??

Right. My point was that from what you described, the automatic C-SPC is the
only difference, since you can use C-SPC S-<arrow> in delete-selection-mode,
versus just S-<arrow> in cua-selection-mode. If the only thing
cua-selection-mode adds wrt delete-selection-mode is the automatic C-SPC,
then let's just make that an option.

> So if you are not in the habit of using shift-select, you can use
> cua-selection-mode just like delete-seletion-mode.

Or, if you are not in that habit, then you can also use
delete-selection-mode just like cua-selection-mode. ;)  Modulo the unnamed
"probably more stuff".

> > I don't know about the "probably some more" stuff - perhaps 
> > we should look into that. If there is in fact no more, then
> > just adding an option to D S mode for S-<arrowkey> to set mark
> > (if inactive) would be sufficient. We could then drop CUA
> > selection mode.
> 
> Huh?  "just adding" ?   That's not trivial!

OK.

> Since delete-seletion-mode functionality is already 
> integrated in cua-mode, while shift-select support is
> absent from delete-seletion-mode, it would be
> more natural to make delete-seletion-mode be a sub-mode of 
> cua-mode, rather than the opposite (it just needs an option 
> cua-enable-shift-select - default on).

That's fine with me. I already stated that either would be fine.

But what about the "probably more stuff" you referred to? What's involved
there?

You say now that all you would need to get delete-selection-mode behavior is
to turn off a proposed option that automatically sets mark when you use the
arrow keys. But what about the other stuff? What is it, and how would a user
turn it off, to get delete-selection-mode behavior?

> > Question (not proposal): Assuming we keep CUA selection 
> > mode, would it be clearer to change its name, to avoid
> > confusion with CUA mode? I imagine that CUA selection mode
> > is a perfectly accurate name, in that it presumably
> > implements the selection part of IBM's Common User Access
> > (http://en.wikipedia.org/wiki/Common_User_Access).
> 
> Why rename something which is a "perfecty accurate name" ?

For the reason I gave in the very next paragraph, which you omitted:

  Even so, (1) the name might lead to some confusion with
  CUA mode, and (2) it's not obvious to most people what
  "CUA" is. That ignorance is probably OK for CUA mode, since
  you need to read the doc anyway to find out what it's
  all about (lots of features), and "Common User Access"
  refers to more than just selection. But for CUA selection
  mode, we might look for a better name.

IOW, even though "common user access selection mode" accurately describes
this as the selection mode of Common User Access, the term can be misleading
(confusion with cua-mode) or inadequate (ignorance of Common User Access).

BTW, there is no need to get defensive about it. I don't really care how we
handle the overlap or the name. I just pointed out some overlap and some
potential user confusion.

> > Looking at various Emacs Wiki entries, I suspect there is a 
> > fair amount of confusion for newbies among (1) transient mark mode,
> > (2) delete selection mode, (3) PC selection mode, and (4) CUA
> > selection mode.
> 
> The confusion must be because experienced users try to 
> convince the newbies NOT to enable full cua-mode (with the
> C-x C-c mappings)...

I think you are being defensive. "The confusion must be"? What evidence do
you have either that experienced users are doing that or that that "must be"
the reason that newbies are confused about this?

> To avoid confusion - just enable cua-mode (in full) and Emacs 
> behaves like

(something missing there?)

Nothing wrong with such a suggestion, and I think that has already been
communicated to users, both on the wiki and in the Emacs doc.
 
> >> If we want to promote it that way, we should choose a better
> >> name that CUA Selection mode, because most people won't know
> >> what "CUA" means.
> 
> Call it delete-selection-mode then !

Call it what you like. I have no axe to grind here. I already said that
"delete-selection-mode" is also not a great name:

  Note that "delete selection" mode is also not the ideal name
  for what it does. It is really a "replace selection" mode.
  You can type to replace the active region, and deletion is just
  replacement by nothing. But then, even "replace selection"
  doesn't convey the ability to extend the active region
  using S-<arrowkey>.

(or using just <arrowkey>)

Re: CUA-mode features and documenation

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> This might be a superior for Delete Selection mode.
> If we want to promote it that way, we should choose a better
> name that CUA Selection mode, because most people won't know
> what "CUA" means.

cua-selection-mode is far more intrusive though, as it adds
"shift-select" behavior (all shifted movement keys implicitly set and
activate the mark if it hasn't already been activated).  To implement
that behavior both adds a post-command hook, and rebinds a bunch of very
common commands.

-Miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: CUA-mode features and documenation

[Lennart Borgman (gmail)]

Miles Bader wrote:
> Richard Stallman <rms@gnu.org> writes:
>> This might be a superior for Delete Selection mode.
>> If we want to promote it that way, we should choose a better
>> name that CUA Selection mode, because most people won't know
>> what "CUA" means.
> 
> cua-selection-mode is far more intrusive though, as it adds
> "shift-select" behavior (all shifted movement keys implicitly set and
> activate the mark if it hasn't already been activated).  To implement
> that behavior both adds a post-command hook, and rebinds a bunch of very
> common commands.


The feature is IMO opinion very useful (though I use cua-mode -- 
together with viper...).

Should the "shift-select" behaviour be reimplemented?

Re: CUA-mode features and documenation

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> cua-selection-mode is far more intrusive though, as it adds
>> "shift-select" behavior (all shifted movement keys implicitly set and
>> activate the mark if it hasn't already been activated).  To implement
>> that behavior both adds a post-command hook, and rebinds a bunch of very
>> common commands.
>
> The feature is IMO opinion very useful (though I use cua-mode -- 
> together with viper...).

I'm sure many people like it, especially windows users.

> Should the "shift-select" behaviour be reimplemented?

I don't know how possible that is (Kim would be the person to ask I
guess), but given the "pervasive" nature of the behavior, it sounds hard
to me.

-Miles

-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Re: CUA-mode features and documenation

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

>> Should the "shift-select" behaviour be reimplemented?
>
> I don't know how possible that is (Kim would be the person to ask I
> guess), but given the "pervasive" nature of the behavior, it sounds hard
> to me.

cua-(selection-)mode is already the fourth implementation of the
shift-select functionality that I know about (the others are:
s-mark.el, s-region.el, pc-selection-mode) -- so unless there's a
brilliant new way to do it, I don't see a need to do that!

Of course, IMHO, cua-mode is the only implementation which does it the
right way :-)

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

Re: CUA-mode features and documenation

[Richard Stallman]

    BTW, before the pretest for 22.1 you were trying transient-mark-mode in
    order to enable it by default. What was the result of that experiment?

I could not stand Transient Mark mode by itself.
However, I now use it with `mark-even-if-inactive' = t,
and I think that is fine.

Re: CUA-mode features and documenation

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     BTW, before the pretest for 22.1 you were trying transient-mark-mode in
  >     order to enable it by default. What was the result of that experiment?
  > 
  > I could not stand Transient Mark mode by itself.
  > However, I now use it with `mark-even-if-inactive' = t,
  > and I think that is fine.

OK, I have changed the default for mark-even-if-inactive to be t and
turned on transient-mark-mode by default.

RE: CUA-mode features and documenation

[Drew Adams]

>   >     BTW, before the pretest for 22.1 you were trying 
>   >     transient-mark-mode in order to enable it by default.
>   >     What was the result of that experiment?
>   > 
>   > I could not stand Transient Mark mode by itself.
>   > However, I now use it with `mark-even-if-inactive' = t,
>   > and I think that is fine.
> 
> OK, I have changed the default for mark-even-if-inactive to be t and
> turned on transient-mark-mode by default.

Huh? Just like that?

I don't mind for myself, since that is the behavior I use. 

But does such a change follow, just from RMS using it now? I think the
previous discussion came to a consensus about t-m mode as the default, but
I'm not sure we agreed on (or even discussed) `mark-even-if-inactive' being
t by default. Anyway, it gets my vote.

Re: CUA-mode features and documenation

[Richard Stallman]

    OK, I have changed the default for mark-even-if-inactive to be t and
    turned on transient-mark-mode by default.

That seems hasty.

(If and when this is done, someone has to carefully change
some early sections in the Emacs manual.)

Enabling Transient Mark Mode by default [Re: CUA-mode features and documenation]

[Alan Mackenzie]

Hi, Dan!

On Sun, Feb 17, 2008 at 08:58:26AM -0800, Dan Nicolaescu wrote:
> Richard Stallman <rms@gnu.org> writes:

>   >     BTW, before the pretest for 22.1 you were trying
>   >     transient-mark-mode in order to enable it by default. What was
>   >     the result of that experiment?

>   > I could not stand Transient Mark mode by itself.  However, I now
>   > use it with `mark-even-if-inactive' = t, and I think that is fine.

> OK, I have changed the default for mark-even-if-inactive to be t and
> turned on transient-mark-mode by default.

I feel I must protest about this.  I tried transient-mark-mode yesterday
(for the first time) on a Solaris system (Emacs 22.1).  I'm trying it now
on my Linux TTY, also Emacs 22.1.

I've done nothing more than M-x transient-mark-mode (in a buffer.el
loaded by desktop), and already half of the screen's font-locking has
been obliterated by an ugly heavy blue transient-mark face (whatever it's
called).  (The same happened yesterday on Solaris running X-Windows).

I do M-: mark-even-if-inactive, and the blue face vanishes in an
explosion.  I can't work when things explode in my face.  Then M-: (setq
mark-even-if-inactive t).  Things behave a bit more sanely.

Then C-x 5 b *info*.  90% of the manual page was obliterated by this
ghastly overpowering deep blue face.  By experimentation, C-g got rid of
it.

Transient Mark mode is a radical departure from standard Emacs, in which
the concept of the mark is substantially changed.  I don't think we're
talking here about two equally valid ways of doing things, one of which
we must chose; rather we have an option which can be on or off by
default - a bit like paren matching.  Such options shouldn't, in
general, be on by default.

OK, I {sh,c}ould read the fine manual, but I've deliberately avoided
this, so as to simulate the reactions of typical users.  I think enough
typical users will detest this facility, that it should not be thrust
upon them.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Enabling Transient Mark Mode by default [Re: CUA-mode features and documenation]

[Dan Nicolaescu]

Alan Mackenzie <acm@muc.de> writes:

  > Hi, Dan!
  > 
  > On Sun, Feb 17, 2008 at 08:58:26AM -0800, Dan Nicolaescu wrote:
  > > Richard Stallman <rms@gnu.org> writes:
  > 
  > >   >     BTW, before the pretest for 22.1 you were trying
  > >   >     transient-mark-mode in order to enable it by default. What was
  > >   >     the result of that experiment?
  > 
  > >   > I could not stand Transient Mark mode by itself.  However, I now
  > >   > use it with `mark-even-if-inactive' = t, and I think that is fine.
  > 
  > > OK, I have changed the default for mark-even-if-inactive to be t and
  > > turned on transient-mark-mode by default.
  > 
  > I feel I must protest about this.  I tried transient-mark-mode yesterday
  > (for the first time) on a Solaris system (Emacs 22.1).  I'm trying it now
  > on my Linux TTY, also Emacs 22.1.
  > 
  > I've done nothing more than M-x transient-mark-mode (in a buffer.el
  > loaded by desktop), and already half of the screen's font-locking has
  > been obliterated by an ugly heavy blue transient-mark face (whatever it's
  > called).  (The same happened yesterday on Solaris running X-Windows).
  > 
  > I do M-: mark-even-if-inactive, and the blue face vanishes in an
  > explosion.  I can't work when things explode in my face.  Then M-: (setq
  > mark-even-if-inactive t).  Things behave a bit more sanely.
  > 
  > Then C-x 5 b *info*.  90% of the manual page was obliterated by this
  > ghastly overpowering deep blue face.  By experimentation, C-g got rid of
  > it.
  >
  > Transient Mark mode is a radical departure from standard Emacs, in which
  > the concept of the mark is substantially changed.  I don't think we're
  > talking here about two equally valid ways of doing things, one of which
  > we must chose; rather we have an option which can be on or off by
  > default - a bit like paren matching.  Such options shouldn't, in
  > general, be on by default.
  > 
  > OK, I {sh,c}ould read the fine manual, but I've deliberately avoided
  > this, so as to simulate the reactions of typical users.  I think enough
  > typical users will detest this facility, that it should not be thrust
  > upon them.

I don't think so, typical users are used the transient-mark-mode
behavior from all the other applications they use on their desktop.
Many times emacs has been called backwards because it refuses to
implement this now omnipresent convention (plus a few other ones).

Defaults are most useful for people that don't have a .emacs, nor have
the skills/time/or interest to write one.  Providing the behavior that
such type of users expect by default is the best way to make a larger
number of people happy.  Yes, sometimes common conventions are not the
thing, and we can provide a different default then, but this is not one
of those case.

It seems that changing ANY default will provoke some resistance from at
least one person on this list because "it used to be different before".
But catering mostly to the readers of this list is not the best idea,
better have 5 people here add a line in their .emacs to turn off some
feature than have a few thousands add a line to turn it off.

Re: Enabling Transient Mark Mode by default

[Alan Mackenzie]

Hi, once again, Dan!

On Tue, Feb 19, 2008 at 01:38:38AM -0800, Dan Nicolaescu wrote:
> Alan Mackenzie <acm@muc.de> writes:

[Dan]:
>   > > OK, I have changed the default for mark-even-if-inactive to be t
>   > > and turned on transient-mark-mode by default.

>   > I feel I must protest about this.  ....

[ .... ]

>   > .... I think enough typical users will detest this facility, that
>   > it should not be thrust upon them.

> I don't think so, typical users are used the transient-mark-mode
> behavior from all the other applications they use on their desktop.
> Many times emacs has been called backwards because it refuses to
> implement this now omnipresent convention (plus a few other ones).

Let it be called backward - following the crowd has never been Emacs
policy.  If it is good, do it, otherwise don't.  Unless I've missed it in
another thread (for which, apologies), I don't think anybody has
demonstrated the goodness of this change.

Anyhow, transient-mark-mode is NOT what "all other applications" have.
For example, other applications don't have their font-locking obliterated
over 90% of the screen when first displaying a buffer loaded from
desktop.  And I haven't seen another application where the
transient-facing explodes when you do an equivalend of M-:.

In X-Windows today, I tried setting the region face to a very pale grey
background, no foreground.  This wasn't too bad in general, but it
obliterated my hi-lock faces.  On a GUI system, can we somehow make a
pale grey background attenuate other backgrounds it is applied to rather
than replacing them?  If not, shouldn't we be able to, before transient
regionification becomes default?

What would you suggest as a default for the region face on a 16-colour
TTY?  I can assure you that dark blue background doesn't cut it.

> It seems that changing ANY default will provoke some resistance from at
> least one person on this list because "it used to be different before".

That is because the existing defaults have been carefully thought out,
and honed to optimality over over 20 years of development.  If they are
to be changed, the changes must likewise be carefully thought out.  I
think many people come to Emacs because of the refreshing efficiency of
its ideas, as contrasted with other programs' slavish conformance to a
lowest common denominator "standard".

In otherwords, and IMAO, Transient Mark Mode, while good enough for those
who consciously chose to enable it, needs fixing before becoming a
default, if that is to happen.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

> For example, other applications don't have their font-locking
> obliterated over 90% of the screen when first displaying a buffer
> loaded from desktop.

That sounds like a bug.  Please be constructive and report it rather
than use terms like "obliterate" which are plain wrong since nothing was
destroyed or removed, only the appearence was "transient"ly affected.

> What would you suggest as a default for the region face on a 16-colour
> TTY?  I can assure you that dark blue background doesn't cut it.

Clearly, you don't like the feature, so just turn it off.


        Stefan

Re: Enabling Transient Mark Mode by default

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> In otherwords, and IMAO, Transient Mark Mode, while good enough for those
> who consciously chose to enable it, needs fixing before becoming a
> default, if that is to happen.

Actually, many of us think it works pretty well.

Not that it can't be improved, of course.

-Miles

-- 
Ocean, n. A body of water covering seven-tenths of a world designed for Man -
who has no gills.

Re: Enabling Transient Mark Mode by default

[Mathias Dahl]

> Actually, many of us think it works pretty well.
>
> Not that it can't be improved, of course.

I tested in emacs -Q just now and have to say that it seems to work
well. I have previously had some problems with it like the region
suddenly being highlighted when I did not expect it to or commands not
working when the region was not highlighted. All of that seems to be
solved. For a new user I would guess having the region highlighted
when not expected is the most confusing and annoying thing, it kind of
feels like some sticky thing follows the cursor. If we have eliminated
all those "false positives" (I don't remember now when I got that
behavior) I think this will be a good default. More experienced users
can easily change the appropriate setting to get the behavior they
like.

I like it.

/Mathias

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Mathias Dahl wrote:
>> Actually, many of us think it works pretty well.
>>
>> Not that it can't be improved, of course.
> 
> I tested in emacs -Q just now and have to say that it seems to work
> well. I have previously had some problems with it like the region
> suddenly being highlighted when I did not expect it to or commands not
> working when the region was not highlighted. All of that seems to be
> solved. For a new user I would guess having the region highlighted
> when not expected is the most confusing and annoying thing, it kind of
> feels like some sticky thing follows the cursor. If we have eliminated
> all those "false positives" (I don't remember now when I got that
> behavior) I think this will be a good default. More experienced users
> can easily change the appropriate setting to get the behavior they
> like.
> 
> I like it.

Don't we all think that new users probably want the highlight the way 
cua-mode does it?

Re: Enabling Transient Mark Mode by default

[David Kastrup]

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

> Don't we all think that new users probably want the highlight the way
> cua-mode does it?

No, we don't.  That was easy.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Don't we all think that new users probably want the highlight the way
>> cua-mode does it?
> 
> No, we don't.  That was easy.

;-)

So some of us think that new users want highlighting in Emacs to differ 
from most other applications they use. Can someone summarize what 
differences we expect them to like? And maybe why?

Re: Enabling Transient Mark Mode by default

[David Kastrup]

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

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> Don't we all think that new users probably want the highlight the way
>>> cua-mode does it?
>>
>> No, we don't.  That was easy.
>
> ;-)
>
> So some of us think that new users want highlighting in Emacs to
> differ from most other applications they use. Can someone summarize
> what differences we expect them to like? And maybe why?

Because a web browser is not an editor?  Because in other applications
it is usual only to mark small visible areas instead of large ones?  And
do that with the mouse (which works in Emacs just as expected, anyway)?

If new users wanted everything to be the same as elsewhere, they would
not try Emacs in the first place.  For example, cut&paste&kill using the
mouse in Emacs is vastly superior to how other applications do it (they
require using the keyboard for that, or context menus, or toolbar
buttons).  It would be nonsensical to make Emacs inferior so that people
don't have to learn how Emacs is better than their usual applications.

So could you please take your strawman elsewhere?  Nobody ever proposed
that Emacs should behave differently from other applications merely for
the sake of being different.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> David Kastrup wrote:
>>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>
>>>> Don't we all think that new users probably want the highlight the way
>>>> cua-mode does it?
>>> No, we don't.  That was easy.
>> ;-)
>>
>> So some of us think that new users want highlighting in Emacs to
>> differ from most other applications they use. Can someone summarize
>> what differences we expect them to like? And maybe why?
> 
> Because a web browser is not an editor?  Because in other applications
> it is usual only to mark small visible areas instead of large ones?  And
> do that with the mouse (which works in Emacs just as expected, anyway)?

In what way does cua-mode interfere here? (Except for the key bindings.)

> If new users wanted everything to be the same as elsewhere, they would
> not try Emacs in the first place.  For example, cut&paste&kill using the
> mouse in Emacs is vastly superior to how other applications do it (they
> require using the keyboard for that, or context menus, or toolbar
> buttons).  It would be nonsensical to make Emacs inferior so that people
> don't have to learn how Emacs is better than their usual applications.

What you say here seems reasonable, but I never use a mouse in Emacs.

The point is of course that new users should be able to use their old 
habits as far as possible + new features from Emacs.

> So could you please take your strawman elsewhere?  Nobody ever proposed
> that Emacs should behave differently from other applications merely for
> the sake of being different.

I don't think I said so. I am sorry if my little joke upset you.

Re: Enabling Transient Mark Mode by default

[David Kastrup]

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

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> David Kastrup wrote:
>>>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>>
>>>>> Don't we all think that new users probably want the highlight the way
>>>>> cua-mode does it?
>>>> No, we don't.  That was easy.
>>> ;-)
>>>
>>> So some of us think that new users want highlighting in Emacs to
>>> differ from most other applications they use. Can someone summarize
>>> what differences we expect them to like? And maybe why?
>>
>> Because a web browser is not an editor?  Because in other applications
>> it is usual only to mark small visible areas instead of large ones?  And
>> do that with the mouse (which works in Emacs just as expected, anyway)?
>
> In what way does cua-mode interfere here? (Except for the key
> bindings.)

Could you please focus on one argument at the time?  cua-mode in its
entirety completely messes up the predictability of key presses.
Essentially, you can throw Emacs manuals and the Emacs reference card
into the garbage bin: it will only work at unpredictable times.  That is
not a setting for newbies.

You are talking about the highlighting that is pretty much equivalent to
transient-mark-mode.  And that is annoying to me.  Not least of all
because it is intertwined with active region restrictions for many
commands, and again this is something that will be surprising to the end
user if he did nothing special to restrict the region in that manner.

>> If new users wanted everything to be the same as elsewhere, they
>> would not try Emacs in the first place.  For example, cut&paste&kill
>> using the mouse in Emacs is vastly superior to how other applications
>> do it (they require using the keyboard for that, or context menus, or
>> toolbar buttons).  It would be nonsensical to make Emacs inferior so
>> that people don't have to learn how Emacs is better than their usual
>> applications.
>
> What you say here seems reasonable, but I never use a mouse in Emacs.

Do you really think that you are in the best position to speak for
newcomers then?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> I like it.
>
> Don't we all think that new users probably want the highlight the way
> cua-mode does it?

No?

-Miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

> Don't we all think that new users probably want the highlight the way
> cua-mode does it?

Actually, in this respect, cua-mode isn't very different, as far as
I can tell: you also get into those situations where the region is
highlighted when you don't want it and you have to hit C-g to get rid
of it.


        Stefan

Re: Enabling Transient Mark Mode by default

[Mathias Dahl]

> Don't we all think that new users probably want the highlight the way
> cua-mode does it?

Wrong list to ask that question, Lennart :) I would guess most here
think no because cua-mode "mess up", if you allow me to use such
strong words, many classic Emacs bindings. A friend of mine who has
started to use Emacs recently gets problems quite often when I show
some cool Emacs feature, just because of the cua-bindings. I am sure
one can use cua-mode without any problem but that requires a bit of
manual reading.

However, what I think works quite well for a beginner, although I do
not use it myself anymore, is pc-selection-mode. IMHO it does not
"mess up" anything. Using shift + the arrow keys to select a region is
quite common on most applications even under GNU/Linux.

But I am sure this has been discussed before here so maybe I shouldn't
have brought it up again...

CUA-*mode (was: Enabling Transient Mark Mode by default)

[Stefan Monnier]

> However, what I think works quite well for a beginner, although I do
> not use it myself anymore, is pc-selection-mode. IMHO it does not
> "mess up" anything. Using shift + the arrow keys to select a region is
> quite common on most applications even under GNU/Linux.

cua-selection-mode works as well for that purpose (don't confuse it
with cua-mode).


        Stefan

Re: CUA-*mode (was: Enabling Transient Mark Mode by default)

[Mathias Dahl]

> cua-selection-mode works as well for that purpose (don't confuse it
> with cua-mode).

How does it differ from `pc-selection-mode'? From what I can gather
after a quick browse of cua-base.el it seems it is like
`pc-selection-mode' plus `delete-selection-mode' enabled both at once.
Is that true?

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    > In otherwords, and IMAO, Transient Mark Mode, while good enough for those
    > who consciously chose to enable it, needs fixing before becoming a
    > default, if that is to happen.

I consider it unacceptable, without mark-even-if-inactive.  However,
te change that was installed included making mark-even-if-inactive
default to t.  That might be ok.  But the person who did it jumped the
gun.

Re: Enabling Transient Mark Mode by default

[Sascha Wilde]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

Richard Stallman <rms@gnu.org> wrote:

>     > In otherwords, and IMAO, Transient Mark Mode, while good enough for those
>     > who consciously chose to enable it, needs fixing before becoming a
>     > default, if that is to happen.
>
> I consider it unacceptable, without mark-even-if-inactive.  However,
> te change that was installed included making mark-even-if-inactive
> default to t.  That might be ok.  But the person who did it jumped the
> gun.

When starting a freshly build Emacs this morning I was somewhat shocked
by the fact that transient-mark-mode suddenly became default.

It's not that much of a problem for a simple (transient-mark-mode -1) in
.emacs fixes it.  But on the other hand I'm still missing a good reason
for activating it in the first place (after skimming briefly over this
thread).  And "it might be ok" is not equal to "it's a good thing to do",
IMO.

I think we are facing a more general strategic problem here:

One has to turn of more and more features, to get back the traditional
Emacsian behavior (which I consider the best in many cases).  The policy
for Emacs once seemed to be (I don't recall if it was officially stated)
to be rather puristic per default and leave it to the user to turn on
all the bells and whistles and blinken light he wants.  

This is a good thing IMO and I would appreciate if less features would
be turned into defaults (even if many of them are surely useful).

I for one prefer to look into the manual to learn how to turn some great
feature on, than to feel forced to search for a way to turn a feature of,
which I consider annoying...

cheers
sascha
-- 
Sascha Wilde 
Hi! I'm a .signature *virus*! Copy me into your ~/.signature to help me spread!

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Enabling Transient Mark Mode by default

[Juanma Barranquero]

On Feb 20, 2008 1:27 PM, Sascha Wilde <wilde@sha-bang.de> wrote:

> One has to turn of more and more features, to get back the traditional
> Emacsian behavior (which I consider the best in many cases).  The policy
> for Emacs once seemed to be (I don't recall if it was officially stated)
> to be rather puristic per default and leave it to the user to turn on
> all the bells and whistles and blinken light he wants.

IMO, defaults should be choosen, if possible, so the behavior is what
most new users would expect. An experienced user will research how to
deactivate something that he doesn't like. A newbie will perhaps just
give up.

The first time I tried Emacs I gave up because there wasn't an easy
way to make it save the current screen position and frame size (easy
as in "just activate this menu option"). And I didn't came from a
particularly windowsy, mouse-driven background, more like PDP-11's
RSX-11M, VAX/VMS, Oasis/Theos and other command-line oriented OSes.

             Juanma

Re: Enabling Transient Mark Mode by default

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Feb 20, 2008 1:27 PM, Sascha Wilde <wilde@sha-bang.de> wrote:
>
>> One has to turn of more and more features, to get back the
>> traditional Emacsian behavior (which I consider the best in many
>> cases).  The policy for Emacs once seemed to be (I don't recall if it
>> was officially stated) to be rather puristic per default and leave it
>> to the user to turn on all the bells and whistles and blinken light
>> he wants.
>
> IMO, defaults should be choosen, if possible, so the behavior is what
> most new users would expect.

No.  What is most usable.  We want Emacs to be the best editor
available, not the most similar to lesser products.

Transient-mark-mode messes with the normal work flow (and the active
region) in a way that is not helpful.  It is not even actually similar
to what other software does with regions.

> An experienced user will research how to deactivate something that he
> doesn't like. A newbie will perhaps just give up.

On deactivating something that he doesn't like?  Likely.  So do we want
to make newbies give up?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Juanma Barranquero]

On Feb 20, 2008 2:09 PM, David Kastrup <dak@gnu.org> wrote:

> No.  What is most usable.  We want Emacs to be the best editor
> available, not the most similar to lesser products.

It can be the best editor available even if some defaults (similar to
those of "lesser products") make life easier for newbies.

> Transient-mark-mode messes with the normal work flow (and the active
> region) in a way that is not helpful.  It is not even actually similar
> to what other software does with regions.

I was commenting on general policy; I don't particularly care about
transient mark mode.

> On deactivating something that he doesn't like?

On Emacs.

             Juanma

Re: Enabling Transient Mark Mode by default

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Feb 20, 2008 2:09 PM, David Kastrup <dak@gnu.org> wrote:
>
>> No.  What is most usable.  We want Emacs to be the best editor
>> available, not the most similar to lesser products.
>
> It can be the best editor available even if some defaults (similar to
> those of "lesser products") make life easier for newbies.
>
>> Transient-mark-mode messes with the normal work flow (and the active
>> region) in a way that is not helpful.  It is not even actually similar
>> to what other software does with regions.
>
> I was commenting on general policy; I don't particularly care about
> transient mark mode.

Solving problems in perfect generality without bothering to look at them
is not necessarily the most effective recipe for actual progress.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Juanma Barranquero]

> Solving problems in perfect generality without bothering to look at them
> is not necessarily the most effective recipe for actual progress.

Nitpicking comments instead of trying to understand the intention is
not a good recipe, either.

             Juanma

Re: Enabling Transient Mark Mode by default

[David Reitter]

On 20 Feb 2008, at 12:52, Juanma Barranquero wrote:

> IMO, defaults should be choosen, if possible, so the behavior is what
> most new users would expect. An experienced user will research how to
> deactivate something that he doesn't like. A newbie will perhaps just
> give up.


I would replace "newbie" with anyone who uses Emacs alongside a number  
of other applications which provide their own editing facilities (even  
if just to fill a form field). That was my situation, and while I'd  
happily adapt one way or the other (w.r.t transient-mark-mode and key  
bindings, etc.) in general, I wouldn't want to switch back and forth  
within seconds. Emacs users say the same about switching between  
machines and having their own .emacs sync'ed between them.

Is it possible to satisfy both types of users?
Can't there be two variants of Emacs?

Re: Enabling Transient Mark Mode by default

[Juanma Barranquero]

On Feb 20, 2008 4:55 PM, David Reitter <david.reitter@gmail.com> wrote:

> I would replace "newbie" with anyone who uses Emacs alongside a number
> of other applications which provide their own editing facilities (even
> if just to fill a form field). That was my situation, and while I'd
> happily adapt one way or the other (w.r.t transient-mark-mode and key
> bindings, etc.) in general, I wouldn't want to switch back and forth
> within seconds.

Of course. But an experienced user does not *need* for Emacs to agree
with other apps he uses: he can customize it. The trouble is
unexperienced users who find themselves with (to them) weird or
unexpected behavior, and no way to fix it. We can give them familiar
defaults, or we can send them to RTFM...

             Juanma

Re: Enabling Transient Mark Mode by default

[David Reitter]

On 20 Feb 2008, at 16:04, Juanma Barranquero wrote:

> Of course. But an experienced user does not *need* for Emacs to agree
> with other apps he uses: he can customize it. The trouble is
> unexperienced users who find themselves with (to them) weird or
> unexpected behavior, and no way to fix it. We can give them familiar
> defaults, or we can send them to RTFM...


Absolutely. Despite some 15-20 years experience with computers, I had  
no Emacs and no Lisp experience. So I gave up twice until I decided to  
bite the bullet and switch to the only editor with Prolog support. It  
took me many weeks to customize it to the behavior I was used to from  
all my other apps. And even four years later I find myself going nuts  
over some things, except that I know now why they're hard to implement.

By the way, I found empirically that some 80 percent of all users  
(exact figure eludes me now) left the Aquamacs default of opening new  
buffers in separate frames turned on. They're happy with it and get on  
with their lives. Of course there's a few others, old-time Emacs  
users, who don't find the big fat menu option in "Options" to turn  
this off, and instead bitch about it on their blogs. But I tend to  
look at what the majority wants, even if it might not be the best  
solution when ignoring the user's environment (other apps!). That's  
why we've got these things switched on. Including variable-width fonts  
for all text modes.

I've never understood what hinders people from providing an "Emacs"  
and an "Emacs Classic", which simply differ in their default  
configuration. (But I also don't really care any more.)

Re: Enabling Transient Mark Mode by default

[Dan Nicolaescu]

David Reitter <david.reitter@gmail.com> writes:

  > On 20 Feb 2008, at 16:04, Juanma Barranquero wrote:
  > 
  > > Of course. But an experienced user does not *need* for Emacs to agree
  > > with other apps he uses: he can customize it. The trouble is
  > > unexperienced users who find themselves with (to them) weird or
  > > unexpected behavior, and no way to fix it. We can give them familiar
  > > defaults, or we can send them to RTFM...
  > 
  > 
  > Absolutely. Despite some 15-20 years experience with computers, I had
  > no Emacs and no Lisp experience. So I gave up twice until I decided to
  > bite the bullet and switch to the only editor with Prolog support. It
  > took me many weeks to customize it to the behavior I was used to from
  > all my other apps. And even four years later I find myself going nuts
  > over some things, except that I know now why they're hard to
  > implement.
  > 
  > By the way, I found empirically that some 80 percent of all users
  > (exact figure eludes me now) left the Aquamacs default of opening new
  > buffers in separate frames turned on. They're happy with it and get on
  > with their lives. Of course there's a few others, old-time Emacs
  > users, who don't find the big fat menu option in "Options" to turn
  > this off, and instead bitch about it on their blogs. But I tend to
  > look at what the majority wants, even if it might not be the best
  > solution when ignoring the user's environment (other apps!). That's
  > why we've got these things switched on. Including variable-width fonts
  > for all text modes.
  > 
  > I've never understood what hinders people from providing an "Emacs"
  > and an "Emacs Classic", which simply differ in their default
  > configuration. (But I also don't really care any more.)

Re: Enabling Transient Mark Mode by default

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> On 20 Feb 2008, at 12:52, Juanma Barranquero wrote:
>
>> IMO, defaults should be choosen, if possible, so the behavior is what
>> most new users would expect. An experienced user will research how to
>> deactivate something that he doesn't like. A newbie will perhaps just
>> give up.
>
>
> I would replace "newbie" with anyone who uses Emacs alongside a number
> of other applications which provide their own editing facilities (even
> if just to fill a form field). That was my situation, and while I'd
> happily adapt one way or the other (w.r.t transient-mark-mode and key
> bindings, etc.) in general, I wouldn't want to switch back and forth
> within seconds. Emacs users say the same about switching between
> machines and having their own .emacs sync'ed between them.
>
> Is it possible to satisfy both types of users?
> Can't there be two variants of Emacs?

That's pointless because then the experienced users will cease to be
able help newcomers.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Provide different sets of .emacs [Was: Enabling Transient Mark Mode by default]

[William Xu]

David Reitter <david.reitter@gmail.com> writes:

> Is it possible to satisfy both types of users?
> Can't there be two variants of Emacs?

This discussion grows so huge...  I think we can provide different sets
of .emacs aiming at different people. 

In the EMMS[1] project, we have a separate file `emms-setup.el' dealing
with a similar situation, it includes four pre-defined sets of
configurations: 

,----[ four configurations ]
| (defun emms-minimalistic ()
|   "An Emms setup script.
| Invisible playlists and all the basics for playing media."
| )
| 
| (defun emms-standard ()
|   "An Emms setup script.
| Everything included in the `emms-minimalistic' setup, the Emms
| interactive playlist mode, reading information from tagged
| audio files, and a metadata cache."
| )     
| 
| (defun emms-all ()
|   "An Emms setup script.
| Everything included in the `emms-standard' setup and adds all the
| stable features which come with the Emms distribution."
| )
| 
| (defun emms-devel ()
|   "An Emms setup script.
| Everything included in the `emms-all' setup and adds all the
| features which come with the Emms distribution regardless of if
| they are considered stable or not.  Use this if you like living
| on the edge."
| )
`----

Emacs could have something similar, like emacs-newbie, emacs-guru...
Then for instance, in this thread, we can make transient-mark-mode off
in emacs-newbie and on in emacs-guru.  That will make everyone happy,
right? After all, you just need one command jumping to different set of
configurations.


Footnotes, 
[1] EMMS, http://www.gnu.org/software/emms/

-- 
William

http://williamxu.net9.org

Re: Provide different sets of .emacs

[William Xu]

Correction: swap `off' and `on'.

William Xu <william.xwl@gmail.com> writes:

> we can make transient-mark-mode off
> in emacs-newbie and on in emacs-guru.

-- 
William

http://williamxu.net9.org

Re: Enabling Transient Mark Mode by default

[Mathias Dahl]

> IMO, defaults should be choosen, if possible, so the behavior is what
> most new users would expect. An experienced user will research how to
> deactivate something that he doesn't like. A newbie will perhaps just
> give up.

I agree, and this has happened to at least two colleagues, people I
know would have liked Emacs if they just had hung in there a little
longer. I have been able to convince one of them that Emacs is the way
to go by showing him some killer features, and he is now happily
Emacsing along. The other colleague gave up when C-c/v/x did not do
what he expected. He said he became to stressed when the app did not
behave like he was used to, and he felt it interfered with his work.
Anyway, I would not go as far as saying that CUA should be on by
default, because I think that generates other problems. I guess my
point is that a lot of people give up more easily today so good
defaults are important.

Re: Enabling Transient Mark Mode by default

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

>> IMO, defaults should be choosen, if possible, so the behavior is what
>> most new users would expect. An experienced user will research how to
>> deactivate something that he doesn't like. A newbie will perhaps just
>> give up.
>
> I agree, and this has happened to at least two colleagues, people I
> know would have liked Emacs if they just had hung in there a little
> longer.

How do you know that?

> I have been able to convince one of them that Emacs is the way to go
> by showing him some killer features, and he is now happily Emacsing
> along. The other colleague gave up when C-c/v/x did not do what he
> expected. He said he became to stressed when the app did not behave
> like he was used to, and he felt it interfered with his work.

Emacs would have behaved different from his expectations in a lot of
other respects, anyway.  And never being to tell what C-x is actually
going to do or why it does not work in one or the other manner just when
one expects it is not going to be the ultimate stress reducer, anyway.

> Anyway, I would not go as far as saying that CUA should be on by
> default, because I think that generates other problems. I guess my
> point is that a lot of people give up more easily today so good
> defaults are important.

People that give up easily will not work with complex software of any
kind, anyway.  We need to focus on our target clientele rather than
bothering to keep some people a few minutes longer.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Mathias Dahl]

> > I agree, and this has happened to at least two colleagues, people I
> > know would have liked Emacs if they just had hung in there a little
> > longer.
>
> How do you know that?

I have talked to them about it, but of course I cannot be sure, they
might be lying to me.

> People that give up easily will not work with complex software of any
> kind, anyway.

"How do you know that?" Do you know my colleagues? Do you know what
they work with, what tools they use? Sigh...

> We need to focus on our target clientele rather than
> bothering to keep some people a few minutes longer.

What is our target audience then? They were my target audience,
apparently. When I find nice functions in program X or Y it pains me
when I see people crawling around in the mud with notepad.exe or
whatever and I want them to see the light as well. Maybe that is my
problem, that I want to help people...

Re: Enabling Transient Mark Mode by default

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

> What is our target audience then? They were my target audience,
> apparently.

Sure, but not Emacs' target audience.

> When I find nice functions in program X or Y it pains me when I see
> people crawling around in the mud with notepad.exe or whatever and I
> want them to see the light as well. Maybe that is my problem, that I
> want to help people...

You can lead a dragon to water, but you can't make it drink.  And a
layer of gasoline will burn off fast and not make a noticeable
difference.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Mathias Dahl]

> > What is our target audience then? They were my target audience,
> > apparently.
>
> Sure, but not Emacs' target audience.

What is Emacs' target audience? Please, tell me, so that I can skip
advocating Emacs to the wrong audience.

Re: Enabling Transient Mark Mode by default

[David Kastrup]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

>> > What is our target audience then? They were my target audience,
>> > apparently.
>>
>> Sure, but not Emacs' target audience.
>
> What is Emacs' target audience? Please, tell me, so that I can skip
> advocating Emacs to the wrong audience.

People comfortable working with a large humongous set of loosely related
tools, packages, editing modes and keybindings on a Lisp-based rapid
prototyping platform for editing.

People who would rather stop using an editor than electing to set an
option are not Emacs' target audience.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

> It's not that much of a problem for a simple (transient-mark-mode -1)
> in .emacs fixes it.  But on the other hand I'm still missing a good
> reason for activating it in the first place (after skimming briefly
> over this thread).  And "it might be ok" is not equal to "it's a good
> thing to do", IMO.

Whenever I use "emacs -Q" or some similar "vanilla Emacs", the first
thing that I'm urged to do is M-x transient-mark-mode (and it was
already N°1 back when fotn-lock-mode wasn't the default).

Of course, I'm sure I'd be able to learn to live without it.  It seems
like an option affect people *very* strongly, so those who want it
*really* want it, and those who don't *really* don't.

So, that's for my personal preference.  As to why turn it on *by
default*, here are some reasons why I think it should be ON by default:
- Visual feedback about the mark's position and active status.
  I and all (X)Emacs users I know personally (i.e. off-this-list) and
  with whom I've talked about transient-mark-mode use
  transient-mark-mode (or its XEmacs equivalent) and find it difficult
  to use Emacs without it because of the lack of visual feedback about
  where the mark really is.  I do not claim that this small group of
  people is representative, but it does seem relevant.
- Extended semantics for various commands.
  Many commands now offer to operate on the region if the region is
  active but only when transient-mark-mode is ON.
  This functionality is now also available to non-tmm-users via the
  temporary-transient-mark-mode (C-SPC C-SPC), admittedly, but while
  C-SPC C-SPC is easy enough to use, I always find myself selecting the
  region *before* knowing that I want to use such a command (or
  selecting the region with something else than C-SPC, typically
  C-M-SPC), so I end up having to use C-u C-x C-x which I find a lot
  more inconvenient.


-- Stefan

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Whenever I use "emacs -Q" or some similar "vanilla Emacs", the first
> thing that I'm urged to do is M-x transient-mark-mode (and it was
> already N°1 back when fotn-lock-mode wasn't the default).
>
> Of course, I'm sure I'd be able to learn to live without it.  It seems
> like an option affect people *very* strongly, so those who want it
> *really* want it, and those who don't *really* don't.

That means that it has presumably some strong advantages and some strong
disadvantages.  If they are not immediate consequences of one another,
the controversy might be better resolved by lessening the disadvantages
rather than having to choose.

> So, that's for my personal preference.  As to why turn it on *by
> default*, here are some reasons why I think it should be ON by default:
> - Visual feedback about the mark's position and active status.
>   I and all (X)Emacs users I know personally (i.e. off-this-list) and
>   with whom I've talked about transient-mark-mode use
>   transient-mark-mode (or its XEmacs equivalent)

All I know personally can't stand it.  Now what?

> and find it difficult to use Emacs without it because of the lack of
> visual feedback about where the mark really is.

Huh?  That's what C-x C-x is for (among other things).  And if you want
a more permanent feedback, even C-u C-x C-x is now available.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

>> Whenever I use "emacs -Q" or some similar "vanilla Emacs", the first
>> thing that I'm urged to do is M-x transient-mark-mode (and it was
>> already N°1 back when fotn-lock-mode wasn't the default).
>> 
>> Of course, I'm sure I'd be able to learn to live without it.  It seems
>> like an option affect people *very* strongly, so those who want it
>> *really* want it, and those who don't *really* don't.

> That means that it has presumably some strong advantages and some strong
> disadvantages.  If they are not immediate consequences of one another,
> the controversy might be better resolved by lessening the disadvantages
> rather than having to choose.

If anybody has an idea how to reduce the disadvantage of tmm, I'm
all ears.  `mark-even-if-inactive' is already set, so most things work
exactly as before (other than visual artifacts).  So all that's left is
the visual "burden" and the cases where the mark is active when you
don't want it.  The visual burden boils down to the choice of colors and
I'll let other people deal with this (I use "grey75", for what it's
worth).

The issue of the mark being active when you don't want it, is
particularly acute for people who push marks for navigation purposes.
Maybe we could make C-SPC C-SPC in tmm push the mark and deactivate it.
That might be sufficient for those people who occasionally push marks
for navigation.  For those who do it often, the best is for them to turn
off transient-mark-mode.


        Stefan

Re: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

On 20/02/2008, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>  The issue of the mark being active when you don't want it, is
>  particularly acute for people who push marks for navigation purposes.
>  Maybe we could make C-SPC C-SPC in tmm push the mark and deactivate it.
>  That might be sufficient for those people who occasionally push marks
>  for navigation.  For those who do it often, the best is for them to turn
>  off transient-mark-mode.
>

I use tmm and sometimes push marks just for navigation, but I then
just hit C-g to get immediately rid of the activation (when I bother
at all) after a C-SPC - the mark is still pushed.  C-SPC C-g is only
slightly more awkward than C-SPC C-SPC.

Re: Enabling Transient Mark Mode by default

[David Kastrup]

"David De La Harpe Golden" <david.delaharpe.golden@gmail.com> writes:

> On 20/02/2008, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>  The issue of the mark being active when you don't want it, is
>>  particularly acute for people who push marks for navigation purposes.
>>  Maybe we could make C-SPC C-SPC in tmm push the mark and deactivate it.
>>  That might be sufficient for those people who occasionally push marks
>>  for navigation.  For those who do it often, the best is for them to turn
>>  off transient-mark-mode.
>>
>
> I use tmm and sometimes push marks just for navigation, but I then
> just hit C-g to get immediately rid of the activation (when I bother
> at all) after a C-SPC - the mark is still pushed.  C-SPC C-g is only
> slightly more awkward than C-SPC C-SPC.

From the number of keystrokes.  But between C-SPC and C-g I get annoyed,
and that takes longer to wear off.  And if you happened to have a slow X
connection, the cost of the entire screen flashing the mark-active face
in your face might also cause an interruption of work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

On 20/02/2008, David Kastrup <dak@gnu.org> wrote:
> "David De La Harpe Golden" <david.delaharpe.golden@gmail.com> writes:

>  > I use tmm and sometimes push marks just for navigation, but I then
>  > just hit C-g to get immediately rid of the activation (when I bother
>  > at all) after a C-SPC - the mark is still pushed.  C-SPC C-g is only
>  > slightly more awkward than C-SPC C-SPC.
>
>
> From the number of keystrokes.  But between C-SPC and C-g I get annoyed,
>  and that takes longer to wear off.  And if you happened to have a slow X
>  connection, the cost of the entire screen flashing the mark-active face
>  in your face might also cause an interruption of work.

I don't see why that should happen prescisely.  C-SPC directly
followed by C-g shouldn't cause any highlighting, the point wouldn't
move.  More annoying might be the bell or visual-bell C-g might cause,
though that is of course customisable.

Re: Enabling Transient Mark Mode by default

[Juri Linkov]

>>  > I use tmm and sometimes push marks just for navigation, but I then
>>  > just hit C-g to get immediately rid of the activation (when I bother
>>  > at all) after a C-SPC - the mark is still pushed.  C-SPC C-g is only
>>  > slightly more awkward than C-SPC C-SPC.
>>
>> From the number of keystrokes.  But between C-SPC and C-g I get annoyed,
>>  and that takes longer to wear off.  And if you happened to have a slow X
>>  connection, the cost of the entire screen flashing the mark-active face
>>  in your face might also cause an interruption of work.
>
> I don't see why that should happen prescisely.  C-SPC directly
> followed by C-g shouldn't cause any highlighting, the point wouldn't
> move.  More annoying might be the bell or visual-bell C-g might cause,
> though that is of course customisable.

Deactivating the region without the bell is possible with
keyboard-escape-quit.

But even this is not necessary: cua-selection-mode uses C-SPC C-SPC
to set the mark without activating the region (more precisely the second
C-SPC cancels the region activation).  This is another reason to enable
cua-selection-mode by default because this will help people who use
the mark for navigational purposes.

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

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Puh! This was a long thread with lots of details. After reading it all I 
think I agree with Juri, there are good reasons to turn on 
cua-selection-mode by default. It looks like Kim already have been 
travelling the road we are on now.

It looks to me like cua-selection-mode/cua-mode does not disturb the use 
of the mark ring. Or does it? I do not use the mark ring myself. (Sasha? 
Stefan?)

I have cut and paste some arguments here for convenience and added some 
comments:

Juri Linkov wrote:
> Deactivating the region without the bell is possible with
> keyboard-escape-quit.
> 
> But even this is not necessary: cua-selection-mode uses C-SPC C-SPC
> to set the mark without activating the region (more precisely the second
> C-SPC cancels the region activation).  This is another reason to enable
> cua-selection-mode by default because this will help people who use
> the mark for navigational purposes.

Juri Linkov wrote:
 > In cua-selection-mode point movement deactivates the region only when
 > the region was activated by shift-arrows.  But when the region is
 > activated by C-SPC, point movements extend the active region.

I think this could be made a little bit more useful without sacrificing 
consistency.

cua-mode/cua-selection-mode activates the region with shift added to 
some commands: arrows/home/end /C-arrows/C-home/C-end and deactivates 
them if they are used without shift. This is how other applications 
tends to do it too. So this is good in my opinion.

However when it comes to other movement commands I think they should 
extend the region since that is useful. If you want to deactivate the 
region that is easy enough (C-g, the commands above).


David De La Harpe Golden wrote:
 > On 21/02/2008, David De La Harpe Golden
 >>  Given apparent concern over mouse then keyboard interaction, maybe
 >>  pc-selection-mode needs to also deactivate the mark when cursor moves
 >>  after the _mouse_ has set the region...
 >
 > er... which cua-selection-mode already does...


Richard Stallman wrote:
 >     I am still trying to grasp the problem. Apart from the region to act
 >     with CUA keys like in all main applications I use today I would 
expect
 >
 >     * operations on the region should only happen when the region is 
visible
 >
 > I do not understand clearly what you mean.
 >
 > Are you proposing a change?  If so, what _concretely_ is that change?

Yes. A bit more consistency. I think for all commands for which it is 
useful to work for the region only they should do so when the region is 
highlighted, otherwise not.

However I should add that some users seem to want to have the region 
active but not highlighted. That should be an option that they should 
turn on if they want it.


Stefan Monnier wrote:
 >> Don't we all think that new users probably want the highlight the way
 >> cua-mode does it?
 >
 > Actually, in this respect, cua-mode isn't very different, as far as
 > I can tell: you also get into those situations where the region is
 > highlighted when you don't want it and you have to hit C-g to get rid
 > of it.

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

It looks like something went wrong so I am resending this. Sorry if 
someone gets it twice.

Lennart Borgman (gmail) wrote:
> Puh! This was a long thread with lots of details. After reading it all I 
> think I agree with Juri, there are good reasons to turn on 
> cua-selection-mode by default (and have highlight of an active region on).
 > It looks like Kim already have been travelling the road we are on now.
> 
> It looks to me like cua-selection-mode/cua-mode does not disturb the use 
> of the mark ring. Or does it? I do not use the mark ring myself. (Sasha? 
> Stefan?)
> 
> I have cut and paste some arguments here for convenience and added some 
> comments:
> 
> Juri Linkov wrote:
>> Deactivating the region without the bell is possible with
>> keyboard-escape-quit.
>>
>> But even this is not necessary: cua-selection-mode uses C-SPC C-SPC
>> to set the mark without activating the region (more precisely the second
>> C-SPC cancels the region activation).  This is another reason to enable
>> cua-selection-mode by default because this will help people who use
>> the mark for navigational purposes.
> 
> Juri Linkov wrote:
>  > In cua-selection-mode point movement deactivates the region only when
>  > the region was activated by shift-arrows.  But when the region is
>  > activated by C-SPC, point movements extend the active region.
> 
> I think this could be made a little bit more useful without sacrificing 
> consistency.
> 
> cua-mode/cua-selection-mode activates the region with shift added to 
> some commands: arrows/home/end /C-arrows/C-home/C-end and deactivates 
> them if they are used without shift. This is how other applications 
> tends to do it too. So this is good in my opinion.
> 
> However when it comes to other movement commands I think they should 
> extend the region since that is useful. If you want to deactivate the 
> region that is easy enough (C-g, the commands above).
> 
> 
> David De La Harpe Golden wrote:
>  > On 21/02/2008, David De La Harpe Golden
>  >>  Given apparent concern over mouse then keyboard interaction, maybe
>  >>  pc-selection-mode needs to also deactivate the mark when cursor moves
>  >>  after the _mouse_ has set the region...
>  >
>  > er... which cua-selection-mode already does...
> 
> 
> Richard Stallman wrote:
>  >     I am still trying to grasp the problem. Apart from the region to act
>  >     with CUA keys like in all main applications I use today I would 
> expect
>  >
>  >     * operations on the region should only happen when the region is 
> visible
>  >
>  > I do not understand clearly what you mean.
>  >
>  > Are you proposing a change?  If so, what _concretely_ is that change?
> 
> Yes. A bit more consistency. I think for all commands for which it is 
> useful to work for the region only they should do so when the region is 
> highlighted, otherwise not.
> 
> However I should add that some users seem to want to have the region 
> active but not highlighted. That should be an option that they should 
> turn on if they want it.
> 
> 
> Stefan Monnier wrote:
>  >> Don't we all think that new users probably want the highlight the way
>  >> cua-mode does it?
>  >
>  > Actually, in this respect, cua-mode isn't very different, as far as
>  > I can tell: you also get into those situations where the region is
>  > highlighted when you don't want it and you have to hit C-g to get rid
>  > of it.
> 
> 

Re: Enabling Transient Mark Mode by default

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> But even this is not necessary: cua-selection-mode uses C-SPC C-SPC
> to set the mark without activating the region (more precisely the second
> C-SPC cancels the region activation).  This is another reason to enable
> cua-selection-mode by default because this will help people who use
> the mark for navigational purposes.

No it's not.  If that feature is desired (seems ok to me), it should
just be added to normal t-m-m.

-Miles

-- 
Politeness, n. The most acceptable hypocrisy.

Fwd: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Argh, effing gmail.  resending, to people besides Miles this time (sorry Miles).

On 22/02/2008, Miles Bader <miles.bader@necel.com> wrote:
 > Juri Linkov <juri@jurta.org> writes:
 >  > But even this is not necessary: cua-selection-mode uses C-SPC C-SPC
 >  > to set the mark without activating the region (more precisely the second
 >  > C-SPC cancels the region activation).  This is another reason to enable
 >  > cua-selection-mode by default because this will help people who use
 >  > the mark for navigational purposes.
 >
 >
 > No it's not.  If that feature is desired (seems ok to me), it should
 >  just be added to normal t-m-m.

Well, it does have slight discoverability and ease-of-typing
 advantages over C-SPC C-g.

 Small thing to add to set-mark-command.  Might also be ui-consistent
 to augment momentary mark (transient-mark-mode = lambda) similarly
 i.e.
 when transient-mark-mode is t (perma-on), C-SPC C-SPC deactivates
 mark, but when transient-mark-mode is off, a third C-SPC after
 the C-SPC C-SPC turning on momentary mark cancels the momentary mark?

 Illustrative/trivial patch attached, seems nice in small tests, but
 dunno if there are any awful ramifications.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: disable-mark-on-c-spc-c-spc.diff --]
[-- Type: text/x-diff; name=disable-mark-on-c-spc-c-spc.diff, Size: 1944 bytes --]

--- lisp/simple.el
+++ lisp/simple.el
@@ -3455,7 +3455,11 @@
 old mark position on local mark ring.  Also push the old mark on
 global mark ring, if the previous mark was set in another buffer.
 
-Immediately repeating this command activates `transient-mark-mode' temporarily.
+When `transient-mark-mode' is off, immediately repeating this command 
+activates `transient-mark-mode' temporarily, immediately repeating it 
+again  deactivates that temporary activation and the mark.  When 
+`transient-mark-mode' is on, immediately repeating this command
+deactivates the mark (mark having been activated by the preceding).
 
 With prefix argument \(e.g., \\[universal-argument] \\[set-mark-command]\), \
 jump to the mark, and set the mark from
@@ -3474,6 +3478,7 @@
 Novice Emacs Lisp programmers often try to use the mark for the wrong
 purposes.  See the documentation of `set-mark' for more information."
   (interactive "P")
+  (let ((last-transient-mark-mode transient-mark-mode))
   (if (eq transient-mark-mode 'lambda)
       (setq transient-mark-mode nil))
   (cond
@@ -3496,11 +3501,20 @@
     (setq this-command 'pop-to-mark-command)
     (pop-to-mark-command))
    ((and (eq last-command 'set-mark-command)
+	 mark-active (eq 'lambda last-transient-mark-mode))
+    (deactivate-mark)
+    (setq transient-mark-mode nil)
+    (message "Disabled temporarily enabled Transient-mark-mode"))
+   ((and (eq last-command 'set-mark-command)
 	 mark-active (null transient-mark-mode))
     (setq transient-mark-mode 'lambda)
     (message "Transient-mark-mode temporarily enabled"))
+   ((and (eq last-command 'set-mark-command)
+         mark-active (eq t transient-mark-mode))
+    (deactivate-mark)
+    (message "Mark deactivated"))
    (t
-    (push-mark-command nil))))
+    (push-mark-command nil)))))
 
 (defun push-mark (&optional location nomsg activate)
   "Set mark at LOCATION (point, by default) and push old mark on mark ring.

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    > But even this is not necessary: cua-selection-mode uses C-SPC C-SPC
    > to set the mark without activating the region (more precisely the second
    > C-SPC cancels the region activation).

    No it's not.  If that feature is desired (seems ok to me), it should
    just be added to normal t-m-m.

That makes sense to me.  Just as C-SPC C-SPC enables a temporarily
specially active region when that's not the default (Transient Mark
mode disabled), it could set the mark and not activate in the mode
where activating is the default (Transient Mark mode enabled).

I am not sure whether it is useful, but there is no reason to reject
it if it is useful.

Re: Enabling Transient Mark Mode by default

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     No it's not.  If that feature is desired (seems ok to me), it should
>     just be added to normal t-m-m.
>
> That makes sense to me.  Just as C-SPC C-SPC enables a temporarily
> specially active region when that's not the default (Transient Mark
> mode disabled), it could set the mark and not activate in the mode
> where activating is the default (Transient Mark mode enabled).
>
> I am not sure whether it is useful, but there is no reason to reject
> it if it is useful.

Now that I think about it, I really like this idea:  it's very easy to
understand that C-SPC C-SPC and C-SPC are "active and non-active"
mark-setting commands, and simply swap roles depending on whether
full-t-m-mode is enabled, and obviously C-SPC C-SPC is very convenient
to type.

I've never really used the "push a mark" command much, as I use
t-m-mode, but I think if C-SPC C-SPC pushed a non-active mark, I would
use it more often.

-Miles

-- 
Freebooter, n. A conqueror in a small way of business, whose annexations lack
of the sanctifying merit of magnitude.

Re: Enabling Transient Mark Mode by default

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Sat, 23 Feb 2008 09:09:34 +0900
Miles Bader <miles@gnu.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
> >     No it's not.  If that feature is desired (seems ok to me), it
> > should just be added to normal t-m-m.
> >
> > That makes sense to me.  Just as C-SPC C-SPC enables a temporarily
> > specially active region when that's not the default (Transient Mark
> > mode disabled), it could set the mark and not activate in the mode
> > where activating is the default (Transient Mark mode enabled).
> >
> > I am not sure whether it is useful, but there is no reason to reject
> > it if it is useful.
> 
> Now that I think about it, I really like this idea:  it's very easy to
> understand that C-SPC C-SPC and C-SPC are "active and non-active"
> mark-setting commands, and simply swap roles depending on whether
> full-t-m-mode is enabled, and obviously C-SPC C-SPC is very convenient
> to type.
> 
> I've never really used the "push a mark" command much, as I use
> t-m-mode, but I think if C-SPC C-SPC pushed a non-active mark, I would
> use it more often.

It will rock your world :) especially when you consider that the mark-ring is
a list. I am going to cook up a function that assumes the marks of the ring
are inside defuns.

That way I can quickly extract several functions by dropping a mark on each
one as I scan through the buffer, and then collect them off the mark ring.
Just one idea, but it's food for thought. It's great to be able to leave
a trail. or apply commands beyond a linear region.

A mark is insanely great when it is just a mark.
 
> -Miles
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Enabling Transient Mark Mode by default

[Drew Adams]

> I am going to cook up a function that assumes the 
> marks of the ring are inside defuns.
> 
> That way I can quickly extract several functions by dropping 
> a mark on each one as I scan through the buffer, and then
> collect them off the mark ring. Just one idea, but it's food
> for thought. It's great to be able to leave
> a trail. or apply commands beyond a linear region.

You might be interested in Icicles command `icicle-goto-marker' (also
`icicle-goto-global-marker'). It's like a dynamic, completing `occur' for
the `mark-ring' (or the `global-mark-ring'). It's a multi-command, so you
can use it as a browser.

If you want to visit only function definitions, use `icicle-imenu' or
`icicle-search-tag' - similar functionality.

Re: Enabling Transient Mark Mode by default

[Bastien]

Miles Bader <miles@gnu.org> writes:

> Now that I think about it, I really like this idea:  it's very easy to
> understand that C-SPC C-SPC and C-SPC are "active and non-active"
> mark-setting commands, and simply swap roles depending on whether
> full-t-m-mode is enabled, and obviously C-SPC C-SPC is very convenient
> to type.

+1

> I've never really used the "push a mark" command much, as I use
> t-m-mode, but I think if C-SPC C-SPC pushed a non-active mark, I would
> use it more often.

I've never really used t-m-mode, as I often push marks, but I think if
C-SPC C-SPC pushed a non-active mark, I would use it more often.

:)

-- 
Bastien

Re: Enabling Transient Mark Mode by default

[Sascha Wilde]

Bastien <bzg@altern.org> wrote:

> Miles Bader <miles@gnu.org> writes:
>
>> Now that I think about it, I really like this idea:  it's very easy to
>> understand that C-SPC C-SPC and C-SPC are "active and non-active"
>> mark-setting commands, and simply swap roles depending on whether
>> full-t-m-mode is enabled, and obviously C-SPC C-SPC is very convenient
>> to type.
>
> +1

+1

sascha
-- 
Sascha Wilde
To become a Jedi, use Emacs you have to.

Re: Enabling Transient Mark Mode by default

[Bastien]

Richard Stallman <rms@gnu.org> writes:

>     > But even this is not necessary: cua-selection-mode uses C-SPC C-SPC
>     > to set the mark without activating the region (more precisely the second
>     > C-SPC cancels the region activation).
>
>     No it's not.  If that feature is desired (seems ok to me), it should
>     just be added to normal t-m-m.
>
> That makes sense to me.  Just as C-SPC C-SPC enables a temporarily
> specially active region when that's not the default (Transient Mark
> mode disabled), it could set the mark and not activate in the mode
> where activating is the default (Transient Mark mode enabled).
>
> I am not sure whether it is useful, but there is no reason to reject
> it if it is useful.

FWIW I think this would be useful.

This is what I had in mind when I proposed that C-SPC C-SPC could
temporarily negate `transient-mark-mode'[1].

And now I realize that, if C-SPC C-SPC temporarily negates the value of
`transient-mark-mode', then swapping the commands behind C-SPC and C-SPC
C-SPC [2] is strictly an equivalent of setting `transient-mark-mode' to
non-nil by default.  Or am I missing something?

[1]  <87mypsoo6k.fsf@bzg.ath.cx>
[2]  <87r6f4oogj.fsf@bzg.ath.cx>

-- 
Bastien

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

> `transient-mark-mode', then swapping the commands behind C-SPC and C-SPC
> C-SPC [2] is strictly an equivalent of setting `transient-mark-mode' to
> non-nil by default.  Or am I missing something?

You're missing the other commands that activate the mark, e.g. mark-*


        Stefan

Re: Enabling Transient Mark Mode by default

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> `transient-mark-mode', then swapping the commands behind C-SPC and C-SPC
>> C-SPC [2] is strictly an equivalent of setting `transient-mark-mode' to
>> non-nil by default.  Or am I missing something?
>
> You're missing the other commands that activate the mark, e.g. mark-*

Right.  

I guess the ambiguity you pointed before between the use of the mark for
navigation purpose and for selecting a region is not really relevant for
mark-*, which I guess are not really ever used for navigation.

But maybe I'm wrong on this.

In any case I would find it useful to have an intermediary route between
Transient Mark mode enabled and disabled, namely the one where setting
the mark with C-SPC also temporarily enable Transient Mark mode (with
just one keystroke, and without mark-* highlighting the region.)

(Here I can ear the movie soundtrack: "This thread is dead.")

-- 
Bastien

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    And now I realize that, if C-SPC C-SPC temporarily negates the value of
    `transient-mark-mode', then swapping the commands behind C-SPC and C-SPC
    C-SPC [2] is strictly an equivalent of setting `transient-mark-mode' to
    non-nil by default.  Or am I missing something?

The proposal I'm talking about is that Transient Mark mode
should effectively swap the meanings of C-SPC and C-SPC C-SPC.

Perhaps there was a misunderstanding about that.

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> The issue of the mark being active when you don't want it, is
> particularly acute for people who push marks for navigation purposes.
> Maybe we could make C-SPC C-SPC in tmm push the mark and deactivate it.
> That might be sufficient for those people who occasionally push marks
> for navigation.  For those who do it often, the best is for them to turn
> off transient-mark-mode.


I am still trying to grasp the problem. Apart from the region to act 
with CUA keys like in all main applications I use today I would expect

* operations on the region should only happen when the region is visible

However this seems to interfere with the definition of the mark as 
active/inactive. Is this necessary?

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    I am still trying to grasp the problem. Apart from the region to act 
    with CUA keys like in all main applications I use today I would expect

    * operations on the region should only happen when the region is visible

I do not understand clearly what you mean.

Are you proposing a change?  If so, what _concretely_ is that change?

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    The issue of the mark being active when you don't want it, is
    particularly acute for people who push marks for navigation purposes.

Could you explain what you mean by this?  As far as I know, the mark
is active now in the same cases where it would be active when
Transient Mark mode is not enabled.

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

>     The issue of the mark being active when you don't want it, is
>     particularly acute for people who push marks for navigation purposes.

> Could you explain what you mean by this?  As far as I know, the mark
> is active now in the same cases where it would be active when
> Transient Mark mode is not enabled.

For people who use the mark(s) for navigational purposes, pushing the
mark is an operation comparable to saving point to a register.
So the fact that TMM starts to highlight the text between that mark and
point is just a hassle.

I.e. those people will often activate the mark just because they wanted
to add a position to the mark-ring, not because they cared particularly
about activating the mark.  Without TMM, activating the mark
unnecessarily is harmless, but not with TMM.


        Stefan

Re: Enabling Transient Mark Mode by default

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Could you explain what you mean by this?  As far as I know, the mark
>> is active now in the same cases where it would be active when
>> Transient Mark mode is not enabled.
>
> For people who use the mark(s) for navigational purposes, pushing the
> mark is an operation comparable to saving point to a register.
> So the fact that TMM starts to highlight the text between that mark and
> point is just a hassle.

What about this:

  C-SPC  set the mark and temporarily turn on Transient Mark mode
    C-@  only sets the mark

C-SPC C-SPC would be used to temporarily negate transient-mark-mode.
(For now it does not *negate* it, it turns it on temporarily.)

The benefits of such a small change would be:

- for the ordinary use of the mark (C-SPC), it is a bit like setting
  transient-mark-mode on by default;

- it makes a clear distinction between using the mark for navigating
  purposes (C-@) and using the mark for selecting and highlighting a
  region (C-SPC);

- people could use C-SPC or C-@ depending on what they locally need, 
  not on the basis of some unsteady global preference.

I think finding the right usage for the temporary transient-mark-mode 
is a key point in this issue.  

-- 
Bastien

Re: Enabling Transient Mark Mode by default

[Sascha Wilde]

Bastien <bzg@altern.org> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> For people who use the mark(s) for navigational purposes, pushing the
>> mark is an operation comparable to saving point to a register.
>> So the fact that TMM starts to highlight the text between that mark and
>> point is just a hassle.
>
> What about this:
>
>   C-SPC  set the mark and temporarily turn on Transient Mark mode
>     C-@  only sets the mark
>
> C-SPC C-SPC would be used to temporarily negate transient-mark-mode.
> (For now it does not *negate* it, it turns it on temporarily.)

Veto.

I think the current behavior is quite convenient and fits the needs of
those who don't want a permanent transient-mark-mode best.

> The benefits of such a small change would be:
>
> - for the ordinary use of the mark (C-SPC), it is a bit like setting
>   transient-mark-mode on by default;

And therefor for people like me it wouldn't be a benefit but an
obstacle.

> - it makes a clear distinction between using the mark for navigating
>   purposes (C-@) and using the mark for selecting and highlighting a
>   region (C-SPC);
> - people could use C-SPC or C-@ depending on what they locally need, 
>   not on the basis of some unsteady global preference.

This is clearly a change to the worse.  The old semantics are perfectly
good, they differ from what users of nowadays GUI-editors expect, but
they are perfectly consistent and highly usable.  Please don't change
them!  (FWIW C-@ is even harder to type than C-SPC)

cheers
sascha
-- 
Sascha Wilde
"Structure is _nothing_ if it is all you got.  Skeletons _spook_ people if
 thwy try to walk around on their own.  I really wonder why XML does
 not."            -- Erik Naggum <erik@naggum.net> in comp.lang.lisp

Re: Enabling Transient Mark Mode by default

[Bastien Guerry]

Sascha Wilde <wilde@sha-bang.de> writes:

> Bastien <bzg@altern.org> wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> For people who use the mark(s) for navigational purposes, pushing the
>>> mark is an operation comparable to saving point to a register.
>>> So the fact that TMM starts to highlight the text between that mark and
>>> point is just a hassle.
>>
>> What about this:
>>
>>   C-SPC  set the mark and temporarily turn on Transient Mark mode
>>     C-@  only sets the mark
>>
>> C-SPC C-SPC would be used to temporarily negate transient-mark-mode.
>> (For now it does not *negate* it, it turns it on temporarily.)
>
> Veto.
>
> I think the current behavior is quite convenient and fits the needs of
> those who don't want a permanent transient-mark-mode best.

My point is that there are really two ways of having the active region
highlighted by default: either by setting transient-mark-mode to t, or
by letting C-SPC turn Transient Mark mode temporarily on.

If we go for the first solution, I guess it is useful for C-SPC C-SPC 
to temporarily *negate* transient-mark-mode (not to turn it on.)

If we go for the second solution, I think it is useful for C-@ to set
the mark without activating/highlighting the region, so that people
don't have to turn off transient-mark-mode to be able to use the mark
for navigation purpose only.

If the issue is that C-@ is hard to type, then let's use C-SPC for
whatever the default is (set mark or set the mark and activate and
highlight the region temporarily) and let's use C-@ for the other.

I can see no harm in using C-SPC and C-@ for different purposes.  

-- 
Bastien

Re: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

On 22/02/2008, Bastien Guerry <Bastien.Guerry@ens.fr> wrote:

>  I can see no harm in using C-SPC and C-@ for different purposes.
>

Text terminals may not distinguish between C-SPC and C-@.

> or by letting C-SPC turn Transient Mark mode temporarily on.

You're aware that C-SPC C-SPC already temporarily turns it on?

Re: Enabling Transient Mark Mode by default

[Bastien]

"David De La Harpe Golden" <david.delaharpe.golden@gmail.com> writes:

> On 22/02/2008, Bastien Guerry <Bastien.Guerry@ens.fr> wrote:
>
>>  I can see no harm in using C-SPC and C-@ for different purposes.
>
> Text terminals may not distinguish between C-SPC and C-@.

I did not know that, thanks for pointing this.

>> or by letting C-SPC turn Transient Mark mode temporarily on.
>
> You're aware that C-SPC C-SPC already temporarily turns it on?

Yes.  The aim of my proposal was to focus the discussion on swaping the
commands associated with C-SPC and C-SPC C-SPC, rather than deciding if
Transient Mark mode should be globally enable by default.  

-- 
Bastien

Re: Enabling Transient Mark Mode by default

[Sascha Wilde]

Bastien Guerry <Bastien.Guerry@ens.fr> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> Bastien <bzg@altern.org> wrote:
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> For people who use the mark(s) for navigational purposes, pushing the
>>>> mark is an operation comparable to saving point to a register.
>>>> So the fact that TMM starts to highlight the text between that mark and
>>>> point is just a hassle.
>>>
>>> What about this:
>>>
>>>   C-SPC  set the mark and temporarily turn on Transient Mark mode
>>>     C-@  only sets the mark
>>>
>>> C-SPC C-SPC would be used to temporarily negate transient-mark-mode.
>>> (For now it does not *negate* it, it turns it on temporarily.)
>>
>> Veto.
>>
>> I think the current behavior is quite convenient and fits the needs of
>> those who don't want a permanent transient-mark-mode best.
>
> My point is that there are really two ways of having the active region
> highlighted by default: either by setting transient-mark-mode to t, or
> by letting C-SPC turn Transient Mark mode temporarily on.

The difference is that in the case of setting transient-mark-mode to t I
can still put (transient-mark-mode -1) in my .emacs file to get back the
old behavior.  In case of the later "solution" there would be no way to
get back the original behavior -- or am I mistaken?

cheers
sascha
-- 
Sascha Wilde  :  "The PROPER way to handle HTML postings is to cancel
the article, then hire a hitman to kill the poster, his wife and kids,
and fuck his dog and smash his computer into little bits. Anything
more is just extremism."  -- Paul Tomblin

Re: Enabling Transient Mark Mode by default

[Bastien]

Sascha Wilde <wilde@sha-bang.de> writes:

>> My point is that there are really two ways of having the active region
>> highlighted by default: either by setting transient-mark-mode to t, or
>> by letting C-SPC turn Transient Mark mode temporarily on.
>
> The difference is that in the case of setting transient-mark-mode to t I
> can still put (transient-mark-mode -1) in my .emacs file to get back the
> old behavior.  In case of the later "solution" there would be no way to
> get back the original behavior -- or am I mistaken?

Since C-@ would be bound to the old C-SPC behavior (only set mark) you
would be able to set C-SPC back to this old behavior.

Or you would have a variable deciding whether C-SPC should trigger
Transient Mark mode temporarily.  

-- 
Bastien

Re: Enabling Transient Mark Mode by default

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

On Fri, 22 Feb 2008 18:12:35 +0000
Bastien <bzg@altern.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
> 
> >> My point is that there are really two ways of having the active
> >> region highlighted by default: either by setting
> >> transient-mark-mode to t, or by letting C-SPC turn Transient Mark
> >> mode temporarily on.
> >
> > The difference is that in the case of setting transient-mark-mode
> > to t I can still put (transient-mark-mode -1) in my .emacs file to
> > get back the old behavior.  In case of the later "solution" there
> > would be no way to get back the original behavior -- or am I
> > mistaken?
> 
> Since C-@ would be bound to the old C-SPC behavior (only set mark) you
> would be able to set C-SPC back to this old behavior.
> 
> Or you would have a variable deciding whether C-SPC should trigger
> Transient Mark mode temporarily.  
> 

This works for me. swapping a couple of bindings is no problem. Couldn't this
swap be tied to transient mark mode ? so that enabling transient mode turns
on this new behavior ? or did I miss something in this monster thread ?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Enabling Transient Mark Mode by default

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 3343 bytes --]

On Fri, 22 Feb 2008 18:12:35 +0000
Bastien <bzg@altern.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
> 
> >> My point is that there are really two ways of having the active
> >> region highlighted by default: either by setting
> >> transient-mark-mode to t, or by letting C-SPC turn Transient Mark
> >> mode temporarily on.
> >
> > The difference is that in the case of setting transient-mark-mode
> > to t I can still put (transient-mark-mode -1) in my .emacs file to
> > get back the old behavior.  In case of the later "solution" there
> > would be no way to get back the original behavior -- or am I
> > mistaken?
> 
> Since C-@ would be bound to the old C-SPC behavior (only set mark) you
> would be able to set C-SPC back to this old behavior.
> 
> Or you would have a variable deciding whether C-SPC should trigger
> Transient Mark mode temporarily.  
> 

After following a bit of this thread I decided to challenge my assumptions
and strain my brain to come up with scenarios where highlighting is
truly useful.

I was able to dig up several. Ediff is I think the best example. The highlighting
shows precisely what changed, with a higher granularity than a plain context diff.
Simply put I am more effective at finding what I need with the highlighting since
it points me straight to my task, which is analyzing the difference in two buffers.

Another scenario is where I am not sure of my bounds. A good example is active-paren
which I use. When I am not sure of my brace matching placing my cursor on a paren
shows me the scope as long as it's within the viewport.

However when I am trying to delineate a span of text within a buffer a highlight does not
help me at all, because all it does is highlight the middle. My goal in creating a span
is to find the bounds, the middle is obviously implied!

You can try it yourself. Try to mark a region while looking at the highlighted part only.
Your stuck, because it's highlighting were you have been, not where you need to go.
To take paraphrase from Lewis Carrol, it's riding the horse backwards to see where you
have been.

I do see one way that it could be useful though. Often with active-paren when the opening
or closing brace is outside the viewport it degrades to showing the bounded line in the
minibuffer. With any luck this code fragment might pop up the image of where the bound
is in my head.

A useful highlighting would pop up/down some window ala icicles that automatically shrunk
to the required size, and highlighted up to the mark/boundary that was normally outside of
the viewport.

it would be good for active paren, and those cases where you do actually forget where you
dropped a mark. It would have to be on-demand as emacs would go nuts visually during simple
scrolling, but does that at least sounds useful and novel ?

Out of this enormous thread is it possible to invent a highlighting feature that shows me
*what I am looking for*, not what I already found ?

Or maybe rephrased can highlighting tell me what I don't already know ?

Cheers,
Mike Mattie

P.S: forgot isearch. useful highlighting there.

P.P.S: what about changing the arrow keys to move like M-f,M-b ? If I set a mark I probably
want to scoot around for navigation or creating a region. That would be useful.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

C-SPC is the easy way to type C-@.
We will not make C-@ and C-SPC different.

Re: Enabling Transient Mark Mode by default

[Andreas Schwab]

Bastien <bzg@altern.org> writes:

> What about this:
>
>   C-SPC  set the mark and temporarily turn on Transient Mark mode
>     C-@  only sets the mark

C-SPC and C-@ cannot be distinguised on tty frames, and C-@ is awkward
to type on many keyboards (even the US layout requires shift).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Enabling Transient Mark Mode by default

[Leo]

On 2008-02-22 10:47 +0000, Bastien wrote:
>   C-SPC  set the mark and temporarily turn on Transient Mark mode
>     C-@  only sets the mark

This won't work.

There is no C-SPC when emacs is running under terminal such as xterm?

Bye,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    What about this:

      C-SPC  set the mark and temporarily turn on Transient Mark mode
	C-@  only sets the mark

It is not a good idea to make them different.
And on a tty it is impossible.
C-SPC on a tty sends C-@.

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    If anybody has an idea how to reduce the disadvantage of tmm, I'm
    all ears.

Please let's not call Transient Mark mode "tmm".  That is inviting
confusion because tmm.el is something totally unrelated.

Re: Enabling Transient Mark Mode by default

[Sascha Wilde]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> So, that's for my personal preference.  As to why turn it on *by
> default*, here are some reasons why I think it should be ON by default:
[...]

One important reason against it is, that it makes uses of the mark ring
other than marking text very unpleasant.  The manual starts section 12.6
with the example of using the mark to mark interesting spots in an
buffer so that one can easily jump between them (in many cases this is
faster than saving positions in registers and therefor very
convenient).  In such cases the highlighting of text between point and
the last mark is distracting and useless.

On the other hand (as you pointed out your self) in case you really want
the marking (and the transient-marks semantics) typing C-SPC C-SPC is
still possible and easy.

cheers
sascha
-- 
Sascha Wilde : "Lies, was ich meine, nicht, was ich schreibe."
             : (Urs Traenkner in de.alt.admin)

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Sascha Wilde wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> So, that's for my personal preference.  As to why turn it on *by
>> default*, here are some reasons why I think it should be ON by default:
> [...]
> 
> One important reason against it is, that it makes uses of the mark ring
> other than marking text very unpleasant.  The manual starts section 12.6
> with the example of using the mark to mark interesting spots in an
> buffer so that one can easily jump between them (in many cases this is
> faster than saving positions in registers and therefor very
> convenient).  In such cases the highlighting of text between point and
> the last mark is distracting and useless.


Thanks for this explanation. In line with Davids thoughts I wonder if 
this behaviour can be improved. (Not yours, Emacs ...)

Do you have any suggestions?

Re: Enabling Transient Mark Mode by default

[Evans Winner]

I am not an Emacs developer, but am an avid user, and
thought my input might be useful.  It strikes me that
enabling hand-holding features by default in Emacs may not
actually be a favor to new users.

Very early on in my learning to use Emacs (several years
ago) I found out how to enable transient-mark-mode.  I
enabled it blindly on somebody's advice, in essence, because
I didn't know about or understand the actual use for which
the mark is designed.  I didn't question the feature because
it mimics one that I was used to from other applications.
It was only as a result of reading this thread that I looked
into the use of the mark and have begun to understand what I
have been missing.  So, my experience is similar (though not
identical) to that of someone new to an Emacs in which
transient-mark-mode is enabled by default.

On the other hand, at that time, I was one of those who had
the idea that GUIs are for wimps, so I also disabled
menu-bar-mode and tool-bar-mode.  The result was as
intended: I was forced to learn the Emacs way of doing many
things and now, though there was a bit more initial
investment in learning, I am very happy I did it.  I believe
the time invested has paid off, even though I no longer have
any objection to GUIs (if designed well), and even though I
leave those features turned on now.

One principle of teaching is that learners tend to strongly
favor the first mental model of something or method to which
they are exposed.  From Wikipedia: `` `Unteaching' wrong
first impressions is harder than teaching them right the
first time.''[1]  In general, tools or systems designed to
do something really well require a greater initial outlay of
time or money to use, but pay off over the long term.

I won't bother advocating that menus and tool bars and
scroll bars be deactivated by default, but I would at least
suggest that the right principle is that if a feature would
make it actively more difficult to use Emacs in the way that
it is fundamentally designed to be used, then that feature
ought not to be active by default.

Footnotes:

[1] Wikipedia; Principles of learning; Primacy
http://en.wikipedia.org/wiki/Principles_of_learning#Primacy

Re: Enabling Transient Mark Mode by default

[Jason Earl]

Evans Winner <thorne@timbral.net> writes:

> I am not an Emacs developer, but am an avid user, and
> thought my input might be useful.  It strikes me that
> enabling hand-holding features by default in Emacs may not
> actually be a favor to new users.

I think that this depends on whether or not the person would
use Emacs or abandon it for some other text editor without the
hand holding.  Once upon a time Emacs was so much better than
the competition that it could afford to be impenetrable.
People who were serious about editing text were going to end
up using Emacs whether they liked it or not.  That's not the
case anymore.

> Very early on in my learning to use Emacs (several years
> ago) I found out how to enable transient-mark-mode.  I
> enabled it blindly on somebody's advice, in essence, because
> I didn't know about or understand the actual use for which
> the mark is designed.  I didn't question the feature because
> it mimics one that I was used to from other applications.
> It was only as a result of reading this thread that I looked
> into the use of the mark and have begun to understand what I
> have been missing.  So, my experience is similar (though not
> identical) to that of someone new to an Emacs in which
> transient-mark-mode is enabled by default.

I had precisely the same thing happen to me.  In fact, I was
halfway through a long rant about the importance of making
Emacs more friendly to beginners when I decided to inform
myself a little better.  So I took a little bit of time to
actually read the part of the Emacs manual that deals with the
point and mark.

Like you, after a bit of experiment I have decided to turn off
transient mark mode for a bit so that I can learn to use the
point and mark more effectively.  I am starting to believe
that my use of transient-mark-mode has caused me to miss out
on one of Emacs' more useful features.  However, there is no
question that a visible representation of the region is very
helpful to someone that is learning to mark regions for the
first time.  I know that it certainly helped me.  Before I
started using Emacs I had never highlighted a block of text
with the keyboard.  In fact, I didn't even know that this was
possible on a more Windowsy editor until very recently :).

Personally, I think that Emacs developers should spend more
time and effort making Emacs approachable to new users, and
more user-friendly defaults is a great place to start.  After
all, I would bet that none of the people on this list spend
any time in a plain vanilla Emacs without a .emacs file.  The
vast majority of people that currently use Emacs understand
how to customize it.  Choosing defaults to satisfy current
users is a waste of time and energy.  The inveterate Emacs
user is going to customize Emacs to his or her specifications.
Only newbies are stuck with the defaults.  As such, the
defaults should be designed to hold the hand of the new user
that doesn't know how to customize Emacs.

> On the other hand, at that time, I was one of those who had
> the idea that GUIs are for wimps, so I also disabled
> menu-bar-mode and tool-bar-mode.  The result was as
> intended: I was forced to learn the Emacs way of doing many
> things and now, though there was a bit more initial
> investment in learning, I am very happy I did it.  I believe
> the time invested has paid off, even though I no longer have
> any objection to GUIs (if designed well), and even though I
> leave those features turned on now.

I certainly believe that we should encourage new users to
learn to use Emacs' key commands effectively.  However, the
real problem that Emacs faces currently is that there are an
increasing number of powerful editors that offer many of
Emacs' advanced features without Emacs' ridiculously steep
learning curve.

I am a true believer in Emacs' way of doing things.  If you
really want to learn to edit text effectively the smartest
thing you can do is find an accomplished Emacs user and learn
his or her tricks.  Heck, that's the real reason why I am
subscribed to this list.  I want to learn to use Emacs more
effectively.  The problem is that other editors have, over the
years, closed the gap considerably on Emacs.  If Emacs is
going to stay relevant and attract another generation of
hackers it can't afford to be actively hostile to newcomers.

> One principle of teaching is that learners tend to strongly
> favor the first mental model of something or method to which
> they are exposed.  From Wikipedia: `` `Unteaching' wrong
> first impressions is harder than teaching them right the
> first time.''[1]  In general, tools or systems designed to
> do something really well require a greater initial outlay of
> time or money to use, but pay off over the long term.

The problem is that the first impression that Emacs gives is
that it is an outmoded text editor with non-standard
keystrokes.  The non-standard keystrokes bit is probably
unavoidable, but the "outmoded" bit could be avoided easily.
Emacs has tons of neat features that simply aren't presented
effectively to the casual user.

transient-mark-mode is a perfect example.  Setting an
operating on regions is a huge part of using Emacs effectively
and yet Emacs has historically forced new Emacs users to learn
how the region works the hard way.  As of today I can see why
people might want transient-mark-mode off in their own setup.
But the only reason to default to having it off in a vanilla
Emacs is that if you *want* to be hostile to newbies.

Take this quote from the Emacs manual:

      When Emacs was developed, terminals had only one cursor,
   so Emacs does not show where the mark is located-you have
   to remember.

To a newbie learning Emacs for the first time this sounds
suspiciously like, "When I was a boy we didn't have fancy
computers like we do today.  We had to toggle the bits in our
files by waving magnets over the platters of the hard drives.
What's more, we liked it that way."  You might as well tell
aspiring young hackers to get off your lawn while you are at
it.

The alternative, as the manual points out, is to enable
transient-mark-mode and have Emacs work like most newbies
would expect a text editor to work.  Yes, this is possibly not
optimal for the advanced user, but the advanced user will be
able to turn the feature (or mis-feature if you will) off.

> I won't bother advocating that menus and tool bars and
> scroll bars be deactivated by default, but I would at least
> suggest that the right principle is that if a feature would
> make it actively more difficult to use Emacs in the way that
> it is fundamentally designed to be used, then that feature
> ought not to be active by default.

I completely agree that this is probably the right way to go
about learning to use Emacs effectively.  Unfortunately, I
think that this is also basically a recipe for disaster for
the Emacs project.  Faced with the prospect of learning a text
editor that is actively hostile to users that don't grok it's
Meta-Alt-Ctrl goodness such a tactic is likely to drive new
users towards the many other text editors and IDEs that are
more friendly to the uninitiated.

I wouldn't mind so much, but I personally would really like to
see the Emacs user community (and through it the Emacs
developer community) grow, not wither and die.

Jason

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Jason Earl <jearl@xmission.com> writes:

> The alternative, as the manual points out, is to enable
> transient-mark-mode and have Emacs work like most newbies
> would expect a text editor to work.

You are presuming that enabling transient-mark-mode makes Emacs work
like most newbies (or people) would expect a text editor to work.

I disagree strongly with that presumption.  Other editors have marked
regions that are _independent_ of point.  Emacs doesn't.
Transient-mark-mode merely introduces some artifacts of typical text
editor regions, but because point is by necessity one region end, the
side effects are quite obnoxious and the result in no way leads to a
behavior typical for the work flow of other editors.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

On 20/02/2008, David Kastrup <dak@gnu.org> wrote:
> Jason Earl <jearl@xmission.com> writes:
>
>  > The alternative, as the manual points out, is to enable
>  > transient-mark-mode and have Emacs work like most newbies
>  > would expect a text editor to work.
>
>
> You are presuming that enabling transient-mark-mode makes Emacs work
>  like most newbies (or people) would expect a text editor to work.
>
>  I disagree strongly with that presumption.  Other editors have marked
>  regions that are _independent_ of point.

No doubt some might, by what editors?  kedit/gedit certainly seem to
handle it in a non-point-independent fashion, much like emacs,  main
difference is that the point may be visually hidden while their region
is active and vice-versa - emacs doesn't hide the point when the
region is active (nor does kedit actually, but it uses a thin
intercharacter vertical line cursor.  I myself have occasionally made
"off by one" errors because I've mistaken a still-visible block cursor
as part of the transient-mark-highlighted region in emacs, but these
days they're different colours on my display so I don't do that.)

It always seems to be at one end of the region though, as confirmed by
hitting an unshifted cursor movement key, which insta-deactivates the
region in kedit/gedit, with the cursor ending up on one side of the
ex-region. And hey, keyboard region selection is  by moving the point
with shifted cursor keys in kedit/gedit, so  I don't think
"independent of point" is a sane description.

Emacs with cua-selection-mode and transient mark mode really is pretty
close to other editors' behaviour.  Also need to adjust mouse and
interprogram behaviour, but hey I've bombarded the list with (slightly
less than perfect) patches to do that already.

What IS very different is that most editors allow the point to move
offscreen when scrolling...

Re: Enabling Transient Mark Mode by default

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

 > What IS very different is that most editors allow the point to move
 > offscreen when scrolling...

You can emulate this behavior by using scroll-restore (attached).

[-- Attachment #2: scroll-restore.el --]
[-- Type: text/plain, Size: 19123 bytes --]

;;; scroll-restore.el --- restore original position after scrolling

;; Copyright (C) 2007 Martin Rudalics

;; Time-stamp: "2007-12-05 10:44:11 martin"
;; Author: Martin Rudalics <rudalics@gmx.at>
;; Keywords: scrolling

;; scroll-restore.el is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3, or (at your option)
;; any later version.

;; scroll-restore.el is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;;; Commentary:

;; Scroll Restore mode is a minor mode to restore the position of
;; `point' in a sequence of scrolling commands whenever that position
;; has gone off-screen and becomes visible again.  The user option
;; `scroll-restore-commands' specifies the set of commands that may
;; constitute such a sequence.

;; The following additional options are provided:

;; - Recenter the window when restoring the original position, see
;;   `scroll-restore-recenter'.

;; - Jump back to the original position before executing a command not
;;   in `scroll-restore-commands', see `scroll-restore-jump-back'.  The
;;   resulting behavior is similar to that provided by a number of word
;;   processors.

;; - Change the appearance of the cursor in the selected window to
;;   indicate that the original position is off-screen, see
;;   `scroll-restore-handle-cursor'.

;; - With `transient-mark-mode' non-nil Emacs highlights the region
;;   between `point' and `mark' when the mark is active.  If you scroll
;;   `point' off-screen, Emacs relocates `point' _and_ the region.
;;   Customizing `scroll-restore-handle-region' permits to highlight the
;;   original region as long as the original position of `point' is
;;   off-screen, and restore the original region whenever the original
;;   position of `point' becomes visible again.


;; Caveats:

;; - Scroll Restore mode does not handle `switch-frame' and
;;   `vertical-scroll-bar' events executed within the loops in
;;   `mouse-show-mark' and `scroll-bar-drag' (these don't call
;;   `post-command-hook' as needed by Scroll Restore mode).

;; - Scroll Restore mode may disregard your customizations of
;;   `scroll-margin'.  Handling `scroll-margin' on the Elisp level is
;;   tedious and might not work correctly.

;; - Scroll Restore mode should handle `make-cursor-line-fully-visible'
;;   but there might be problems.

;; - Scroll Restore mode can handle region and cursor only in the
;;   selected window.  This makes a difference when you have set
;;   `highlight-nonselected-windows' to a non-nil value.

;; - Scroll Restore mode has not been tested with emulation modes like
;;   `cua-mode' or `pc-selection-mode'.  In particular, the former's
;;   handling of `cursor-type' and `cursor-color' might be affected by
;;   Scroll Restore mode."

;; - Scroll Restore mode might interact badly with `follow-mode'.  For
;;   example, the latter may deliberately select a window A when the
;;   original position of a window B appears in it.  This won't restore
;;   the appearance of the cursor when Scroll Restore mode handles it.


;;; Code:

(defgroup scroll-restore nil
  "Restore original position after scrolling."
  :version "23.1"
  :group 'windows)

(defcustom scroll-restore-commands
  '(handle-select-window handle-switch-frame
    scroll-up scroll-down
    scroll-bar-toolkit-scroll mwheel-scroll
    scroll-other-window scroll-other-window-down
    scroll-bar-scroll-up scroll-bar-scroll-down scroll-bar-drag)
  "Commands handled by Scroll Restore mode.
Scroll Restore mode will try to restore the original position of
`point' after executing a sequence of any of these commands."
  :type '(repeat symbol)
  :set #'(lambda (symbol value)
	   (when (boundp 'scroll-restore-commands)
	     (dolist (cmd scroll-restore-commands)
	       (put cmd 'scroll-restore nil)))
	   (set-default symbol value)
	   (dolist (cmd scroll-restore-commands)
	     (put cmd 'scroll-restore t)))
  :group 'scroll-restore)

;; Recenter.
(defcustom scroll-restore-recenter nil
  "Non-nil means scrolling back recenters the original position.
Setting this to a non-nil value can be useful to detect the original
position more easily and coherently when scrolling back."
  :type 'boolean
  :group 'scroll-restore)

;; Jump back.
(defcustom scroll-restore-jump-back nil
  "Non-nil means jump back to original position after scrolling.
When this option is non-nil, Scroll Restore mode resets `point'
to the original position when scrolling has moved that position
off-screen and a command not in `scroll-restore-commands' shall
be executed.  The resulting behavior is similar to that of some
word processors.  You probably want to remove commands like
`scroll-up' and `scroll-down' from `scroll-restore-commands' when
activating this option.

Alternatively you may consider binding the command
`scroll-restore-jump-back' to a key of your choice."
  :type 'boolean
  :set #'(lambda (symbol value)
	   (set-default symbol value)
	   (when (and (boundp 'scroll-restore-mode) scroll-restore-mode)
	     (scroll-restore-restart)))
  :group 'scroll-restore)

;;; Cursor handling.
(defvar scroll-restore-buffer nil
  "Buffer for `scroll-restore-cursor-type'.")

;; Note: nil is a valid cursor-type.
(defvar scroll-restore-buffer-cursor-type 'invalid
  "Original cursor-type of `scroll-restore-buffer'.")

(defvar scroll-restore-frame nil
  "Frame for `scroll-restore-cursor-color'.")

(defvar scroll-restore-frame-cursor-color nil
  "Original cursor-color of `scroll-restore-frame'.")

(defcustom scroll-restore-handle-cursor nil
  "Non-nil means Scroll Restore mode may change appearance of cursor.
Scroll Restore mode can change the appearance of the cursor in
the selected window while the original position is off-screen.
Customize `scroll-restore-cursor-type' to change the type of the
cursor and `scroll-restore-cursor-color' to change its color."
  :type '(choice
	  (const :tag "Off" nil)
	  (const :tag "Cursor type" type)
	  (const :tag "Cursor color" color)
	  (const :tag "Type and color" t))
  :set #'(lambda (symbol value)
	   (set-default symbol value)
	   (when (and (boundp 'scroll-restore-mode) scroll-restore-mode)
	     (scroll-restore-restart)))
  :group 'scroll-restore)

(defcustom scroll-restore-cursor-type 'box
  "Type of cursor when original position is off-screen.
Applied if and only if `scroll-restore-handle-cursor' is either
'type or t.

Be careful when another application uses that type.  Otherwise,
you might get unexpected results when Scroll Restore mode resets
the cursor type to its \"original\" value after a sequence of
scrolling commands and the application has changed the cursor
type in between.

To guard against unexpected results, Scroll Restore mode does not
reset the type of the cursor whenever its value does not equal
the value of scroll-restore-cursor-type."
  :type '(choice
	  (const :tag "No cursor" nil)
	  (const :tag "Filled box" box)
	  (const :tag "Hollow box" hollow)
	  (const :tag "Vertical bar" bar)
	  (const :tag "Horizontal bar" hbar))
  :set #'(lambda (symbol value)
	   (set-default symbol value)
	   (when (and (boundp 'scroll-restore-mode) scroll-restore-mode)
	     (scroll-restore-restart)))
  :group 'scroll-restore)

(defcustom scroll-restore-cursor-color "DarkCyan"
  "Background color of cursor when original position is off-screen.
Applied if and only if `scroll-restore-handle-cursor' is either
'color or t.

Observe that when Emacs changes the color of the cursor, the
change applies to all windows on the associated frame.

Be careful when another application is allowed to change the
cursor-color.  Otherwise, you might get unexpected results when
Scroll Restore mode resets the cursor color to its \"original\"
value and the application has changed the cursor color in
between.

To guard against unexpected results Scroll Restore mode does not
reset the color of the cursor whenever its value does not equal
the value of scroll-restore-cursor-color."
  :type 'color
  :set #'(lambda (symbol value)
	   (set-default symbol value)
	   (when (and (boundp 'scroll-restore-mode) scroll-restore-mode)
	     (scroll-restore-restart)))
  :group 'scroll-restore)

;;; Region handling.
(defvar scroll-restore-region-overlay
  (let ((overlay (make-overlay (point-min) (point-min))))
    (overlay-put overlay 'face 'scroll-restore-region)
    (delete-overlay overlay)
    overlay)
  "Overlay used for highlighting the region.")

(defcustom scroll-restore-handle-region nil
  "Non-nil means Scroll Restore mode handles the region.
This affects the behavior of Emacs in `transient-mark-mode' only.
In particular, Emacs will suppress highlighting the region as
long as the original position of `point' is off-screen.  Rather,
Emacs will highlight the original region \(the region before
scrolling started\) in `scroll-restore-region' face.  Scrolling
back to the original position will restore the region to its
original state.

Note that Scroll Restore mode does not deactivate the mark during
scrolling.  Hence any operation on the region will not use the
original but the _actual_ value of `point'.

If you mark the region via `mouse-drag-region', setting this
option has no effect since Scroll Restore mode cannot track mouse
drags."
  :type 'boolean
  :set #'(lambda (symbol value)
	   (set-default symbol value)
	   (when (and (boundp 'scroll-restore-mode) scroll-restore-mode)
	     (scroll-restore-restart)))
  :group 'scroll-restore)

(defface scroll-restore-region
  '((t :inherit region))
  "Face for Scroll Restore region when `scroll-restore-handle-region' is non-nil."
  :group 'scroll-restore)

;; Note: We can't use `point-before-scroll' for our purposes because
;; that variable is buffer-local.  We need a variable that recorded
;; `window-point' before a sequence of scroll operations.  Also
;; `point-before-scroll' is not handled by mwheel.el and some other
;; commands that do implicit scrolling.  hence, the original position is
;; handled, among others, by the following alist.
(defvar scroll-restore-alist nil
  "List of <window, buffer, point> quadruples.
`window' is the window affected, `buffer' its buffer.  `pos' is
the original position of `point' in that window.  `off' non-nil
means `pos' was off-screen \(didn't appear in `window'\).")

(defun scroll-restore-pre-command ()
  "Scroll Restore's pre-command function."
  (let (overlay-buffer)
    ;; Handle region overlay.
    (when (setq overlay-buffer (overlay-buffer scroll-restore-region-overlay))
      ;; Remove `transient-mark-mode' binding in any case.
      (with-current-buffer overlay-buffer
	(kill-local-variable 'transient-mark-mode))
      (delete-overlay scroll-restore-region-overlay)))
  ;; Handle cursor-type.
  (when (and scroll-restore-buffer
	     (not (eq scroll-restore-buffer-cursor-type 'invalid))
	     (with-current-buffer scroll-restore-buffer
	       (eq cursor-type scroll-restore-cursor-type)))
    (with-current-buffer scroll-restore-buffer
      (setq cursor-type scroll-restore-buffer-cursor-type)
      (setq scroll-restore-buffer-cursor-type 'invalid)))
  ;; Handle cursor-color.
  (when (and scroll-restore-frame scroll-restore-frame-cursor-color
	     (eq (frame-parameter scroll-restore-frame 'cursor-color)
		 scroll-restore-cursor-color))
    (let ((frame (selected-frame)))
      (select-frame scroll-restore-frame)
      (set-cursor-color scroll-restore-frame-cursor-color)
      (setq scroll-restore-frame-cursor-color nil)
      (select-frame frame)))
  ;; Handle jumping.
  (when (and scroll-restore-jump-back
	     (not (get this-command 'scroll-restore)))
    (let ((entry (assq (selected-window) scroll-restore-alist)))
      (when entry
	(let ((window (car entry))
	      (buffer (nth 1 entry))
	      (pos (nth 2 entry)))
	  (set-window-point window pos)
	  ;; We are on-screen now.
	  (setcdr (nthcdr 2 entry) (list nil))))))
  ;; Paranoia.
  (unless (or scroll-restore-jump-back scroll-restore-handle-region
	      scroll-restore-handle-cursor)
    ;; Should be never reached.
    (remove-hook 'pre-command-hook 'scroll-restore-pre-command)))

(defun scroll-restore-remove (&optional all)
  "Remove stale entries from `scroll-restore-alist'.
Optional argument ALL non-nil means remove them all."
  (dolist (entry scroll-restore-alist)
    (let ((window (car entry))
	  (buffer (nth 1 entry))
	  (pos (nth 2 entry)))
      (when (or all (not (window-live-p window))
		(not (eq (window-buffer window) buffer))
		(not (markerp pos)) (not (marker-position pos)))
	(when (markerp pos)
	  (set-marker pos nil))
	(setq scroll-restore-alist
	      (assq-delete-all window scroll-restore-alist))))))

(defun scroll-restore-add ()
  "Add new entries to `scroll-restore-alist'."
  (walk-windows
   (lambda (window)
     (unless (assq window scroll-restore-alist)
       (let ((buffer (window-buffer window)))
	     (setq scroll-restore-alist
		   (cons
		    (list
		     window buffer
		     (with-current-buffer buffer
		       (copy-marker (window-point window)))
		     nil)
		    scroll-restore-alist)))))
   'no-mini t))

(defun scroll-restore-update (how window buffer pos)
  "Update various things in `scroll-restore-post-command'.
HOW must be either on-off, on-on, off-off, off-on, or t.  WINDOW
and BUFFER are affected window and buffer.  POS is the original
position."
  (when (eq window (selected-window))
    (with-current-buffer buffer
      ;; Handle region.
      (when scroll-restore-handle-region
	(if (and transient-mark-mode mark-active
		 (not deactivate-mark)
		 (memq how '(on-off off-off)))
	    (progn
	      (move-overlay scroll-restore-region-overlay
			    (min pos (mark)) (max pos (mark)) buffer)
	      (overlay-put scroll-restore-region-overlay 'window window)
	      ;; Temporarily disable `transient-mark-mode' in this buffer.
	      (set (make-local-variable 'transient-mark-mode) nil))
	  (delete-overlay scroll-restore-region-overlay)))
      ;; Handle cursor.
      (when (and scroll-restore-handle-cursor
		 (memq how '(on-off off-off))
		 ;; Change cursor iff there was a visible cursor.
		 cursor-type)
	(when (memq scroll-restore-handle-cursor '(type t))
	  (setq scroll-restore-buffer buffer)
	  (setq scroll-restore-buffer-cursor-type cursor-type)
	  (setq cursor-type scroll-restore-cursor-type))
	(when (memq scroll-restore-handle-cursor '(color t))
	  (setq scroll-restore-frame (window-frame window))
	  (setq scroll-restore-frame-cursor-color
		(frame-parameter scroll-restore-frame 'cursor-color))
	  (let ((frame (selected-frame)))
	    (select-frame scroll-restore-frame)
	    (set-cursor-color scroll-restore-cursor-color)
	    (select-frame frame)))))))

(defun scroll-restore-post-command ()
  "Scroll Restore mode post-command function."
  (scroll-restore-remove)
  (let (recenter)
    (dolist (entry scroll-restore-alist)
      (let ((window (car entry))
	    (buffer (nth 1 entry))
	    (pos (nth 2 entry))
	    (off (nth 3 entry)))
	(if (get this-command 'scroll-restore)
	    ;; A scroll restore command.
	    (if off
		;; `pos' was off-screen.
		(if (pos-visible-in-window-p (marker-position pos) window)
		    ;; `pos' is on-screen now.
		    (progn
		      ;; Move cursor to original position.
		      (set-window-point window pos)
		      ;; Recenter if desired.
		      (when (and scroll-restore-recenter
				 (eq window (selected-window)))
			(setq recenter (/ (window-height window) 2)))
		      ;; Record on-screen status.
		      (setcdr (nthcdr 2 entry) (list nil))
		      (scroll-restore-update 'off-on window buffer pos))
		  ;; `pos' is still off-screen
		  (scroll-restore-update 'off-off window buffer pos))
	      ;; `pos' was on-screen.
	      (if (pos-visible-in-window-p pos window)
		  ;; `pos' is still on-screen.
		  (progn
		    ;; Occasionally Emacs deliberately changes
		    ;; `window-point' during scrolling even when
		    ;; it's visible.  Maybe this is due to
		    ;; `make-cursor-line-fully-visible' maybe due to
		    ;; `scroll-margin' maybe due to something else.
		    ;; We override that behavior here.
		    (unless (= (window-point) pos)
		      (set-window-point window pos))
		    (scroll-restore-update 'on-on window buffer pos))
		;; `pos' moved off-screen.
		;; Record off-screen state.
		(setcdr (nthcdr 2 entry) (list t))
		(scroll-restore-update 'on-off window buffer pos)))
	  ;; Not a scroll-restore command.
	  (let ((window-point (window-point window)))
		  (when (and (eq window (selected-window))
			     (or (/= window-point pos) off))
		    ;; Record position and on-screen status.
		    (setcdr
		     (nthcdr 1 entry)
		     (list (move-marker pos (window-point window)) nil)))
		  (scroll-restore-update t window buffer pos)))))
    (scroll-restore-add)
    (when recenter (recenter recenter))))

(defun scroll-restore-jump-back ()
  "Jump back to original position.
The orginal position is the value of `window-point' in the
selected window before you started scrolling.

This command does not push the mark."
  (interactive)
  (let ((entry (assq (selected-window) scroll-restore-alist)))
    (if entry
	(goto-char (nth 2 entry))
      (error "No jump-back position available"))))

(define-minor-mode scroll-restore-mode
  "Toggle Scroll Restore mode.
With arg, turn Scroll Restore mode on if arg is positive, off
otherwise.

In Scroll Restore mode Emacs attempts to restore the original
position that existed before executing a sequence of scrolling
commands whenever that position becomes visible again.  The
option `scroll-restore-commands' permits to specify the set of
commands that may constitute such a sequence.  In addition you
can

- recenter the window when you scroll back to the original
  position, see the option `scroll-restore-recenter',

- aggressively jump back to the original position before
  executing a command not in `scroll-restore-commands', see
  `scroll-restore-jump-back',

- change the appearance of the cursor in the selected window
  while the original position is off-screen, see the option
  `scroll-restore-handle-cursor',

- change the appearance of the region in the selected window
  while the original position is off-screen, see the option
  `scroll-restore-handle-region'."
  :global t
  :group 'scroll-restore
  :init-value nil
  :link '(emacs-commentary-link "scroll-restore.el")
  (if scroll-restore-mode
      (progn
	(scroll-restore-add)
	(when (or scroll-restore-jump-back scroll-restore-handle-region
		  scroll-restore-handle-cursor)
	  (add-hook 'pre-command-hook 'scroll-restore-pre-command))
	(add-hook 'post-command-hook 'scroll-restore-post-command t))
    (scroll-restore-remove 'all)
    (remove-hook 'pre-command-hook 'scroll-restore-pre-command)
    (remove-hook 'post-command-hook 'scroll-restore-post-command)))

(defun scroll-restore-restart ()
  "Restart Scroll Restore mode."
  (scroll-restore-mode -1)
  (scroll-restore-mode 1))

(provide 'scroll-restore)

;;; scroll-restore.el ends here

scroll-restore.el

[Richard Stallman]

I think this is trying to implement too many different features, and
we don't want them all.  I would rather implement just the feature of
restoring point after you scroll back to the previous screen, in a
simple way.

In general, it is best to avoid `pre-command-hook' whenever a finer
tool can be used, and likewise `post-command-hook'.

    ;; Note: We can't use `point-before-scroll' for our purposes because
    ;; that variable is buffer-local.

WHY isn't `point-before-scroll' enough?

Would it be enough just for the feature of restoring point?

				       We need a variable that recorded
    ;; `window-point' before a sequence of scroll operations.  Also
    ;; `point-before-scroll' is not handled by mwheel.el and some other
    ;; commands that do implicit scrolling.

I presume we can fix `point-before-scroll' to DTRT in those cases.  In
general, if a primitive feature isn't suitable for the job it is meant for,
let's make it suitable, rather than do the job in a heavy-handed way.

If we want a few commands to do a certain thing, then it is a bad idea
to use `post-command-hook' to check for them.  Instead we should
change those commands to do it, whatever IT is.  We can add a new
specific hook, and run it from commands and features that scroll.

People often choose `post-command-hook' rather than change C code.
But when we design changes to install in Emacs, we should not design
them based on the premise of "avoid changing the C code."

Re: scroll-restore.el

[David De La Harpe Golden]

On 21/02/2008, Richard Stallman <rms@gnu.org> wrote:
> I think this is trying to implement too many different features, and
>  we don't want them all.  I would rather implement just the feature of
>  restoring point after you scroll back to the previous screen, in a
>  simple way.
>

Well, that is perhaps useful on its own.  But just to note, some of
the additional features are probably needed to address the
transient-mark-mode region selection concern in the context where
Martin introduced scroll-restore - e.g. handle-region and jump-back.
(handle region just gives the appearance that an active region can go
offscreen, jump back is apparently then needed so that the region is
really reset to the pre-scrolled region just before the kill,
otherwise the real region at scrolled time is killed).

>   We can add a new
>  specific hook, and run it from commands and features that scroll.
>

I think that may wind up being necessary anyway - e.g. As pointed out
in the source comments, the code can't handle e.g. vertical scroll bar
or mouse drag scrolling sometimes because they don't cause a
post-command-hook?

(And if you are then concerned with the behaviour of the active region
under scrolling (though of course you mightn't be),  that can then
cause  serious flickering at best, "wrong" region at worst (e.g. if
you segue directly into a vertical scroll bar scroll from a mouse drag
mark region)).

Re: scroll-restore.el

[martin rudalics]

 > Well, that is perhaps useful on its own.  But just to note, some of
 > the additional features are probably needed to address the
 > transient-mark-mode region selection concern in the context where
 > Martin introduced scroll-restore - e.g. handle-region and jump-back.
 > (handle region just gives the appearance that an active region can go
 > offscreen,

Yes.  I found it useful when showing the same buffer in two windows.
Scrolling one window wouldn't relocate the region in the other.

 > jump back is apparently then needed so that the region is
 > really reset to the pre-scrolled region just before the kill,
 > otherwise the real region at scrolled time is killed).

No.  The region is restored automatically when the original position is
restored.  Jump back is much more aggressive in the sense that when you
have scrolled the original `point' offscreen and, for example, type a
self-insert character, that character is inserted at the original
position of `point' and not where `point' actually is.  I wouldn't use
the feature in practice but it's consistent with `delete-selection-mode'
and its derivatives.

 >>  We can add a new
 >> specific hook, and run it from commands and features that scroll.
 >
 > I think that may wind up being necessary anyway - e.g. As pointed out
 > in the source comments, the code can't handle e.g. vertical scroll bar
 > or mouse drag scrolling sometimes because they don't cause a
 > post-command-hook?

Precisely.

 > (And if you are then concerned with the behaviour of the active region
 > under scrolling (though of course you mightn't be),  that can then
 > cause  serious flickering at best, "wrong" region at worst (e.g. if
 > you segue directly into a vertical scroll bar scroll from a mouse drag
 > mark region)).

There are two options IMHO: Either turn off active region highlighting
when `point' is scrolled off-screen or highlight the region between the
original position and the mark.  The current approach of expanding and
contracting the region whenever `point' is adjusted is simply confusing.

Re: scroll-restore.el

[David De La Harpe Golden]

On 22/02/2008, martin rudalics <rudalics@gmx.at> wrote:
>  > Well, that is perhaps useful on its own.  But just to note, some of
>   > the additional features are probably needed to address the
>   > transient-mark-mode region selection concern in the context where
>   > Martin introduced scroll-restore - e.g. handle-region and jump-back.
>   > (handle region just gives the appearance that an active region can go
>   > offscreen,
>
>
> Yes.  I found it useful when showing the same buffer in two windows.
>  Scrolling one window wouldn't relocate the region in the other.
>
>
>   > jump back is apparently then needed so that the region is
>   > really reset to the pre-scrolled region just before the kill,
>   > otherwise the real region at scrolled time is killed).
>
>
> No.  The region is restored automatically when the original position is
>  restored.

... But that means you would have to restore the position (e.g. by
scrolling back "manually") before hitting kill? in other systems, it
is conventional for the C-x/C-c cut/copy to do the kill of the
partially or totally scrolled-offscreen active region (not of a
different region, which is what happens without jump-back, unless I'm
still misunderstanding) - i.e. for this purpose, jump back is involved
so as to jump back to restore the point position so as to
insta-restore the original region just before kill.

Re: scroll-restore.el

[martin rudalics]

 >>No.  The region is restored automatically when the original position is
 >> restored.
 >
 > ... But that means you would have to restore the position (e.g. by
 > scrolling back "manually") before hitting kill?

Yes.

 > in other systems, it
 > is conventional for the C-x/C-c cut/copy to do the kill of the
 > partially or totally scrolled-offscreen active region (not of a
 > different region, which is what happens without jump-back, unless I'm
 > still misunderstanding) - i.e. for this purpose, jump back is involved
 > so as to jump back to restore the point position so as to
 > insta-restore the original region just before kill.

You do understand correctly.  Having jump-back nil _is_ inconsistent.
But I never kill the region when I'm scrolling.  I always "explicitly"
move `point' before.

Re: scroll-restore.el

[martin rudalics]

 > I think this is trying to implement too many different features, and
 > we don't want them all.  I would rather implement just the feature of
 > restoring point after you scroll back to the previous screen, in a
 > simple way.

It's the only feature I use in practice.  But I never scroll a window
when the region is highlighted.  Scrolling with a highlighted region is
a real pain when `point' gets relocated to stay on screen.

 > In general, it is best to avoid `pre-command-hook' whenever a finer
 > tool can be used, and likewise `post-command-hook'.

Goes without saying.  Last summer someone on bug-gnu-emacs lamented the
absence of such a feature.  I just wanted to know whether I liked it and
use it ever since.

 >     ;; Note: We can't use `point-before-scroll' for our purposes because
 >     ;; that variable is buffer-local.
 >
 > WHY isn't `point-before-scroll' enough?

The variable must be window-local to handle the case of independently
scrolling two or more windows showing the same buffer (setting
`mouse-wheel-follow-mouse' to t makes that possible).

 > Would it be enough just for the feature of restoring point?
 >
 > 				       We need a variable that recorded
 >     ;; `window-point' before a sequence of scroll operations.  Also
 >     ;; `point-before-scroll' is not handled by mwheel.el and some other
 >     ;; commands that do implicit scrolling.
 >
 > I presume we can fix `point-before-scroll' to DTRT in those cases.  In
 > general, if a primitive feature isn't suitable for the job it is meant for,
 > let's make it suitable, rather than do the job in a heavy-handed way.

I'll have to look into how `point-before-scroll' is currently used by
the scroll-bar / mouse code and whether it can (or should) be safely
made window-local.

 > If we want a few commands to do a certain thing, then it is a bad idea
 > to use `post-command-hook' to check for them.  Instead we should
 > change those commands to do it, whatever IT is.  We can add a new
 > specific hook, and run it from commands and features that scroll.
 >
 > People often choose `post-command-hook' rather than change C code.
 > But when we design changes to install in Emacs, we should not design
 > them based on the premise of "avoid changing the C code."

Fully agreed.

Re: Enabling Transient Mark Mode by default

[Jason Earl]

David Kastrup <dak@gnu.org> writes:

> Jason Earl <jearl@xmission.com> writes:
>
>> The alternative, as the manual points out, is to enable
>> transient-mark-mode and have Emacs work like most newbies
>> would expect a text editor to work.
>
> You are presuming that enabling transient-mark-mode makes Emacs work
> like most newbies (or people) would expect a text editor to work.
> 
> I disagree strongly with that presumption.  Other editors have marked
> regions that are _independent_ of point.  Emacs doesn't.
> Transient-mark-mode merely introduces some artifacts of typical text
> editor regions, but because point is by necessity one region end, the
> side effects are quite obnoxious and the result in no way leads to a
> behavior typical for the work flow of other editors.

Yes, I agree that transient-mark-mode works somewhat differently than
most text editors.  However, without transient-mark-mode Emacs is
*remarkably* different than other editors.  More importantly,
transient-mark-mode helps give the newbie clues as to how setting the
region works in Emacs.  Think of it as training wheels for region
marking.

Without those visual clues it is easy for even the experienced Emacs
user to forget where the mark is.  Of course, the experienced Emacs user
has read the manual and knows about C-x C-x and friends.  The newbie, on
the other hand, doesn't have a clue about these keystrokes.  As far as
they are concerned Emacs is simply too old-fashioned to do something
sensible like highlight the region they are marking.  To make matters
worse the new user is in for a surprise when they try to actually use
the "invisible" region that they are trying to mark because, as you
point out, it is likely to work differently than they expect.  At least
with transient-mark-mode Emacs gives the user some visual clues that can
help the new user figure out what just happened to their text.

Marking regions in Emacs *should* be different than how it is done in
other editors because the way Emacs marks regions is better :).
However, it is not likely to *seem* better to the uninitiated if they
have a hard time telling what parts of the text comprise the region.

Just for fun I fired up gedit to see how that particular editor dealt
with regions.  As you pointed out it didn't work even remotely like
Emacs, but the fact that I could see the region that I marked did make
it easy for me to quickly deduce how it worked.  I think that Emacs
should extend the same courtesy for newcomers.  For those of you that
don't want training wheels turning the feature off is very
straightforward.

Jason

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Jason Earl <jearl@xmission.com> writes:

> Yes, I agree that transient-mark-mode works somewhat differently than
> most text editors.  However, without transient-mark-mode Emacs is
> *remarkably* different than other editors.  More importantly,
> transient-mark-mode helps give the newbie clues as to how setting the
> region works in Emacs.  Think of it as training wheels for region
> marking.
>
> Without those visual clues it is easy for even the experienced Emacs
> user to forget where the mark is.  Of course, the experienced Emacs
> user has read the manual and knows about C-x C-x and friends.

You don't need to read the manual.  The tutorial is sufficient as are
the help sheets.  And without learning at least some basics, Emacs is
not going to be fun.

> The newbie, on the other hand, doesn't have a clue about these
> keystrokes.  As far as they are concerned Emacs is simply too
> old-fashioned to do something sensible like highlight the region they
> are marking.  To make matters worse the new user is in for a surprise
> when they try to actually use the "invisible" region that they are
> trying to mark because, as you point out, it is likely to work
> differently than they expect.  At least with transient-mark-mode Emacs
> gives the user some visual clues that can help the new user figure out
> what just happened to their text.

Sorry, but you miss the fact that the highlighted region is _active_
whereas the non-highlighted region is _inactive_.  And _active_ region
changes the meaning of lots of commands, making them operate on the
region instead of their normal range.  An _inactive_ region defined with
mark and point does not have such an effect.  It merely sets mark
somewhere but assigns no special meaning to the region.  Only commands
explicitly working on the region between mark and point are ever
affected.

So transient-mark-mode does something quite different from merely
highlighting the region.  It changes its meaning.

> Marking regions in Emacs *should* be different than how it is done in
> other editors because the way Emacs marks regions is better :).
> However, it is not likely to *seem* better to the uninitiated if they
> have a hard time telling what parts of the text comprise the region.

But the highlighting of tmm does more than show mark and point.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Jason Earl]

David Kastrup <dak@gnu.org> writes:

> Jason Earl <jearl@xmission.com> writes:
>
>> Yes, I agree that transient-mark-mode works somewhat differently than
>> most text editors.  However, without transient-mark-mode Emacs is
>> *remarkably* different than other editors.  More importantly,
>> transient-mark-mode helps give the newbie clues as to how setting the
>> region works in Emacs.  Think of it as training wheels for region
>> marking.
>>
>> Without those visual clues it is easy for even the experienced Emacs
>> user to forget where the mark is.  Of course, the experienced Emacs
>> user has read the manual and knows about C-x C-x and friends.
>
> You don't need to read the manual.  The tutorial is sufficient as are
> the help sheets.  And without learning at least some basics, Emacs is
> not going to be fun.
>
>> The newbie, on the other hand, doesn't have a clue about these
>> keystrokes.  As far as they are concerned Emacs is simply too
>> old-fashioned to do something sensible like highlight the region they
>> are marking.  To make matters worse the new user is in for a surprise
>> when they try to actually use the "invisible" region that they are
>> trying to mark because, as you point out, it is likely to work
>> differently than they expect.  At least with transient-mark-mode Emacs
>> gives the user some visual clues that can help the new user figure out
>> what just happened to their text.
>
> Sorry, but you miss the fact that the highlighted region is _active_
> whereas the non-highlighted region is _inactive_.  And _active_ region
> changes the meaning of lots of commands, making them operate on the
> region instead of their normal range.  An _inactive_ region defined
> with mark and point does not have such an effect.  It merely sets mark
> somewhere but assigns no special meaning to the region.  Only commands
> explicitly working on the region between mark and point are ever
> affected.

Even an inactive region has meaning (C-w proves it).  What it doesn't
have is some sort of visible clue as to where it is.  That makes the
mark a useful bookmark for experts who have read the manual (the
TUTORIAL doesn't mention C-x C-x and friends) and useless and confusing
to anyone else.  The TUTORIAL mentions the mark one time, but it
certainly doesn't talk about potential uses for it other than cutting
regions of text.

For the new user the mark doesn't exist.  Unless, of course, they turn
on transient-mark-mode, then, when the region is active the user can see
where the mark and point happen to be.

> So transient-mark-mode does something quite different from merely
> highlighting the region.  It changes its meaning.

Yes, it changes the meaning in a way that even people that don't like
transient-mark-mode seem to like.  That's why commands behave
differently with active regions.  Or are you suggesting this feature
should go away?

A new user that highlights a region using transient-mark-mode and then
does M-x query-replace to replace some text isn't going to be surprised
that only text in the highlighted region is affected.  Or if they are
surprised they are likely to be excited by the fact that they can search
and replace in a subset of a file easily.  After all, you can always
make the region inactive and run the command again.

I know that when I stumbled across that functionality that I thought it
was pretty cool.

The whole point of marking a region is that you are going to do
something to that region.

The real tragedy is that, without transient-mark-mode, new users won't
even know that they can run commands on a region of the text because
they won't learn about making a region active unless they stumble
accross the part of the manual that talks about The Mark and the Region.
Even if you do stumble upon that section it doesn't tell you that making
the region active changes the way many commands work.

Like I mentioned before, I personally found out about this particular
feature by accident.  I assume that most of the people here found out
about the feature by reading Emacs Lisp source code.  That's fine if you
are an Emacs Lisp developer.  It's not so fine for the rest of us.

If Emacs were some sort of text adventure (and I suppose that it is)
then this sort of discovery would be worth quite a few points.
Personally, I am glad that someone has decided that the default going
forward is to give newcomers a clue by turning on transient-mark-mode
and showing people (by default) the cool things that can be done with
active regions.

Yes, transient-mark-mode screws up the bookmarking features of inactive
regions and marks (well, actually it just highlights the region, but why
get technical).

>> Marking regions in Emacs *should* be different than how it is done in
>> other editors because the way Emacs marks regions is better :).
>> However, it is not likely to *seem* better to the uninitiated if they
>> have a hard time telling what parts of the text comprise the region.
>
> But the highlighting of tmm does more than show mark and point.

Yes, it makes marking the region actually useful for a whole pile of
commands at the expense of making the mark less useful as a bookmark.

It's likely that I am missing some other magical use of the invisible
mark, I just started using it today.

Jason

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Jason Earl <jearl@xmission.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Sorry, but you miss the fact that the highlighted region is _active_
>> whereas the non-highlighted region is _inactive_.  And _active_ region
>> changes the meaning of lots of commands, making them operate on the
>> region instead of their normal range.  An _inactive_ region defined
>> with mark and point does not have such an effect.  It merely sets mark
>> somewhere but assigns no special meaning to the region.  Only commands
>> explicitly working on the region between mark and point are ever
>> affected.
>
> Even an inactive region has meaning (C-w proves it).

What about "Only commands explicitly working on the region between mark
and point are ever affected" did you not understand?

>> So transient-mark-mode does something quite different from merely
>> highlighting the region.  It changes its meaning.
>
> Yes, it changes the meaning in a way that even people that don't like
> transient-mark-mode seem to like.

Let's not forget that "temporary transient mark mode" is new with Emacs
22, and that many people preferred not having an active region at all
(the default Emacs setting) than getting it forcefed by
transient-mark-mode (which pretty much knows nothing except active
regions).

> That's why commands behave differently with active regions.  Or are
> you suggesting this feature should go away?

I am suggesting that having a usable mark should not imply an active
region.  But that is more or less the premise of transient-mark-mode.

> A new user that highlights a region using transient-mark-mode and then
> does M-x query-replace to replace some text isn't going to be
> surprised that only text in the highlighted region is affected.

That implies that "highlights a region" is an explicit and voluntary
act.  Which it is when using the mouse or other means of temporary
transient-mark mode (and temporary transient-mark mode is really a life
saver: giving the possibilities of transient-mark mode without pressing
it on you when you don't explicitly want it but are merely working with
the mark).

> Or if they are surprised they are likely to be excited by the fact
> that they can search and replace in a subset of a file easily.  After
> all, you can always make the region inactive and run the command
> again.

But temporary tmm-mode buys you all that.

> The real tragedy is that, without transient-mark-mode, new users won't
> even know that they can run commands on a region of the text because
> they won't learn about making a region active unless they stumble
> accross the part of the manual that talks about The Mark and the
> Region.

Huh?  New users will mark regions with the mouse, and that triggers
temporary transient mark mode just fine.  Are you sure you even _know_
the situation with Emacs 22?  Or is your experience without a permanent
tmm-mode dating from pre-Emacs 22?

-- 
David Kastrup

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

> I am suggesting that having a usable mark should not imply an active
> region.  But that is more or less the premise of transient-mark-mode.

I don't understand in what way TMM requires or enforces that "a usable
mark implies an active region".

> (and temporary transient-mark mode is really a life saver:

Thank you ;-)


        Stefan

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I am suggesting that having a usable mark should not imply an active
>> region.  But that is more or less the premise of transient-mark-mode.
>
> I don't understand in what way TMM requires or enforces that "a usable
> mark implies an active region".

It may be mitigated with mark-even-if-inactive, but that is rather
recent development.  Before that, you could use the mark (like with C-w
or so) only when the region was also active: the region was active
exactly when the mark was active, and the mark was not usable at all
(except for very few commands like C-x C-x) unless it was active.

>> (and temporary transient-mark mode is really a life saver:
>
> Thank you ;-)

The thanks are on my side.  It was somewhat of a nuisance not to be able
to use active-region commands, but the price of regular tmm-mode was
simply too high.

-- 
David Kastrup

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

>>> I am suggesting that having a usable mark should not imply an active
>>> region.  But that is more or less the premise of transient-mark-mode.
>> I don't understand in what way TMM requires or enforces that "a usable
>> mark implies an active region".
> It may be mitigated with mark-even-if-inactive, but that is rather
> recent development.

Well, everyone is entitled to his/her own interpretation of "recent", but

    1993-06-30  Richard Stallman  (rms@mole.gnu.ai.mit.edu)

        * simple.el (mark-even-if-inactive): New variable.

that's around the same time transient-mark-mode sows up in the ChangeLog
files, so I presume it was introduced at the same time (I know
I discovered/enabled it "soon" after enabling TMM, but that "soon" may
span a year or two).

>>> (and temporary transient-mark mode is really a life saver:
>> Thank you ;-)

> The thanks are on my side.  It was somewhat of a nuisance not to be able
> to use active-region commands, but the price of regular tmm-mode was
> simply too high.

What do you think of making C-M-SPC (and a few other such mark-*
commands) turn on temp-TMM?


        Stefan

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>>> I am suggesting that having a usable mark should not imply an active
>>>> region.  But that is more or less the premise of transient-mark-mode.
>>> I don't understand in what way TMM requires or enforces that "a usable
>>> mark implies an active region".
>> It may be mitigated with mark-even-if-inactive, but that is rather
>> recent development.
>
> Well, everyone is entitled to his/her own interpretation of "recent", but
>
>     1993-06-30  Richard Stallman  (rms@mole.gnu.ai.mit.edu)
>
>         * simple.el (mark-even-if-inactive): New variable.
>
> that's around the same time transient-mark-mode sows up in the ChangeLog
> files, so I presume it was introduced at the same time (I know
> I discovered/enabled it "soon" after enabling TMM, but that "soon" may
> span a year or two).

I stand corrected.  How many people using transient-mark-mode regularly
also set mark-even-if-inactive?

>>>> (and temporary transient-mark mode is really a life saver:
>>> Thank you ;-)
>
>> The thanks are on my side.  It was somewhat of a nuisance not to be able
>> to use active-region commands, but the price of regular tmm-mode was
>> simply too high.
>
> What do you think of making C-M-SPC (and a few other such mark-*
> commands) turn on temp-TMM?

Sounds sensible to me for this one.  I think that things like
delete-selection-mode should _not_ switch on permanent
transient-mark-mode, by the way: they would appear also useful with
temporary transient-mark-mode, and it is a pity that one can't use them
with it.

-- 
David Kastrup

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

>> What do you think of making C-M-SPC (and a few other such mark-*
>> commands) turn on temp-TMM?

> Sounds sensible to me for this one.

Here's the list:

   M-x mark- TAB
   
   mark-defun       mark-end-of-sentence   mark-page
   mark-paragraph   mark-sexp              mark-whole-buffer
   mark-word

Would you obect to have them all set temp-TMM?

> I think that things like delete-selection-mode should _not_ switch on
> permanent transient-mark-mode, by the way: they would appear also
> useful with temporary transient-mark-mode, and it is a pity that one
> can't use them with it.

Agreed.  It made sense to do it back when temp-TMM didn't exist (since
del-sel-mode needs either temp-TMM or TMM to be of any use), but
not any more.  Same for cua-selection-mode and pc-selection-mode,
I guess (tho these would need to be tweaked so that they properly
activate the mark in temp-TMM).


        Stefan


PS: BTW, the current TMM implementation is odd and inconvenient.  I think
the activation/highlighting status of the mark needs to be determined
solely from mark-active, and the transient-mark-mode variable should
only affect how mark-active is changed.  I.e. we should change
`mark-active' to accept more than 2 values: it can be nil (unset),
t (set but not highlighted), `highlighted', and maybe also
`highlight-once' (this corresponds to the `once' setting of TMM used for
mouse operations so that the mark is only highlighted for 1 operation so
even just moving point will dehighlight it).  Or maybe just nil or
a number (the number is decremented after every command and if it is
positive it means that the mark is highlighted: 1=highlight-once, 0=t,
most-positive-fixnum=highlighted).  Then TMM and mark-even-if-inactive
are only consulted when activating/deactivating the mark to know to what
to (re)set mark-active.

Problem is: this would be backward-incompatible because of code that
does (and mark-active transient-mark-mode) and would hence be confused
when the mark is set but not highlighted.

Re: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

On 21/02/2008, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>  I.e. we should change
> `mark-active' to accept more than 2 values:

Not necessarily disagreeing, but just noting that pc-selection mode
already sets mark-active to "pc-select" to allow it to coexist with
tmm-style highlighting by C-SPC - pc-selection only deactivates "its
own" mark activations on cursor move.   Thus, people can use C-SPC
plus cursor keys even when pc-selection-mode is active, it is only if
they use shift-cursor keys to activate the mark will it be deactivated
on cursor move.

This is (or was) considered a feature I think!

Given apparent concern over mouse then keyboard interaction, maybe
pc-selection-mode needs to also deactivate the mark when cursor moves
after the _mouse_ has set the region...

Re: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

On 21/02/2008, David De La Harpe Golden
>  Given apparent concern over mouse then keyboard interaction, maybe
>  pc-selection-mode needs to also deactivate the mark when cursor moves
>  after the _mouse_ has set the region...
>

er... which cua-selection-mode already does...

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> What do you think of making C-M-SPC (and a few other such mark-*
>>> commands) turn on temp-TMM?
>
>> Sounds sensible to me for this one.
>
> Here's the list:
>
>    M-x mark- TAB
>    
>    mark-defun       mark-end-of-sentence   mark-page
>    mark-paragraph   mark-sexp              mark-whole-buffer
>    mark-word
>
> Would you obect to have them all set temp-TMM?

I have to admit to actually only using mark-whole-buffer of all those.
And C-x h M-w is a pretty frequent key combination for me.  I don't
think I would be all too happy about the whole screen flashing in yellow
for that, but I could probably live with that as a price for some
consistency.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> I have to admit to actually only using mark-whole-buffer of all those.
> And C-x h M-w is a pretty frequent key combination for me.  I don't
> think I would be all too happy about the whole screen flashing in yellow
> for that, but I could probably live with that as a price for some
> consistency.

Actually I like the fact that the entire screen gets highlighted --
it's a bit of extra visual confirmation that I didn't make a typo... :-/

-Miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

RE: Enabling Transient Mark Mode by default

[Drew Adams]

> What do you think of making C-M-SPC (and a few other such mark-*
> commands) turn on temp-TMM?

Yes.

And let's come up with an easier binding than C-u C-x C-x for activating the
mark without moving point or mark. I don't have a good idea for the binding,
but it should be very easy to use.

M-SPC might be one possibility, but that would mean juggling its current
binding.

And it should be easy to exchange point and mark and activate the mark at
the same time.

Here's a thought. What about letting C-x C-x turn on temp-TMM? Would that
bother people? That is a lot quicker than C-u C-x C-x, and it would also
activate for exchanging point and mark.

How about this? C-x C-x would do what C-u C-x C-x does now - just activate,
without swapping. And C-x C-x C-x C-x would do what C-x C-x does now. Yes,
you would need to double C-x C-x to swap point and mark. But it is very
quick to type C-x multiple times.

IOW, I would privilege activating the mark (temp-TMM) over exchanging point
and mark, in terms of ease of typing. Replace C-u C-x C-x by C-x C-x to
activate, and so replace C-u C-x C-x C-x C-x with C-x C-x C-x C-x to swap
and activate.

If some people would be bothered by the highlighting from swapping, then
maybe this could be an option. But I suspect those people might also be
bothered by C-M-SPC etc. also highlighting.

Re: Enabling Transient Mark Mode by default

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> M-SPC might be one possibility, but that would mean juggling its current
> binding.

M-SPC seems to be trapped by this window manager (metacity) so it may
not be a very good binding for a lot of people (since metacity gets many
of its keybinding cues from windows, I'd also check whether windows
traps that)...

-Miles

-- 
Erudition, n. Dust shaken out of a book into an empty skull.

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
>> M-SPC might be one possibility, but that would mean juggling its current
>> binding.
> 
> M-SPC seems to be trapped by this window manager (metacity) so it may
> not be a very good binding for a lot of people (since metacity gets many
> of its keybinding cues from windows, I'd also check whether windows
> traps that)...
> 
> -Miles

Windows does not trap M-SPC but Alt-SPC. But, yes, it will be a problem 
on w32 too as long as Alt is use for Emacs META.

Re: Enabling Transient Mark Mode by default

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> M-SPC seems to be trapped by this window manager (metacity) so it may
>> not be a very good binding for a lot of people (since metacity gets many
>> of its keybinding cues from windows, I'd also check whether windows
>> traps that)...
>
> Windows does not trap M-SPC but Alt-SPC. But, yes, it will be a problem
> on w32 too as long as Alt is use for Emacs META.

Er, well, the concept of "M-" is often kind of fuzzy at a WM level
(since keyboards generally don't say "Meta" anywhere), but yeah, many
WMs seem to trap key bindings that may be what Emacs thinks of as
"M-SPC".

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>> M-SPC seems to be trapped by this window manager (metacity) so it may
>>> not be a very good binding for a lot of people (since metacity gets many
>>> of its keybinding cues from windows, I'd also check whether windows
>>> traps that)...
>> Windows does not trap M-SPC but Alt-SPC. But, yes, it will be a problem
>> on w32 too as long as Alt is use for Emacs META.
> 
> Er, well, the concept of "M-" is often kind of fuzzy at a WM level
> (since keyboards generally don't say "Meta" anywhere), but yeah, many
> WMs seem to trap key bindings that may be what Emacs thinks of as
> "M-SPC".

And I was wrong/unclear: Alt-SPC is not trapped, but the use of Alt-SPC 
interfere with the use it has in all other w32 GUI programs I know: 
Alt-SPC activates the "system menu" (which is the menu that is opened if 
you click the upper right corner of a w32 window). This is used for 
maximize/restore/minimize/close so it is pretty important IMO.

Re: Enabling Transient Mark Mode by default

[Mathias Dahl]

>  And I was wrong/unclear: Alt-SPC is not trapped, but the use of Alt-SPC
>  interfere with the use it has in all other w32 GUI programs I know:
>  Alt-SPC activates the "system menu" (which is the menu that is opened if
>  you click the upper right corner of a w32 window). This is used for
>  maximize/restore/minimize/close so it is pretty important IMO.

I'm not sure if I understand how it works for you, but for me, under
w32 (Windows XP), Alt + SPC has not the "normal" w32 behavior, Emacs
gets that key. Under my current GNU/Linux system with Metacity, the
window menu is opened however (which I did not like at first but have
gotten used to now for minimize/maximize etc). My guess is that this
key would not work for many Gnome users.

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Mathias Dahl wrote:
> I'm not sure if I understand how it works for you, but for me, under
> w32 (Windows XP), Alt + SPC has not the "normal" w32 behavior, Emacs
> gets that key. Under my current GNU/Linux system with Metacity, the
> window menu is opened however (which I did not like at first but have
> gotten used to now for minimize/maximize etc).

I have patched Emacs to do what I want ;-) -- I want the window menu 
with Alt-Space etc.

RE: Enabling Transient Mark Mode by default

[Drew Adams]

> > M-SPC might be one possibility, but that would mean 
> > juggling its current binding.
> 
> M-SPC seems to be trapped by this window manager (metacity) so
> it may not be a very good binding for a lot of people (since 
> metacity gets many of its keybinding cues from windows, I'd
> also check whether windows traps that)...

No, no problem on Windows, for me at least.

But that's a good point. What would be a good binding for this?

Re: Enabling Transient Mark Mode by default

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>> M-SPC might be one possibility, but that would mean juggling its current
>> binding.
>
> M-SPC seems to be trapped by this window manager (metacity) so it may

Seems like this is a speciality of metacity, neither kwin nor fvwm does
that by default.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Enabling Transient Mark Mode by default

[Tassilo Horn]

Andreas Schwab <schwab@suse.de> writes:

>>> M-SPC might be one possibility, but that would mean juggling its
>>> current binding.
>>
>> M-SPC seems to be trapped by this window manager (metacity) so it may
>
> Seems like this is a speciality of metacity, neither kwin nor fvwm
> does that by default.

But many WMs (I think kwin, too) trap M-TAB and probably many other
bindings used by emacs.  Fortunately most if not all WMs let users set
their own shortcuts.  Here all window manager shortcuts use the Windows
(Hyper) key, so all C and M bindings are reserved for use in
applications.  So I would't care much about what WM uses a key by
default.

Bye,
Tassilo

Re: Enabling Transient Mark Mode by default

[David Kastrup]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>>>> M-SPC might be one possibility, but that would mean juggling its
>>>> current binding.
>>>
>>> M-SPC seems to be trapped by this window manager (metacity) so it may
>>
>> Seems like this is a speciality of metacity, neither kwin nor fvwm
>> does that by default.
>
> But many WMs (I think kwin, too) trap M-TAB and probably many other
> bindings used by emacs.  Fortunately most if not all WMs let users set
> their own shortcuts.  Here all window manager shortcuts use the Windows
> (Hyper) key, so all C and M bindings are reserved for use in
> applications.  So I would't care much about what WM uses a key by
> default.

Metacity is the default GNOME window manager, and GNOME is by far the
most used of the two official GNU desktop environments (the other being
GNUstep).  So ignoring Metacity defaults for choosing Emacs bindings is
not a smart move.

-- 
David Kastrup

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    Metacity is the default GNOME window manager, and GNOME is by far the
    most used of the two official GNU desktop environments (the other being
    GNUstep).  So ignoring Metacity defaults for choosing Emacs bindings is
    not a smart move.

M-SPC is an important Emacs command, and has been since long before
Metacity existed.  It was a mistake to set up the Metacity defaults to
conflict with Emacs commands, but they don't listen to the Emacs
developers much.

Metacity interferes with a number of Emacs key bindings; Emacs users
just have to customize it.

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

> Metacity interferes with a number of Emacs key bindings; Emacs users
> just have to customize it.

They should of course also report those problems to the
Metacity developers.


        Stefan

Re: Enabling Transient Mark Mode by default

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Metacity interferes with a number of Emacs key bindings; Emacs users
>> just have to customize it.
>
> They should of course also report those problems to the
> Metacity developers.

Especially since the metacity function in question is, I suspect, not
something that's actually used enough to require a binding at all (it
brings up a menu).

-Miles

-- 
Barometer, n. An ingenious instrument which indicates what kind of weather we
are having.

Re: Enabling Transient Mark Mode by default

[Lennart Borgman (gmail)]

Miles Bader wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Metacity interferes with a number of Emacs key bindings; Emacs users
>>> just have to customize it.
>> They should of course also report those problems to the
>> Metacity developers.
> 
> Especially since the metacity function in question is, I suspect, not
> something that's actually used enough to require a binding at all (it
> brings up a menu).

But that is a very important binding for many that do not want to use a 
mouse to get the menu.

Re: Enabling Transient Mark Mode by default

[Mathias Dahl]

>  Especially since the metacity function in question is, I suspect, not
>  something that's actually used enough to require a binding at all (it
>  brings up a menu).

I use it all day long to maximize, umaximize and close windows and
sometimes for move and resize as well. It is convenient to have those
commands under that menu. It kind of does what a small keymap does in
Emacs. M-SPC (or whatever key) brings up the menu, and another key
press (x for maximize and unmaximize, c for close etc) executes the
command. Only one "top binding" is used instead of one per window
command. I do not particularly care on what key this menu is bound but
for me it is convenient that it is the same one as under w32.

Re: Enabling Transient Mark Mode by default

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> M-SPC is an important Emacs command, and has been since long before
> Metacity existed.  It was a mistake to set up the Metacity defaults to
> conflict with Emacs commands, but they don't listen to the Emacs
> developers much.

I agree, though to be honest I never noticed this particular issue
because I always just hit "ESC SPC" instead (I really only use the meta-
modifier key for commands that I want to hit repeatedly, like M-b)... :-]

-Miles

-- 
"An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god.  He only has to be someone who believes that the evidence
on the God question is at a similar level to the evidence on the werewolf
question."  [John McCarthy]

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    I agree, though to be honest I never noticed this particular issue
    because I always just hit "ESC SPC" instead (I really only use the meta-
    modifier key for commands that I want to hit repeatedly, like M-b)... :-]

I do type M-SPC fairly often.

Re: Enabling Transient Mark Mode by default

[Stephen J. Turnbull]

Richard Stallman writes:

 > M-SPC is an important Emacs command,

Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
`sentence-end-double-space'?  It currently doesn't, but it sort of
feels like a filling command to me.  If this has been tried and
failed, or there are strong intuitions against, I'd like to know.

Re: Enabling Transient Mark Mode by default

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > M-SPC is an important Emacs command,
>
> Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
> `sentence-end-double-space'?  It currently doesn't, but it sort of
> feels like a filling command to me.  If this has been tried and
> failed, or there are strong intuitions against, I'd like to know.

Why should it?  It's a command for inserting a single space, not a
command for inserting whitespace-following-end-of-sentence...

Anyway, if you like double-spaces (as I do), it's very convenient as-is
for use after a sentence:  ESC SPC SPC

[I use this command a lot, and only occasionally does it happen to be at
the end of a sentence.]

-Miles

-- 
The key to happiness
 is having dreams.      [from a fortune cookie]

Should M-SPC respect `sentence-end-double-space'?

[Stephen J. Turnbull]

Sorry for the premature thread hijaculation.  Please respond to this
post, which has an appropriate subject, not the previous one.

Stephen J. Turnbull writes:
 > Richard Stallman writes:
 > 
 >  > M-SPC is an important Emacs command,
 > 
 > Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
 > `sentence-end-double-space'?  It currently doesn't, but it sort of
 > feels like a filling command to me.  If this has been tried and
 > failed, or there are strong intuitions against, I'd like to know.

Re: Should M-SPC respect `sentence-end-double-space'?

[Paul Pogonyshev]

Stephen J. Turnbull writes:
 > Richard Stallman writes:
 > 
 >  > M-SPC is an important Emacs command,
 > 
 > Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
 > `sentence-end-double-space'?  It currently doesn't, but it sort of
 > feels like a filling command to me.  If this has been tried and
 > failed, or there are strong intuitions against, I'd like to know.

FWIW, I use this command editing program code, not text, so for
me such respecting would be annoying.

Paul

Re: Should M-SPC respect `sentence-end-double-space'?

[Stephen J. Turnbull]

Paul Pogonyshev writes:

 > Stephen J. Turnbull writes:
 >  > Richard Stallman writes:
 >  > 
 >  >  > M-SPC is an important Emacs command,
 >  > 
 >  > Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
 >  > `sentence-end-double-space'?  It currently doesn't, but it sort of
 >  > feels like a filling command to me.  If this has been tried and
 >  > failed, or there are strong intuitions against, I'd like to know.
 > 
 > FWIW, I use this command editing program code, not text, so for
 > me such respecting would be annoying.

The only contexts I thought of where this might be a problem would be
Lisp cons literals and the C trinary operator, and maybe the C member
operator.  In all cases handling this smoothly would involve a change
to the end of sentence recognition to require non-whitespace before
the full stop.  I have never seen people use styles like

'(car. cdr)		;; not a dotted list in Emacs Lisp, anyway
x = bool? val1: val2;
aggregate. member = x;

so I don't think it would be a problem in practice.

Re: Should M-SPC respect `sentence-end-double-space'?

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > M-SPC is an important Emacs command,
>
> Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
> `sentence-end-double-space'?  It currently doesn't, but it sort of
> feels like a filling command to me.  If this has been tried and
> failed, or there are strong intuitions against, I'd like to know.

Why should it?  It's a command for inserting a single space, not a
command for inserting whitespace-following-end-of-sentence...

Anyway, if you like double-spaces (as I do), it's very convenient as-is
for use after a sentence:  ESC SPC SPC

[I use this command a lot, and only occasionally does it happen to be at
the end of a sentence.]

-Miles

-- 
The key to happiness
 is having dreams.      [from a fortune cookie]

Re: Should M-SPC respect `sentence-end-double-space'?

[Stephen J. Turnbull]

Miles Bader writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > >  > M-SPC is an important Emacs command,
 > >
 > > Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
 > > `sentence-end-double-space'?  It currently doesn't, but it sort of
 > > feels like a filling command to me.  If this has been tried and
 > > failed, or there are strong intuitions against, I'd like to know.
 > 
 > Why should it?  It's a command for inserting a single space, not a
 > command for inserting whitespace-following-end-of-sentence...

I didn't specify a command, I specified a keystroke.

 > Anyway, if you like double-spaces (as I do), it's very convenient as-is
 > for use after a sentence:  ESC SPC SPC

My use case is in kbd macros: C-x ( C-s SPC SPC M-SPC C-x ), for example.

 > [I use this command a lot, and only occasionally does it happen to be at
 > the end of a sentence.]

Exactly!  Only occasionally would my proposal affect behavior.

Re: Should M-SPC respect `sentence-end-double-space'?

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > Why should it?  It's a command for inserting a single space, not a
>  > command for inserting whitespace-following-end-of-sentence...
>
> I didn't specify a command, I specified a keystroke.

Er, well, ok, that's the current binding of M-SPC... are you saying that
you think it should be rebound to something else?

>  > [I use this command a lot, and only occasionally does it happen to be at
>  > the end of a sentence.]
>
> Exactly!  Only occasionally would my proposal affect behavior.

I'm rather confused by what you _do_ mean.

Do are you saying you think that:

  (1) M-SPC should be rebound to something like
      "canonicalize-space"

  (2) "canonicalize-space" should insert two spaces if following a
      period and sentence-end-double-space is non-nil, otherwise it
      should insert a single space.

?

If so, it certainly shouldn't be bound to M-SPC, as that would interfere
with current users' muscle memory.

But if you mean something else, please describe.

Thanks,

-Miles


-- 
Advice, n. The smallest current coin.

Re: Should M-SPC respect `sentence-end-double-space'?

[Stephen J. Turnbull]

Miles Bader writes:

 > If so, it certainly shouldn't be bound to M-SPC,

I guess that's that.  Sorry I woke you!

Re: Should M-SPC respect `sentence-end-double-space'?

[Stefan Monnier]

>> If so, it certainly shouldn't be bound to M-SPC,
> I guess that's that.  Sorry I woke you!


For what it's worth, I've hacked my M-j so that C-u M-j does a "join",
which in the middle of a line happens to do pretty much what M-SPC does,
except it tries to obey the sentence-end-double-space setting (also it
doesn't leave any space at all if we right after a paren-open or right
before a paren-close, ...).


        Stefan

Re: Should M-SPC respect `sentence-end-double-space'?

[Juri Linkov]

>>  > M-SPC is an important Emacs command,
>>
>> Oh, yeah, that reminds me of an occasional wish: should M-SPC respect
>> `sentence-end-double-space'?  It currently doesn't, but it sort of
>> feels like a filling command to me.  If this has been tried and
>> failed, or there are strong intuitions against, I'd like to know.
>
> Why should it?  It's a command for inserting a single space, not a
> command for inserting whitespace-following-end-of-sentence...

Maybe there should be an option in text modes to insert two spaces on
typing SPC or M-SPC at the end of a sentence when`sentence-end-double-space'
is non-nil.  This means remapping SPC and M-SPC to some new command.

> Anyway, if you like double-spaces (as I do), it's very convenient as-is
> for use after a sentence:  ESC SPC SPC

I also use `M-2 M-SPC' (three keystrokes).

> [I use this command a lot, and only occasionally does it happen to be at
> the end of a sentence.]

In one of the older versions of KDE, M-SPC was captured by Katapult,
and it was not possible to redefine it.  I believe this is fixed
in the latest version of KDE.

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

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    Sorry, but you miss the fact that the highlighted region is _active_
    whereas the non-highlighted region is _inactive_.  And _active_ region
    changes the meaning of lots of commands, making them operate on the
    region instead of their normal range.

It is not so many commands -- and they are not among the most common
commands for beginners.  (Does any of them appear in TUTORIAL?)

But this does point up the fact that this change requires changes in
many places in the Emacs manual.  We should probably take the change
out and not install it until after writing the necessary Emacs Manual
changes.

Re: Enabling Transient Mark Mode by default

[Glenn Morris]

Richard Stallman wrote:

> But this does point up the fact that this change requires changes in
> many places in the Emacs manual.  We should probably take the change
> out and not install it until after writing the necessary Emacs Manual
> changes.

Is it still the position that this change should be reverted?

(I have no interest in writing the manual changes that would be needed.)

Re: Enabling Transient Mark Mode by default

[Kim F. Storm]

Glenn Morris <rgm@gnu.org> writes:

> Richard Stallman wrote:
>
>> But this does point up the fact that this change requires changes in
>> many places in the Emacs manual.  We should probably take the change
>> out and not install it until after writing the necessary Emacs Manual
>> changes.
>
> Is it still the position that this change should be reverted?

IMO, yes.

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

Re: Enabling Transient Mark Mode by default

[Juri Linkov]

>> But this does point up the fact that this change requires changes in
>> many places in the Emacs manual.  We should probably take the change
>> out and not install it until after writing the necessary Emacs Manual
>> changes.
>
> Is it still the position that this change should be reverted?
>
> (I have no interest in writing the manual changes that would be needed.)

As I understand, these changes were not documented because more changes
were expected that will waste the efforts invested to writing the
necessary Emacs Manual changes.

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

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    As I understand, these changes were not documented because more changes
    were expected that will waste the efforts invested to writing the
    necessary Emacs Manual changes.

That does not make much sense.  If a totally different change is being
considered, such that people think there is no need to document this
one, why install this one now?

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

>> But this does point up the fact that this change requires changes in
>> many places in the Emacs manual.  We should probably take the change
>> out and not install it until after writing the necessary Emacs Manual
>> changes.

> Is it still the position that this change should be reverted?

Yes, I think it should be reverted for now,


        Stefan

Re: Enabling Transient Mark Mode by default

[Juri Linkov]

>>> But this does point up the fact that this change requires changes in
>>> many places in the Emacs manual.  We should probably take the change
>>> out and not install it until after writing the necessary Emacs Manual
>>> changes.
>
>> Is it still the position that this change should be reverted?
>
> Yes, I think it should be reverted for now,

When someone will start preparing a patch with documentation, what
reached consensus on this list should be kept in mind?  Is it accepted
that transient-mark-mode should be t by default?  What about shift-arrows
and delete-selection-mode?  Should they be rewritten in C to avoid
using command hooks?

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

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    > But this does point up the fact that this change requires changes in
    > many places in the Emacs manual.  We should probably take the change
    > out and not install it until after writing the necessary Emacs Manual
    > changes.

    Is it still the position that this change should be reverted?

Stefan and Yidong can decide, but my opinion is still that it should
be reverted, and reinstalled when the necessary manual changes are
done.  Changing the manual for this is a substantial job.

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    I won't bother advocating that menus and tool bars and
    scroll bars be deactivated by default, but I would at least
    suggest that the right principle is that if a feature would
    make it actively more difficult to use Emacs in the way that
    it is fundamentally designed to be used, then that feature
    ought not to be active by default.

That is an interesting argument.  But does region highlighting
make it header to learn to use Emacs as Emacs should be used?
I don't see that it does.  Can someone argue that it does?

Re: Enabling Transient Mark Mode by default

[Robert J. Chassell]

    ... does region highlighting make it harder to learn to use Emacs ...?

As far as I can see it does, since extraneous highlighting means you
are less likely to use C-SPC (set-mark-command) for navigation or use
C-SPC and then C-a (move-beginning-of-line) when in the center of a
line (i.e., use Emacs as an editor.  I know this sets the mark twice
but the single keyboard command of just C-a (move-beginning-of-line)
does not set the region to be just the part of the line moved over.)

With Transient-Mark mode disabled, those commands do not cause
highlighting in editing buffers.  

Today's GNU Emacs CVS snapshot, Thu, 2008 Feb 21  11:06 UTC
GNU Emacs 23.0.60.8 (i686-pc-linux-gnu, GTK+ Version 2.12.5)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Enabling Transient Mark Mode by default

[Stephen J. Turnbull]

Sascha Wilde writes:

 > One important reason against it is, that it makes uses of the mark
 > ring other than marking text very unpleasant.  [...]  In such cases
 > the highlighting of text between point and the last mark is
 > distracting and useless.

True.  However, I've found that zmacs-regions (the XEmacs equivalent
of tmm) cooperates very well with two other features, namely
pending-delete mode (ie, the active region is deleted when you type
into it) and navigation by isearch (which sets the mark but does not
activate the region).  I'm willing to put up with this annoyance for
that reason.

A similar use occurs with M-> and M-< (mark is set but region is not
active).  I wonder if it might be worthwhile to have "big jump" motion
deactivate the region.  I rare do things like C-SPC C-n unless I'm
marking text to operate on, and then I want (unobtrusive :-)
highlighting, while the highlighting is annoying in the case of C-SPC
C-v much of the time.

 > typing C-SPC C-SPC is still possible and easy.

YMMV but I don't find C-SPC C-g that bad.

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    A similar use occurs with M-> and M-< (mark is set but region is not
    active).  I wonder if it might be worthwhile to have "big jump" motion
    deactivate the region.

Right now, M-< neither activates the mark nor deactivates it.
Are you suggesting that it should deactivate the mark instead?
That would make a difference when you use it when the mark is active.
Is that what people want?

Re: Enabling Transient Mark Mode by default

[Luc Teirlinck]

       A similar use occurs with M-> and M-< (mark is set but region is not
       active).  I wonder if it might be worthwhile to have "big jump" motion
       deactivate the region.

   Right now, M-< neither activates the mark nor deactivates it.
   Are you suggesting that it should deactivate the mark instead?
   That would make a difference when you use it when the mark is active.
   Is that what people want?

_Definitely_ not. I often use M-< and friends to define a region in
situations where using non-"big jump" commands would be
super-cumbersome and time consuming.  I often _want_ commands to
operate on a huge region and it is hard for me to imagine that nobody
else ever does.

Sincerely,

Luc Teirlinck.

Re: Enabling Transient Mark Mode by default

[Stephen J. Turnbull]

Richard Stallman writes:
 >     A similar use occurs with M-> and M-< (mark is set but region is not
 >     active).  I wonder if it might be worthwhile to have "big jump" motion
 >     deactivate the region.
 > 
 > Right now, M-< neither activates the mark nor deactivates it.
 > Are you suggesting that it should deactivate the mark instead?

No, I'm pointing out that M-< sets the mark, at least in XEmacs, and I
use M-< .... C-u C-SPC a lot.  I use C-s ... C-u C-SPC in the same
way.  I don't think I would like it very much if this activated the
region and put the highlighting in my face.

So maybe C-SPC C-n should leave you with an active region, but C-SPC
C-u 256 C-n should not.

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    No, I'm pointing out that M-< sets the mark, at least in XEmacs, and I
    use M-< .... C-u C-SPC a lot.  I use C-s ... C-u C-SPC in the same
    way.  I don't think I would like it very much if this activated the
    region and put the highlighting in my face.

Neither of those activates the region in Transient Mark mode.
So it looks like what you're ask for is already implemented.

Is there a misunderstanding?

    So maybe C-SPC C-n should leave you with an active region, but C-SPC
    C-u 256 C-n should not.

That seems to be a totally different issue, unrelated to the previous
one.

I think it would be a bad idea to make C-u 256 C-n treat the mark
differently from C-n.  So I have to say no to this idea.

Re: Enabling Transient Mark Mode by default

[Stephen J. Turnbull]

Richard Stallman writes:

 >     No, I'm pointing out that M-< sets the mark, at least in XEmacs, and I
 >     use M-< .... C-u C-SPC a lot.  I use C-s ... C-u C-SPC in the same
 >     way.  I don't think I would like it very much if this activated the
 >     region and put the highlighting in my face.
 > 
 > Neither of those activates the region in Transient Mark mode.
 > So it looks like what you're ask for is already implemented.
 > 
 > Is there a misunderstanding?

My point is precisely that those are convenient for navigation because
they don't activate the region.  I don't want that to change.

 >     So maybe C-SPC C-n should leave you with an active region, but C-SPC
 >     C-u 256 C-n should not.
 > 
 > That seems to be a totally different issue, unrelated to the previous
 > one.

The relationship I perceive is that the distance moved may have a
correlation to the user's desire for highlighting and mark activation,
and tolerance for extra keystrokes to explicitly activate the mark.
In my case, it does.

 > I think it would be a bad idea to make C-u 256 C-n treat the mark
 > differently from C-n.  So I have to say no to this idea.

OK.

Maybe I'll try it and if my perception is that there is some
improvement to be had, I'll see if there's a way to implement a
similar effect without violating this intuition.

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    One important reason against it is, that it makes uses of the mark ring
    other than marking text very unpleasant.  The manual starts section 12.6
    with the example of using the mark to mark interesting spots in an
    buffer so that one can easily jump between them (in many cases this is
    faster than saving positions in registers and therefor very
    convenient).  In such cases the highlighting of text between point and
    the last mark is distracting and useless.

You seem to be talking about the case when the mark is active.
But that's an unusual case, and it's easy to turn off,
so why so concerned about it?

RE: Enabling Transient Mark Mode by default

[Drew Adams]

> Whenever I use "emacs -Q" or some similar "vanilla Emacs", the first
> thing that I'm urged to do is M-x transient-mark-mode (and it was
> already N°1 back when fotn-lock-mode wasn't the default).
> 
> Of course, I'm sure I'd be able to learn to live without it.  It seems
> like an option affect people *very* strongly, so those who want it
> *really* want it, and those who don't *really* don't.
> 
> So, that's for my personal preference.  As to why turn it on *by
> default*, here are some reasons why I think it should be ON 
> by default:
> - Visual feedback about the mark's position and active status.
>   I and all (X)Emacs users I know personally (i.e. off-this-list) and
>   with whom I've talked about transient-mark-mode use
>   transient-mark-mode (or its XEmacs equivalent) and find it difficult
>   to use Emacs without it because of the lack of visual feedback about
>   where the mark really is.  I do not claim that this small group of
>   people is representative, but it does seem relevant.
> - Extended semantics for various commands.
>   Many commands now offer to operate on the region if the region is
>   active but only when transient-mark-mode is ON.
>   This functionality is now also available to non-tmm-users via the
>   temporary-transient-mark-mode (C-SPC C-SPC), admittedly, but while
>   C-SPC C-SPC is easy enough to use, I always find myself 
>   selecting the
>   region *before* knowing that I want to use such a command (or
>   selecting the region with something else than C-SPC, typically
>   C-M-SPC), so I end up having to use C-u C-x C-x which I find a lot
>   more inconvenient.

Well, I thought I might successfully stay out of this calorific thread ;-),
but here goes -

I agree with what Stefan has said, including the reasons he gave for turning
t-m mode on by default.

For the record: I used Emacs for many years with no problem before t-m mode
existed and before there was any mouse support. So I should be able to
understand to some extent those who say they are used to doing without such
features. 

Personally, however, I had no difficulty getting used to t-m mode. I
immediately adopted it, and I haven't looked back. Likewise, FWIW, it didn't
take me long to start using the mouse on occasion. I tend to use the mouse
now (clicking, not dragging) for selecting text and sexps in some
situations, even though much of the time I do not use it. It is a
random-access pointing device, and random access can be an advantage in some
contexts.  anti-rodent -flames > /dev/null

FWIW, I have never experienced the issues that others have cited wrt t-m
mode. I cannot recognize the behavior behind statements such as these:

> Transient-mark-mode messes with the normal work flow (and the
> active region) in a way that is not helpful.

> it makes uses of the mark ring other than marking text
> very unpleasant

> using the mark to mark interesting spots in an buffer so
> that one can easily jump between them....  In such cases the
> highlighting of text between point and the last mark is
> distracting and useless.

I don't discount others experiencing such problems. I'm unexperienced in
that way; that's all. Transient-mark mode doesn't interfere with my work
flow at all - quite the contrary, but maybe my work doesn't flow in the same
direction as yours.

So count me as one person who was quite used to the "old" way but
nevertheless changed to the "new" way. That doesn't mean the new trick is
right for other old dogs - YMMV. It just means that there are some people
used to living without t-m mode who can end up appreciating it.

My vote (we've been through this before...) is for delete-selection mode to
be on by default. Second choice: transient-mark mode on by default. In
either case, `mark-even-if-inactive' should be non-nil by default. Just one
vote.

Wrt emacs -nw: I can't speak to this, because I no longer use Emacs without
a window manager, but from Alan's report, perhaps the default should be
different for emacs -nw. He seemed to be reporting horrible dark blue
flashes or something. Maybe others can comment on whether the default should
differ in this case.

Re: Enabling Transient Mark Mode by default

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> Wrt emacs -nw: I can't speak to this, because I no longer use Emacs without
> a window manager, but from Alan's report, perhaps the default should be
> different for emacs -nw. He seemed to be reporting horrible dark blue
> flashes or something. Maybe others can comment on whether the default should
> differ in this case.

I regularly use tmm on both X and tty displays, and I don't think
there's any problem with tmm on ttys using the default faces (in fact I
quite like the "blue" tmm region face used on ttys) .

I think basic problem is Alan's visceral dislike of tmm, not any
particular problem with tmm on ttys.

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Enabling Transient Mark Mode by default

[Richard Stallman]

    I regularly use tmm on both X and tty displays, and I don't think
    there's any problem with tmm on ttys using the default faces (in fact I
    quite like the "blue" tmm region face used on ttys) .

I use Transient Mark mode on ttys all the time
with the default faces.  I think they are ok.

Re: Enabling Transient Mark Mode by default

[Alan Mackenzie]

Hi, Miles!

On Thu, Feb 21, 2008 at 09:10:05AM +0900, Miles Bader wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
> > Wrt emacs -nw: I can't speak to this, because I no longer use Emacs without
> > a window manager, but from Alan's report, perhaps the default should be
> > different for emacs -nw. He seemed to be reporting horrible dark blue
> > flashes or something. Maybe others can comment on whether the default should
> > differ in this case.

> I regularly use tmm on both X and tty displays, and I don't think
> there's any problem with tmm on ttys using the default faces (in fact I
> quite like the "blue" tmm region face used on ttys) .

> I think basic problem is Alan's visceral dislike of tmm, not any
> particular problem with tmm on ttys.

Hey, I had to look that word up in a dictionary.  I thought it was an
insult, but it's not - merely accurate.  Thanks for the new word, Miles.
;-)

Yes, I dislike TMM, but not only viscerally, intellectually as well - it
takes a starkly simple and intuitive concept, the mark, and turns it
into something complicated with masses of detailed rules.  Still, enough
people like it that there must be substantial benefit to offset the
complexity.  Thanks to the the people (Drew, Stefan, ...) who've made
this understandable.

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Tentative diagnosis of TMM's problem. [Re: Enabling Transient Mark Mode by default]

[Alan Mackenzie]

Hi, Stefan,

On Wed, Feb 20, 2008 at 11:52:32AM -0500, Stefan Monnier wrote:
> Whenever I use "emacs -Q" or some similar "vanilla Emacs", the first
> thing that I'm urged to do is M-x transient-mark-mode (and it was
> already N°1 back when fotn-lock-mode wasn't the default).

> Of course, I'm sure I'd be able to learn to live without it.  It seems
> like an option affect people *very* strongly, so those who want it
> *really* want it, and those who don't *really* don't.

Strongly agreed!  It should be obvious, really - using Emacs with TMM is
so radically different from using it without, that it's difficult to
imagine anybody not being unhappy with (at least) one of these options.

Anyhow, thanks for actually giving positive reasons for favouring TMM.
They've been pretty much missing, so far in the thread.

After thinking your next paragraphs over, I think I can see the big
problem with TMM:

> So, that's for my personal preference.  As to why turn it on *by
> default*, here are some reasons why I think it should be ON by default:

> - Visual feedback about the mark's position and active status.
>   I and all (X)Emacs users I know personally (i.e. off-this-list) and
>   with whom I've talked about transient-mark-mode use
>   transient-mark-mode (or its XEmacs equivalent) and find it difficult
>   to use Emacs without it because of the lack of visual feedback about
>   where the mark really is.  I do not claim that this small group of
>   people is representative, but it does seem relevant.

> - Extended semantics for various commands.
>   Many commands now offer to operate on the region if the region is
>   active but only when transient-mark-mode is ON.
>   This functionality is now also available to non-tmm-users via the
>   temporary-transient-mark-mode (C-SPC C-SPC), admittedly, but while
>   C-SPC C-SPC is easy enough to use, I always find myself selecting the
>   region *before* knowing that I want to use such a command (or
>   selecting the region with something else than C-SPC, typically
>   C-M-SPC), so I end up having to use C-u C-x C-x which I find a lot
>   more inconvenient.

And that problem is, what on earth do these two facets of TMM have to do
with eachother?  Why should you have to "suffer" the visual effects of
TMM, if you just want to use the "extended semantics", and why can you
only highlight the region as a side effect of doing something else?

I think that if we partitioned TMM into the command `highlight-region',
and the other stuff, most of the acrimony on this thread would abate.
highlight-region probably deserves its own key binding.

> -- Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Tentative diagnosis of TMM's problem. [Re: Enabling Transient Mark Mode by default]

[Stefan Monnier]

>> - Visual feedback about the mark's position and active status.
>> I and all (X)Emacs users I know personally (i.e. off-this-list) and
>> with whom I've talked about transient-mark-mode use
>> transient-mark-mode (or its XEmacs equivalent) and find it difficult
>> to use Emacs without it because of the lack of visual feedback about
>> where the mark really is.  I do not claim that this small group of
>> people is representative, but it does seem relevant.

>> - Extended semantics for various commands.
>> Many commands now offer to operate on the region if the region is
>> active but only when transient-mark-mode is ON.
>> This functionality is now also available to non-tmm-users via the
>> temporary-transient-mark-mode (C-SPC C-SPC), admittedly, but while
>> C-SPC C-SPC is easy enough to use, I always find myself selecting the
>> region *before* knowing that I want to use such a command (or
>> selecting the region with something else than C-SPC, typically
>> C-M-SPC), so I end up having to use C-u C-x C-x which I find a lot
>> more inconvenient.

> And that problem is, what on earth do these two facets of TMM have to do
> with eachother?

Keeping track of when the region is active and when it isn't can be
tricky, so without the visual feedback, you may get nasty surprises
where you end up, e.g., commenting a large part of your code instead of
inserting a harmless ";" at the end of the current line.

> Why should you have to "suffer" the visual effects of
> TMM, if you just want to use the "extended semantics",

You don't: you can change the `region' face so that it can't be seen.

> and why can you
> only highlight the region as a side effect of doing something else?

If you only want to visually highlight a piece of text, you can use
other packages that do that, like facemenu.

> I think that if we partitioned TMM into the command `highlight-region',
> and the other stuff, most of the acrimony on this thread would abate.
> highlight-region probably deserves its own key binding.

I don't think it's the right way to cut it.  The main issue is with the
conflation of 2 concepts on the set/push-mark commands: one is to push
a buffer location on a ring for navigational purposes, the other is to
set the boundary of the region.

TMM is great for the second use, and is a drag for the first.

Until now, the tendency has been to make the default closer and closer
to TMM, without going all the way to enabling TMM.  The main step in
that direction was the introduction of temporary-TMM.  Maybe another
step in that direction would be to make more commands enable
temporary-TMM.  E.g. all the mark-* commands which I expect are rarely
used for navigational purposes.  That would get us closer to TMM, but
one command at a time.


        Stefan

RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Drew Adams]

> The main issue is with the conflation of 2 concepts on
> the set/push-mark commands: one is to push a buffer
> location on a ring for navigational purposes, the other
> is to set the boundary of the region.
> 
> TMM is great for the second use, and is a drag for the first.

Perhaps there is another way to look at this. Just throwing out an idea. I
imagine that people from all directions will fire upon it, but what the
heck:

Do C-SPC to set the mark. Then click mouse-1 somewhere else. Point has moved
away from the mark, but the region is not active, so no highlighting. In t-m
mode, you can still use the region, if you have `mark-even-if-inactive' = t.
I don't think anyone has complained about this use case.

If, instead of clicking mouse-1, you use C-f (or C-M-f or...), then the
region stays active. It is this highlighting that people find annoying,
apparently. You cannot move point without the region being active (and thus
highlighted), unless you use the mouse.

Question: Is it important that the region stay active when you move point?
If not, then perhaps (in t-m mode) we should always have point movement
deactivate the region.

The behavior would then be that you would use C-SPC to set mark and C-x C-x
(or C-x C-x C-x C-x) to activate the region. The region would not be active
otherwise. But with non-nil `mark-even-if-inactive', you could still use the
region - you would get the same behavior as now, but without the annoying
highlighting.

The basic choices would then be: (a) t-m mode off, same behavior as now (the
region is always active, and no highlighting), (b) t-m mode on,
`mark-even-if-inactive' = nil: you must activate the region explicitly (C-x
C-x), to use it, (c) t-m mode on, `mark-even-if-inactive' = t: same behavior
as now, but no highlighting unless you activate the region explicitly.

FWIW, I have `mark-even-if-inactive' = t, which means I can always use the
region, but I can see when it is active (highlighting). 

Some contexts use the region only when it is active. Those are typically
either contexts where it is helpful to see the region before acting on it or
commands that can act either on the region or on the whole buffer. The
behavior for such contexts should not change if we implemented this idea.

Just an idea. Personally, I don't have a problem with the current t-m mode
behavior.

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Lennart Borgman (gmail)]

Drew Adams wrote:
> Question: Is it important that the region stay active when you move point?
> If not, then perhaps (in t-m mode) we should always have point movement
> deactivate the region.

In my opinion it is important to behave as other application when it is 
possible this means that:

- The region should be highlighted when active
- Using shift arrow keys should not deactivate the region
- Using arrow keys without shift should deactivate the region
- Something similar for the mouse but I do not know the details since I 
do not use the mouse for text editing.

On the other hand I find it very pratictal that the region stays active 
for many other commands that moves the point (C-s for example). This is 
the case for cua-mode today.

RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Drew Adams]

> > Question: Is it important that the region stay active when 
> > you move point? If not, then perhaps (in t-m mode) we should
> > always have point movement deactivate the region.
> 
> In my opinion it is important to behave as other application 
> when it is possible

What other applications define the selection using a point and mark? What
other applications extend the selection when you simply advance the cursor
(point)?

> this means that:
> 
> - The region should be highlighted when active

That would still be true for the idea I suggested. The region would not be
activated just by moving the cursor; that's all. That's similar to what
happens in other apps, AFAIK.

> - Using shift arrow keys should not deactivate the region

I did not say anything about the shifted arrow keys.

> - Using arrow keys without shift should deactivate the region

That was the idea.

> - Something similar for the mouse but I do not know the 
> details since I do not use the mouse for text editing.

The mouse is fine as is, I believe. I don't think anyone has complained
about it in this context.

> On the other hand I find it very pratictal that the region 
> stays active for many other commands that moves the point (C-s for 
> example). This is the case for cua-mode today.

Maybe my idea would have been better expressed as this: C-SPC would set the
mark but would not activate the region. That way, cursor movements
(including C-s) would extend the inactive region or the active region. In
the case of the active region, the highlighting (in t-m mode) would be
extended accordingly.

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[David De La Harpe Golden]

On 20/02/2008, Drew Adams <drew.adams@oracle.com> wrote:

> Do C-SPC to set the mark. Then click mouse-1 somewhere else. Point has > moved away from the mark, but the region is not active, so no
> highlighting.


> That would still be true for the idea I suggested. The region would not be
>  activated just by moving the cursor; that's all. That's similar to what
>  happens in other apps, AFAIK.
>

Okay, those two lines suggest a possible misunderstanding, or you were
just talking loosely - in tmm,  C-SPC sets and activates the mark.
mouse-1 clicking (or zero-length drag) just happens to deactivate it.
FWIW mouse 3 clicking doesn't deactivate the mark, but may move the
mark or point according to a nice little do-what-I-mean algo.

Moving the the cursor after C-SPC doesn't activate the mark in tmm, it
just makes the already-active region become nonzero sized.

RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Drew Adams]

> > Do C-SPC to set the mark. Then click mouse-1 somewhere 
> > else. Point has moved away from the mark, but the region is 
> > not active, so no highlighting.
> 
> > That would still be true for the idea I suggested. The 
> > region would not be activated just by moving the cursor;
> > that's all. That's similar to what happens in other apps,
> > AFAIK.
> 
> Okay, those two lines suggest a possible misunderstanding, or you were
> just talking loosely - in tmm,  C-SPC sets and activates the mark.
> mouse-1 clicking (or zero-length drag) just happens to deactivate it.

Correct. And the net result is that point has moved away from mark and the
region is inactive.

> Moving the the cursor after C-SPC doesn't activate the mark in tmm, it
> just makes the already-active region become nonzero sized.

Correct.

And see my follow-up message. Instead of suggesting that point movements not
activate the mark (which, as you noted, is speaking loosely), I suggested
that C-SPC not activate the mark. 

With that suggestion, the region would become active only by explicit
activation via, e.g., `C-x C-x'. When inactive, Emacs pros can still use the
region and the mark (assuming non-nil `mark-even-if-inactive', by default).
And Emacs newbies (and some oldbies) can have their highlighted-selection
behavior.

The premise for this is that the newbies (and oldbies such as myself) don't
need to use the active region that comes automatically today from C-SPC +
cursor movement. They wouldn't mind hitting `C-x C-x' before doing something
that requires the active region.

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Sven Joachim]

On 2008-02-20 23:32 +0100, Lennart Borgman (gmail) wrote:

> - Using shift arrow keys should not deactivate the region
> - Using arrow keys without shift should deactivate the region

This will break on a tty, because shift arrow keys do not seem to be
available there.

Sven

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> Question: Is it important that the region stay active when you move point?
> If not, then perhaps (in t-m mode) we should always have point movement
> deactivate the region.

Yes, in fact it's a basic tenent of tmm usage...  People that are used
to tmm would be _extremely_ inconvenienced if movement deactivated the
mark.

Remember:  tmm is not cua-selection-mode.

-Miles

-- 
"An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god.  He only has to be someone who believes that the evidence
on the God question is at a similar level to the evidence on the werewolf
question."  [John McCarthy]

RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Drew Adams]

> > Question: Is it important that the region stay active when 
> > you move point? If not, then perhaps (in t-m mode) we
> > should always have point movement deactivate the region.
> 
> Yes, in fact it's a basic tenent of tmm usage...  People that are used
> to tmm would be _extremely_ inconvenienced if movement deactivated the
> mark.
> 
> Remember:  tmm is not cua-selection-mode.

Oh, I know it's not cua-selection-mode, believe me. And I'm one of those
regular tmm users. And I don't think I would mind such a change. 

But see my follow-up message. Instead of deactivating the region for point
movements (I misspoke, in fact), I clarified (changed) my suggestion to
simply not let C-SPC activate the region.

The active region would still act as usual, and so would the inactive
region.

Those who use Emacs now without tmm mode would either continue without it or
they might even like to try it. If they tried it, they could still use the
region without it being activated. (I'm assuming non-nil
`mark-even-if-inactive', by default.)

Those, like me, who use tmm mode now would, I think, not miss the automatic
region activation of C-SPC. I, at least, wouldn't mind doing C-x C-x
(possibly twice) when I really needed the region to be active.

Newbies would find something pretty familiar, even if in a slightly
different form. Mouse selection would of course be pretty familiar to them.
And they would eventually learn that they can activate (and make visible)
the existing (invisible) region, for times when they don't want to use the
mouse.

Commands and contexts that need to differentiate between active and inactive
region would still apply to the same use cases. I don't think plain C-SPC
plus cursor movement today is such a case - for either camp of users. 

For those who don't use tmm, today's highlighting in that context is
annoying. And I suspect that those who do use tmm don't take advantage of
the fact that the region is active in that C-SPC-move-the-cursor context -
even if they don't mind the highlighting. And even if they do take advantage
of that, I suspect they wouldn't mind the low price of `C-x C-x' to activate
the region. (But someone will set me straight, no doubt. ;-))

IOW, with my suggestion, the active region and its highlighting would be
used only for contexts that, well, actually distinguish an active region
from an inactive one. All other uses of the region and the mark would make
use of an inactive region. When you really need the region to be active, you
would need to activate it - no big deal. I use tmm (and
delete-selection-mode), and I could live with that. 

As someone pointed out, when you need an active region you typically want to
operate on a fairly big region. It's not as if you would be needing to
activate the region each time you marked a word or a sexp, in order to
operate on that region. Most operations can act on the region whether or not
it is active. For those operations that require an active region (e.g. to
distinguish from operating on the whole buffer), one or two `C-x C-x' is a
small price to pay for getting rid of today's pervasive (and gratuitous) tmm
highlighting from C-SPC activating the region.

But, as I also said, I personally have no problem with the status quo wrt
tmm and highlighting.

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[David De La Harpe Golden]

On 21/02/2008, Drew Adams <drew.adams@oracle.com> wrote:
>  Those, like me, who use tmm mode now would, I think, not miss the automatic
>  region activation of C-SPC. I, at least, wouldn't mind doing C-x C-x
>  (possibly twice) when I really needed the region to be active.
>

Setting the third arg to nil in the call to push-mark in
push-mark-command in simple.el can maybe give you a taste of it.
Maybe customisation could be introduced there.

I know from trying that that I dislike it though, maybe simply because
I'm accustomed to having the nice instant visual feedback of the
highlighted region rather than having to remember where the mark is
and imagine it.

I use C-SPC and cursor keys and C-SPC and C-s blah RET a lot (yes I
know that C-s RET can push a mark anyway, but then you need to C-x C-x
(C-x C-x...) _after_ the search and don't get the nice highlighting of
the region during the search, ho hum).

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Richard Stallman]

    But see my follow-up message. Instead of deactivating the region for point
    movements (I misspoke, in fact), I clarified (changed) my suggestion to
    simply not let C-SPC activate the region.

That is the main way to activate the mark, so if it stops doing so,
activating the mark would be inconvenient.

This change would be no improvement.

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Juri Linkov]

> "Drew Adams" <drew.adams@oracle.com> writes:
>> Question: Is it important that the region stay active when you move point?
>> If not, then perhaps (in t-m mode) we should always have point movement
>> deactivate the region.
>
> Yes, in fact it's a basic tenent of tmm usage...  People that are used
> to tmm would be _extremely_ inconvenienced if movement deactivated the
> mark.
>
> Remember:  tmm is not cua-selection-mode.

In cua-selection-mode point movement deactivates the region only when
the region was activated by shift-arrows.  But when the region is
activated by C-SPC, point movements extend the active region.

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

Re: Tentative diagnosis of Transient Mark mode's problem. [Re: Enabling TransientMark Mode by default]

[Richard Stallman]

    > Question: Is it important that the region stay active when you move point?
    > If not, then perhaps (in t-m mode) we should always have point movement
    > deactivate the region.

    Yes, in fact it's a basic tenent of [Transient Mark mode] usage...  

That change is a non-starter, so let's not discuss it any more.

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default]

[Alan Mackenzie]

Hi, Drew!

On Wed, Feb 20, 2008 at 02:16:14PM -0800, Drew Adams wrote:

> Perhaps there is another way to look at this. Just throwing out an idea. I
> imagine that people from all directions will fire upon it, but what the
> heck:

:-)

Doing a bit of heavy distortion and context removal on your post, you've
written ....

> ....but the region is not active, so no highlighting.  ...., if you
> have `mark-even-if-inactive' = t. 

This is what I was trying to say in my first post with this subject:  Why
the "so" in "so no highlighting"?  I'm beginning to think that this is
tautological (see below).

I'm beginning to think that people say "highlight a region" (particularly
in non-Emacs programs) when they really mean "create a region".  I think
I've seen Lennart doing this (hi, Lennart!).  This lack of precision is
unhelpful.

> FWIW, I have `mark-even-if-inactive' = t, which means I can always use the
> region, but I can see when it is active (highlighting). 

I've now become thoroughly confused as to what an "active" region is.  If
`mark-even-if-inactive' is t, I think "active" has become equivalent to
"highlit".  Somebody please unconfuse me as appropriate!

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[Drew Adams]

> Hi, Drew!

Hi Alan.

> > ....but the region is not active, so no highlighting.  ...., if you
> > have `mark-even-if-inactive' = t. 
> 
> Why the "so" in "so no highlighting"?
> I'm beginning to think that this is tautological (see below).

I'm no expert, but my understanding is no, it's not (see below).

> I'm beginning to think that people say "highlight a region" 
> (particularly in non-Emacs programs) when they really mean
> "create a region".  I think I've seen Lennart doing this
> (hi, Lennart!).  This lack of precision is unhelpful.

Lack of precision can be confusing, yes. Part of the difficulty about
speaking of this stuff without taking the extra words needed to clarify the
context is that different vocabulary is used in different contexts. In
particular, some of the discussion was about what people are used to doing
in other editors, where the terminology and behavior are different from
Emacs.

My understanding is the following. In Emacs:

1. As soon as you have set mark at least once, there is a region. The region
continues to exist for the rest of your Emacs session. It can be empty
(point = mark), but it is never destroyed.

2. Transient mark mode has a notion of active and inactive region (but the
region always exists - see #1). If you don't use t-m mode or one of its
derivatives such as delete-selection mode, then this distinction is not
important to you.

3. If you do use t-m mode: (a) You can activate and deactive the region.
This is, BTW, the same thing as activating and deactivating the mark. (b)
When the region is active, it is highlighted; when it is deactivated, it is
unhighlighted. (c) Commands such as C-SPC and C-x C-x activate the region.
Some other commands deactivate it. The command loop also deactivates it,
normally.

4. In t-m mode, some commands act differently, depending on whether the
region is active. For example, `query-replace' limits itself to the active
region; if the region is not active, then it acts on the whole buffer.

5. If you set option `mark-even-if-inactive' to non-nil, then you can always
use the region, even in t-m mode, and even when it is inactive. This option
has no effect unless you use t-m mode.

What's the point of #5, and isn't #5 confusing? Let me take the second part
first. Yes, it might confuse someone who doesn't know what to expect (which
is presumably why the default value is nil), because many commands that act
on the region will affect the region even if it is inactive and therefore
invisible. That could be disconcerting to a newbie, in particular. But it
can be handy for many Emacs users, I think. And it would become more
important with my suggestion - see below.

So what's the point of #5? Why have a notion of active/inactive, and why
make the region visible only some of the time, if you can still act on the
inactive, invisible region?

This is near the crux of what we've been debating, I think. IMO, there are
different use cases. Some people, I think, argue for one use case, and
others argue for the other use case. Both can be useful.

One use case is for operations that specifically are meant to act on the
active region. These are operations such as `query-replace' that offer
different actions depending on the active/inactive status, or they could be
operations (none comes to mind) for which it makes sense to show you (via
highlighting or bouncing the cursor) where the region is before you act on
it. Typically, these operations act on fairly large chunks of text, IMO.

The other use case is for all other region operations - operations for which
there is no special region vs buffer difference of behavior, and for which
you don't need or care to see the region before you whack it in some way.
These operations act on regions of all sizes, but on average they probably
act on smaller regions. If you want to delete a word or two, you just set
the region appropriately and then kill it.

Many Emacs users don't use t-m mode, so there is no distinction and only one
use case for them (the second one, above). In particular, they cannot take
advantage of the double-duty that commands such as `query-replace' offer.

Many other Emacs users do use t-m mode, but they leave
`mark-even-if-inactive' = nil, so they do not take advantage of the first
use case above. Even some t-m mode users who set `mark-even-if-inactive' = t
never or seldom, I suspect, take advantage of operations on the inactive
region.

And in fact, in t-m mode, the region is active a good part of the time, so
those users don't lose much. Each time you hit C-SPC, for instance, you
activate the region. Some people find it annoying that in cases like this
(C-SPC followed by simple cursor movement) the region is highlighted. Even
some people who choose to use t-m mode feel this way.

In particular, since C-SPC is often used to set multiple marks for
navigation, when you are doing that you are not really trying to redefine
the region (though that's what you are doing), and you are especially not
really intending to activate (and so highlight) the region.

Others might disagree with my summary, but I hope it helps.

What I threw out as a suggestion is to let users who choose so get rid of
some of the annoying highlighting for t-m mode by accepting to explicitly
activate the region whenever they want to use active-region operations. The
change would be to simply not let C-SPC activate the region. 

This would be, I think, for users who are midway between the two groups
mentioned - users who would like some of the advantages of each approach:

1. They would get the active/inactive distinction of today's t-m mode, for
things such as `query-replace'. But they would have to do something (e.g.
C-x C-x once or twice) to activate the region first for that.

2. They would not get the annoyance of so much highlighting, because the
region would not be activated automatically by C-SPC. They would get the
active region and its highlighting only on demand.

3. Such users would likely set `mark-even-if-inactive' = t, so they could
still use the region without activating it. They would not need or care to
see it highlighted for the simple operations. (And they could always
activate it whenever they did care.)

I didn't state it as part of my suggestion, but I think now that it would be
desirable for this behavior to be optional. You would set a new option
`set-mark-activates-region-flag' to nil, to stop C-SPC from activating the
mark.

> > FWIW, I have `mark-even-if-inactive' = t, which means I can 
> > always use the region, but I can see when it is active
> > (highlighting). 
> 
> I've now become thoroughly confused as to what an "active" 
> region is.  If `mark-even-if-inactive' is t, I think
> "active" has become equivalent to "highlit".
> Somebody please unconfuse me as appropriate!

They are not equivalent, but only the active region is highlighted, and it
is always highlighted. The important distinction for activation, IMO, is the
difference in behavior of some commands, such as `query-replace'. But yes,
highlighting is also an important attribute of the active region. 

HTH. But be prepared for another, counter opinion from some quarter. ;-)

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> What I threw out as a suggestion is to let users who choose so get rid
> of some of the annoying highlighting for t-m mode by accepting to
> explicitly activate the region whenever they want to use active-region
> operations. The change would be to simply not let C-SPC activate the
> region.

We already have that in Emacs 22.  Please get up to scratch before
proposing existing features.

(info "(emacs) Momentary Mark")

Though this node should mention that marking with the mouse also
temporarily triggers tmm.

> HTH. But be prepared for another, counter opinion from some
> quarter. ;-)

Such as the Emacs manual.

-- 
David Kastrup

RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[Drew Adams]

> > What I threw out as a suggestion is to let users who choose 
> > so get rid of some of the annoying highlighting for t-m mode
> > by accepting to explicitly activate the region whenever
> > they want to use active-region operations. The change would
> > be to simply not let C-SPC activate the region.
> 
> We already have that in Emacs 22.

Great minds think alike, I guess. ;-) Thanks for letting me know.

> Please get up to scratch before proposing existing features.

My ignorance is unpardonable. You can whip me now. I see you've already got
your costume ready.

> (info "(emacs) Momentary Mark")

Yes, that's the idea, though a simple C-x C-x won't activate the mark with
the current implementation, as it would with my suggestion. Even C-x C-x C-x
C-x is easier than C-u C-x C-x.

And I'm not sure I see the point of C-SPC C-SPC - who would really use it
and why. I understand the aim, I think, but I doubt many will use it. Sounds
like it was added just to be complete, to give people a way to give
themselves on demand the highlighting they find so annoying when automatic.

Anyway, since this is already available, what about:

1. Making it easier for people to activate the region. C-u C-x C-x is too
cumbersome. It should be at least as easy to activate mark as to set mark.

2. Advertising this more - especially to newbies. We should say that *this
is the way to select* text, besides using the mouse.

3. Making `mark-even-if-inactive' = t the default.

With that, I think more people will be happier. Everyone will still be able
to always act on the region at all times. But newbies and others will not be
confused or annoyed by an active region popping up just from C-SPC. And the
advantages of t-m mode will be easily available on demand. 

The only people who would prefer something else would then be, I suspect:

1. Those who like the current t-m activation by C-SPC. No one has spoken up
in favor of that.

2. Those who don't even like the idea of being *able* to activate the
region. They need only avoid activating it explicitly.

But I do think we should make it easier to activate the region than C-u C-x
C-x. Use of the active region should be encouraged, not discouraged.

The doc for all related stuff, such as delete-selection mode, should then be
updated to account for (mention) this. The doc should generally be written
from the point of view of this being the standard scenario. That's assuming
we decide that it should be the standard scenario.

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[Sascha Wilde]

"Drew Adams" <drew.adams@oracle.com> wrote:
[...]
> And I'm not sure I see the point of C-SPC C-SPC - who would really use it
> and why. I understand the aim, I think, but I doubt many will use it. Sounds
> like it was added just to be complete, to give people a way to give
> themselves on demand the highlighting they find so annoying when automatic.

FWIW: I do.  Sometimes for the changed semantics of some commands like
searches- and replace-commands, and often to show co-workers things on
the screen.

sascha
-- 
Sascha Wilde
God put me on earth to accomplish a certain number of things.
Right now I am so far behind I will never die.
                       -- Bill Waterson, Calvin and Hobbes

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> And I'm not sure I see the point of C-SPC C-SPC - who would really use
> it and why.

Sigh.  People who don't use transient-mark-mode but need an active
region sometimes.

> I understand the aim, I think, but I doubt many will use it. Sounds
> like it was added just to be complete, to give people a way to give
> themselves on demand the highlighting they find so annoying when
> automatic.

When you are done sneering at people who use different features than
you, just ring.

I use it and consider it valuable: there is no way short of the annoying
permanent tmm to make an active region, and active regions are necessary
for some commands.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Enabling Transient Mark Mode by default

[Robert J. Chassell]

    And I'm not sure I see the point of C-SPC C-SPC - who would really use it

You can invoke it accidently.  That is an unintended use.  I have done
that in the past when trying just to mark a small bit of text and
inadvertently illuminated a huge amount.  The frequent illuminations
became so irritating that I bound a function key (F10) to disable
Transient Mark mode.  Now I have learned not to press control space
twice ...

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Enabling Transient Mark Mode by default

[David De La Harpe Golden]

On 22/02/2008, Robert J. Chassell <bob@rattlesnake.com> wrote:
>
> Now I have learned not to press control space
>  twice ...
>

Patch I just sent to list makes one more C-SPC disable that temporary
enablement...

Re: Enabling Transient Mark Mode by default

[Stefan Monnier]

> became so irritating that I bound a function key (F10) to disable
> Transient Mark mode.

Why not just use C-g?


        Stefan

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> 1. As soon as you have set mark at least once, there is a region. The region
> continues to exist for the rest of your Emacs session. It can be empty
> (point = mark), but it is never destroyed.

You can remove the region by explicitly moving the mark marker to nil.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[Drew Adams]

> > 1. As soon as you have set mark at least once, there is a 
> >    region. The region continues to exist for the rest of
> >    your Emacs session. It can be empty (point = mark), but
> >    it is never destroyed.
> 
> You can remove the region by explicitly moving the mark marker to nil.

Of course.

In normal use, it remains - it remains if you don't use Lisp set it to nil.
That's the point to get across - it is always there, even when invisible
(inactive, in t-m mode).

Re: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMarkMode by default]

[Richard Stallman]

    5. If you set option `mark-even-if-inactive' to non-nil, then you can always
    use the region, even in t-m mode, and even when it is inactive. This option
    has no effect unless you use t-m mode.

    What's the point of #5, and isn't #5 confusing?

I don't have time to justify this, or even to read the whole of your
long message.  Please just accept this; we won't change it.

I hope the rest of the Emacs developers also won't spend time
arguing about this, because the distraction would get in the
way of other work.




 

Re: Tentative diagnosis of TMM's problem. [Re: Enabling Transient Mark Mode by default]

[Alan Mackenzie]

'Morning, Stefan!

On Wed, Feb 20, 2008 at 03:52:24PM -0500, Stefan Monnier wrote:

> > And that problem is, what on earth do these two facets [modification
> > of commands, and highlighting the region] of TMM have to do with
> > eachother?

> Keeping track of when the region is active and when it isn't can be
> tricky, so without the visual feedback, you may get nasty surprises
> where you end up, e.g., commenting a large part of your code instead
> of inserting a harmless ";" at the end of the current line.

> > Why should you have to "suffer" the visual effects of TMM, if you
> > just want to use the "extended semantics",

> You don't: you can change the `region' face so that it can't be seen.

> > and why can you only highlight the region as a side effect of doing
> > something else?

> If you only want to visually highlight a piece of text, you can use
> other packages that do that, like facemenu.

Yes, of course there are workarounds, but that doesn't answer the point.
;-)  Why is toggling the region highlighting not regarded as a command
in its own right?  Why can I not, in emacs -Q, highlight the region with
(say) C-x r h?  (Hey, that binding, still unused, could hardly be more
appropriate.  :-)

> > I think that if we partitioned TMM into the command `highlight-region',
> > and the other stuff, most of the acrimony on this thread would abate.
> > highlight-region probably deserves its own key binding.

> I don't think it's the right way to cut it.  The main issue is with the
> conflation of 2 concepts on the set/push-mark commands: one is to push
> a buffer location on a ring for navigational purposes, the other is to
> set the boundary of the region.

Yes, "issue", but not "problem".  This handling of THE mark is essential
to Emacs, and I am convinced it is not coincidental.  These 2 mark uses
are not sharply distinct; I often want to go to places in the mark ring
that were originally there for region operation; I often do M-> C-w to
delete the last few lines of a buffer.  Were there to be separate marks
for these purposes, Emacs wouldn't be Emacs.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Tentative diagnosis of TMM's problem. [Re: Enabling Transient Mark Mode by default]

[Stefan Monnier]

>> If you only want to visually highlight a piece of text, you can use
>> other packages that do that, like facemenu.

> Yes, of course there are workarounds, but that doesn't answer the point.
> ;-)  Why is toggling the region highlighting not regarded as a command
> in its own right?  Why can I not, in emacs -Q, highlight the region with
> (say) C-x r h?  (Hey, that binding, still unused, could hardly be more
> appropriate.  :-)

As mentioned in an earlier message, I find that having to do C-u C-x C-x
to activate temporary-TMM is too long already.
[ So maybe M-x temporary-transient-mark-mode RET yes RET would be
  preferable, although partial-completion-mode could still undermine such
  efforts to force-train my (inexistent) touch-typing. ]

>> > I think that if we partitioned TMM into the command `highlight-region',
>> > and the other stuff, most of the acrimony on this thread would abate.
>> > highlight-region probably deserves its own key binding.

>> I don't think it's the right way to cut it.  The main issue is with the
>> conflation of 2 concepts on the set/push-mark commands: one is to push
>> a buffer location on a ring for navigational purposes, the other is to
>> set the boundary of the region.

> Yes, "issue", but not "problem".  This handling of THE mark is essential
> to Emacs, and I am convinced it is not coincidental.  These 2 mark uses
> are not sharply distinct; I often want to go to places in the mark ring
> that were originally there for region operation; I often do M-> C-w to
> delete the last few lines of a buffer.  Were there to be separate marks
> for these purposes, Emacs wouldn't be Emacs.

The issue is not so much the mark itself as the mark's
activation status.  Without TMM, the mark is (basically) always
activated because it never hurts.  Let's think of it as 3 different
activation levels:
0 - unset:  This state is rare and rather uninteresting.
    Basically it's only the initial state before the first
    mark-pushing command.
1 - set:  There is a mark, but it's not active, so the region is not
    highlighted and commands like M-; do not operate on the region.
    OTOH commands that only operate on the region such as C-w will
    work, tho.
2 - highlighted:  Not only there's a mark but it's active and the region
    is highlighted.

- By default: most mark-setting commands set the mark to 1 and some rare
  exceptions like C-u C-x C-x and C-SPC C-SPC set the mark to 2.
  C-g or buffer-edits only brings the mark from state 2 to state 1 and
  otherwise doesn't change anything.

- With TMM without mark-even-if-inactive: all mark-setting commands set
  the mark to state 2.
  C-g or buffer-edits only brings the mark to state 0.

- With TMM with mark-even-if-inactive: all mark-setting commands set
  the mark to state 2.
  C-g or buffer-edits bring the mark to state 1 and otherwise doesn't
  change anything.

So I suggest to close the gap between the previous default and the
current default by reverting to the previous default but changing some
of the mark-setting commands (I'm thinking mainly of the mark-*
commands) to set the state to 2 rather than to 1.


        Stefan

Re: Tentative diagnosis of TMM's problem.

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Maybe another step in that direction would be to make more commands
> enable temporary-TMM.  E.g. all the mark-* commands

Yeah, that sounds familiar...

-- 
Johan Bockgård

Re: Tentative diagnosis of TMM's problem.

[Stefan Monnier]

>> Maybe another step in that direction would be to make more commands
>> enable temporary-TMM.  E.g. all the mark-* commands
> Yeah, that sounds familiar...

I'm not sure what you mean by that, could you expand?


        Stefan

Re: Tentative diagnosis of TMM's problem.

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Maybe another step in that direction would be to make more commands
>>> enable temporary-TMM.  E.g. all the mark-* commands
>> Yeah, that sounds familiar...
>
> I'm not sure what you mean by that, could you expand?

I've been using exactly that configuration for a long time, as I have
previously mentioned in a thread (on gnu.emacs.help) where you were
involved[1].  You even posted code for doing it.

So obviously I like this idea.

-- 
[1] http://groups.google.com/groups/search?q=monnier+naughty+boy

Re: Tentative diagnosis of TMM's problem.

[Stefan Monnier]

>>>> Maybe another step in that direction would be to make more commands
>>>> enable temporary-TMM.  E.g. all the mark-* commands
>>> Yeah, that sounds familiar...
>> 
>> I'm not sure what you mean by that, could you expand?

> I've been using exactly that configuration for a long time, as I have
> previously mentioned in a thread (on gnu.emacs.help) where you were
> involved[1].  You even posted code for doing it.

Sorry, I didn't pay much attention to the actual content of the macro in
that thread, only to the way the macro was defined.


        Stefan

Re: Tentative diagnosis of TMM's problem. [Re: Enabling Transient Mark Mode by default]

[Richard Stallman]

    Strongly agreed!  It should be obvious, really - using Emacs with TMM is
    so radically different from using it without, that it's difficult to
    imagine anybody not being unhappy with (at least) one of these options.

I am surprised by that statement.  With mark-even-if-inactive set, the
difference is small.  What difference are you talking about that you
think is "radical"?

Re: Tentative diagnosis of TMM's problem. [Re: Enabling Transient Mark Mode by default]

[Alan Mackenzie]

Hi, Richard!

On Thu, Feb 21, 2008 at 04:16:37AM -0500, Richard Stallman wrote:
>     Strongly agreed!  It should be obvious, really - using Emacs with
>     TMM is so radically different from using it without, that it's
>     difficult to imagine anybody not being unhappy with (at least) one
>     of these options.

> I am surprised by that statement.  With mark-even-if-inactive set, the
> difference is small.  What difference are you talking about that you
> think is "radical"?

In Transient Mark Mode, you have two modes (in the sense of vi's "command
mode" and "insert mode"), and the behaviour of many common key sequences
differs greatly between them.  Standard Emacs doesn't otherwise have
modes in that sense.

Perhaps less radical, Emacs has traditionally been a peaceful editor - it
doesn't flash, it doesn't bang, doesn't explode dialogue boxes (or even
dialog boxes ;-) in your face, it doesn't thrust menus into your text
when you use a key sequence, and so on.  I suppose isearch lazy
highlighting is an exception here, but that hardly invalidates the rule.

Transient Mark Mode, where massive refontification can occur for the
simplest of actions makes Emacs significantly more intrusive.  I don't
think this should be done by default.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Tentative diagnosis of TMM's problem. [Re: Enabling Transient Mark Mode by default]

[Richard Stallman]

    In Transient Mark Mode, you have two modes (in the sense of vi's "command
    mode" and "insert mode"), 

I think that is a misleading comparison, because the mark can only
stay active for a short time.  An active mark is more like Isearch.

Re: Enabling Transient Mark Mode by default

[Juri Linkov]

> Whenever I use "emacs -Q" or some similar "vanilla Emacs", the first
> thing that I'm urged to do is M-x transient-mark-mode (and it was
> already N°1 back when fotn-lock-mode wasn't the default).

On environments where I need to start Emacs without .emacs, enabling
transient-mark-mode is the second thing I do.  The first thing
is enabling x-select-enable-clipboard which is much worse because
it requires typing M-: (setq x-select-enable-clipboard t) whereas
M-x transient-mark-mode is easier to type and even without it
C-SPC C-SPC is a real saver.

> Of course, I'm sure I'd be able to learn to live without it.  It seems
> like an option affect people *very* strongly, so those who want it
> *really* want it, and those who don't *really* don't.

As I understand one of the goals of enabling transient-mark-mode was
to make newbies more comfortable with Emacs, yet we achieve nothing.
When newbies run Emacs for the first time, they expect the same behavior
as in other their familiar programs.  For selecting the region of text most
modern programs provide two ways: with the mouse (already enabled by default
in Emacs), and by using arrow keys while holding the SHIFT key.  The latter
is still disabled by default.

So I think in addition to (or instead of) enabling transient-mark-mode,
we should enable a more close equivalent of selecting the region in
most programs, that is either pc-selection-mode or cua-selection-mode.
The question of using C-SPC to activate the region actually is
unrelated here because there are no equivalents to C-SPC in other
programs, so this is a separate question.

I see no objections against enabling SHIFT keys for region selection by
default (contrary to enabling transient-mark-mode :), except for
implementation details that can be fixed, of course.

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

Re: Enabling Transient Mark Mode by default [Re: CUA-mode features and documenation]

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Dan!
>
> On Sun, Feb 17, 2008 at 08:58:26AM -0800, Dan Nicolaescu wrote:
>> Richard Stallman <rms@gnu.org> writes:
>
>>   >     BTW, before the pretest for 22.1 you were trying
>>   >     transient-mark-mode in order to enable it by default. What was
>>   >     the result of that experiment?
>
>>   > I could not stand Transient Mark mode by itself.  However, I now
>>   > use it with `mark-even-if-inactive' = t, and I think that is fine.
>
>> OK, I have changed the default for mark-even-if-inactive to be t and
>> turned on transient-mark-mode by default.
>
> I feel I must protest about this.

Agreed.  This is an abomination.  I find that temporary transient mark
mode is all even an Emacs beginner will really need: after all, those
people will typically mark their texts with a mouse, anyway.

The mouse-invoked temporary transient mark mode is _really_ _really_
important.  But the general transient mark mode is a nuisance.

-- 
David Kastrup

Re: CUA-mode features and documenation

[David De La Harpe Golden]

On 15/02/2008, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> What cua-selection-mode provides is the:
> - transient-mark-mode
> - delete-selection-mode
> - S-ARROW_KEY extends the region
> (Probably some more, but this is the main functionality).
>
> This behavior is the default nowadays on the desktop, including in
> Gtk+/Gnome and KDE (also in XEmacs).

...ish. The emacs<->x-selection side is another matter, as per
"Improved X selections?" thread.

Re: CUA-mode features and documenation

[Leo]

On 2008-02-14 00:50 +0000, Miles Bader wrote:
>> I am not an extremist but it seems that having two similar menu items
>> will be too confusing.  I think `cua-selection-mode' is closer to what
>> most users expect from this type of thing nowadays.
>
> Most users expect MS word.  That's not what Emacs is.
>
> transient-mark-mode is a popular and straight-forward feature that
> highlights (heh!) Emacs' native command set, and I don't think we should
> bury such things.

Seconded.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: change cursor type when idle

[Richard Stallman]

    The reason it is tied into cua-mode in the first place is that I
    needed to have separate cursor styles for rectangle marking and the
    global-mark feature.  

As a historical explanation, that makes sense, but I don't see why
this is an argument against installing a general cursor-style control
feature.  The real point is that we should verify that it serves CUA's
needs before installing it.

    In principle, I fully agree that cua-mode should be completely
    separated into different packages, but unfortunately, the features
    provided by cua-mode need some rather deep interactions, so it
    is hard to actually split them (more than I have already done).

We shouldn't lump together the question of splitting out the CUA
with the question of splitting apart other CUA features.

Re: change cursor type when idle

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The reason it is tied into cua-mode in the first place is that I
>     needed to have separate cursor styles for rectangle marking and the
>     global-mark feature.  
>
> As a historical explanation, that makes sense, but I don't see why
> this is an argument against installing a general cursor-style control
> feature.  The real point is that we should verify that it serves CUA's
> needs before installing it.

I guess if the cursor package has a "cursor-style-setup-functions"
special hook of some form (the cursor package would run the functions on
this list and use the first non-nil cursor face returned instead of its
own idea of which cursor to use).

Then cua-mode could hook into that with its special cursor shapes and colors.

But notice that if the cursor package is using a post-command hook,
it will have problems if it is run before the cua-mode post-command hook.
Of course, cua-mode could just run the rest of its own post-command hook as part
of the call from the above list -- but suppose some other function on that
list determines to use another cursor, the cua hook will not be called.

So cua-mode will have to keep track of whether its hook on the cursor
hook is run before or after its own post command hook - and behave
accordingly.

Better would be to run the cursor-style-setup-functions hook from
C code (after post-command-hook) - and push appropriate functions
on that hook from Lisp if the user wants indications for e.g. overwrite
and read-only buffers.

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

Re: change cursor type when idle

[Richard Stallman]

Thanks for the analysis.  Now people know what is required.

Re: change cursor type when idle

[Juri Linkov]

>  - Someone that uses input methods should comment if changing the
>  cursor for when doing that is useful.

Yes, this is very useful.  This helps keeping track of the current
input method when typing multilingual texts (the indication on the
mode line is too hard to quickly locate when eyes are on the cursor).

>  - Changing the cursor in overwrite mode seems like a good idea, other
>    editors do it too.

But other editors usually start with a bar cursor by default, and
switch it to a box cursor in overwrite mode.

>  - IMO we should only consider adding this if we are willing to turn it
>    on by default.  If it's not considered useful enough to be on by
>    default, then it seems like fluff that it's not worth documenting.

I'm not against merging this with cua-mode by moving it to a separate
package like cua-cursor (isn't using a box cursor in overwrite mode
a CUA thing?)

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

Re: change cursor type when idle

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I'm not against merging this with cua-mode by moving it to a separate
> package like cua-cursor (isn't using a box cursor in overwrite mode
> a CUA thing?)

If merging, it seems better to rip out the CUA code and make it an
independent feature.  CUA sorely needs a good refactoring to rid it of
all the stuff which has nothing to do with CUA... [I seem to recall Kim
said it wasn't that easy, though.]

-Miles

-- 
"An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god.  He only has to be someone who believes that the evidence
on the God question is at a similar level to the evidence on the werewolf
question."  [John McCarthy]

Re: change cursor type when idle

[Juri Linkov]

>> I'm not against merging this with cua-mode by moving it to a separate
>> package like cua-cursor (isn't using a box cursor in overwrite mode
>> a CUA thing?)
>
> If merging, it seems better to rip out the CUA code and make it an
> independent feature.  CUA sorely needs a good refactoring to rid it of
> all the stuff which has nothing to do with CUA... [I seem to recall Kim
> said it wasn't that easy, though.]

While searching for the bug report about the cursor type, I've found
http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00034.html
where Kim said it is tied to the cua's global-mark feature.

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