Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[James Cloos]

C> Put scroll-bar on right by default on UNIX.

Ewww.  Why, if may I ask?

Way over on the right makes the scrollbar essentially useless (except,
of course, for putative buffers which are (will be) primarily r2l
and those times when the frame is split horizontally).

It really needs to be near the action, and on landscape displays the
frames are typically wider than (most of) the text.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

James Cloos <cloos@jhcloos.com> writes:

> C> Put scroll-bar on right by default on UNIX.
>
> Ewww.  Why, if may I ask?
>
> Way over on the right makes the scrollbar essentially useless (except,
> of course, for putative buffers which are (will be) primarily r2l
> and those times when the frame is split horizontally).
>
> It really needs to be near the action, and on landscape displays the
> frames are typically wider than (most of) the text.

I'm familiar with the advantages, but this battle was fought long ago.
Every graphical user interface created in the last X years puts the
scroll bar on the right.  Try naming one other application on a modern
GNU/Linux desktop that does the opposite by default---they don't exist.

Beyond a certain point, conflicting with users' expectations does more
harm than good.  But, you can do

  (set-scroll-bar-mode 'left)

or Options -> Show/Hide -> Scroll Bar -> On the Left.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[James Cloos]

>>>>> "CY" == Chong Yidong <cyd@stupidchicken.com> writes:

CY> Try naming one other application on a modern
CY> GNU/Linux desktop that does the opposite by default---they don't exist.

Terminal emulators, which should be the basis for emacs' x11 frames.

I've also seen it on other editors.

CY> Beyond a certain point, conflicting with users' expectations does
CY> more harm than good.

On the right is in conflict with expectations, not on the left.

CY>  But, you can do
CY>   (set-scroll-bar-mode 'left)

And do it, and do it, and do it again on every install.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

James Cloos <cloos@jhcloos.com> writes:

> Terminal emulators, which should be the basis for emacs' x11 frames.

I don't agree with the second half of this statement, but gnome-terminal
and konsole both put the scroll-bar on the right.

> On the right is in conflict with expectations, not on the left.
>
> CY>  But, you can do
> CY>   (set-scroll-bar-mode 'left)
>
> And do it, and do it, and do it again on every install.

Er, this is what the init file is for.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > I'm familiar with the advantages, but this battle was fought long ago.
>   > Every graphical user interface created in the last X years puts the
>   > scroll bar on the right.
>
> I don't think that can be used as an argument.  If it could, then
> delete-selection-mode would be the default too, that's what everything
> on the desktop does...

Compatibility with other apps is a valid argument, just not an absolute
rule.

What we could do, though, is to put non-toolkit scrollbars on the left
and toolkit scrollbars on the right.  If that's an acceptable
compromise, I'll implement it.

>   > Try naming one other application on a modern
>   > GNU/Linux desktop that does the opposite by default---they don't exist.
>
> xterm AKA the only terminal that actually works.

(The key word is "modern"; and personally, I use xterm with the
scrollbar disabled.)

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> What we could do, though, is to put non-toolkit scrollbars on the left
> and toolkit scrollbars on the right.  If that's an acceptable
> compromise, I'll implement it.

I mean GTK scrollbars.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>>   > I'm familiar with the advantages, but this battle was fought long ago.
>>   > Every graphical user interface created in the last X years puts the
>>   > scroll bar on the right.
>>
>> I don't think that can be used as an argument.  If it could, then
>> delete-selection-mode would be the default too, that's what everything
>> on the desktop does...
>
> Compatibility with other apps is a valid argument, just not an absolute
> rule.

With scrollbars, we are not talking about "compatibility" but
"similarity".  "compatibility" would be an issue when scripting
applications tried applying clicks to the scrollbar.

There is no compatibility issue involved here.

>>   > Try naming one other application on a modern
>>   > GNU/Linux desktop that does the opposite by default---they don't exist.
>>
>> xterm AKA the only terminal that actually works.
>
> (The key word is "modern"; and personally, I use xterm with the
> scrollbar disabled.)

So you are for disabling scrollbars altogether in Emacs?  Or what point
are you trying to make?

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[James Cloos]

>>>>> "CY" == Chong Yidong <cyd@stupidchicken.com> writes:

CY> What we could do, though, is to put non-toolkit scrollbars on the
CY> left and toolkit scrollbars on the right.  If that's an acceptable
CY> compromise, I'll implement it.

I was about to suggest something of that sort, specifically gtk toolkit
scrollbars on the right, athena on the left and non-toolkit on the left.
I do not know what the motif default should be.  Or even whether anyone 
still uses it.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Motif

[Richard Stallman]

    I do not know what the motif default should be.  Or even whether anyone 
    still uses it.

It would be good to find out.  We could put in something in configure.in
so that building with Motif requires some special option to confirm.
If you don't specify that option, it would print an error message
asking people to email us to tell us they are still building with Motif,
and to try again with that option,

delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Juri Linkov]

>> delete-selection-mode would be the default too, that's what everything
>> on the desktop does...

I agree with Richard that the primary concern is doing what is useful
for newcomers.  One of the most frequent questions they ask is how to do
what most other editors do - to replace selected text with a typed
character or with yanked text, and to delete the region by typing <delete>
without copying it to the kill-ring.

What they are asking for is delete-selection-mode,
but they can't find it in the documentation because
the feature name says nothing to beginners, and
they expect to take this functionality for granted.

Some recent examples of such problems:

http://thread.gmane.org/gmane.emacs.help/60992
http://thread.gmane.org/gmane.emacs.help/45623
http://thread.gmane.org/gmane.emacs.help/42402

Is that reason enough to enable delete-selection-mode by default?

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

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Lennart Borgman]

On Wed, Mar 17, 2010 at 1:54 AM, Juri Linkov <juri@jurta.org> wrote:
>>> delete-selection-mode would be the default too, that's what everything
>>> on the desktop does...
>
> I agree with Richard that the primary concern is doing what is useful
> for newcomers.  One of the most frequent questions they ask is how to do
> what most other editors do - to replace selected text with a typed
> character or with yanked text, and to delete the region by typing <delete>
> without copying it to the kill-ring.
>
> What they are asking for is delete-selection-mode,
> but they can't find it in the documentation because
> the feature name says nothing to beginners, and
> they expect to take this functionality for granted.
...
> Is that reason enough to enable delete-selection-mode by default?


In my opinion, yes.

RE: delete-selection-mode (was: Put scroll-bar on right by default onUNIX.)

[Drew Adams]

> Is that reason enough to enable delete-selection-mode by default?

I vote yes.  Yes, of course.

But we've been around this block a few times before. Here we go, round and
round. Folks will chime in again about cua-mode, cua-selection-mode,
pc-selection-mode, transient-mark-mode,... The antimouse will raise its medusa
head again... Round and round and round we go... Are we having fun yet?

Re: delete-selection-mode

[Juri Linkov]

>> Is that reason enough to enable delete-selection-mode by default?
>
> I vote yes.  Yes, of course.
>
> But we've been around this block a few times before. Here we go, round and
> round. Folks will chime in again about cua-mode, cua-selection-mode,
> pc-selection-mode, transient-mark-mode,... The antimouse will raise its medusa
> head again... Round and round and round we go... Are we having fun yet?

Please note that actually pc-selection-mode was already enabled
by default in 23.1 (shift-arrow keys with transient-mark-mode).

So now we have a weird state with enabled pc-selection-mode
and disabled delete-selection-mode.

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

RE: delete-selection-mode

[Drew Adams]

> >> Is that reason enough to enable delete-selection-mode by default?
> >
> > I vote yes.  Yes, of course.
> >
> > But we've been around this block a few times before. Here 
> > we go, round and round. Folks will chime in again about
> > cua-mode, cua-selection-mode, pc-selection-mode,
> > transient-mark-mode,... The antimouse will raise its medusa
> > head again... Round and round and round we go... Are we 
> > having fun yet?
> 
> Please note that actually pc-selection-mode was already enabled
> by default in 23.1 (shift-arrow keys with transient-mark-mode).

Hm. Not quite. `pc-selection-mode' is off (e.g. the variable is nil), though
what you say about the arrow keys is true. Thanks for pointing that out.

BTW -

I'm no expert on PC selection mode, but playing with it a bit and looking at the
doc, it seems that the behavior (but not the doc) has changed from Emacs 22 to
23 - no doubt due to the arrow-key change you refer to.

The doc for `pc-selection-mode' says that UNshifted arrow keys disable the mark
(I guess it should say "deactivate", not "disable"). But I don't see that
happening in Emacs 23. In Emacs 23, the arrow keys extend the active region,
whether or not they are shifted, and whether or not `pc-selection-mode' is
turned on.

Perhaps someone knowledgable can compare the `pc-selection-mode' behaviors in 22
and 23, and report back with (a) a summary and (b) whether the Emacs 23 behavior
is as documented.

> So now we have a weird state with enabled pc-selection-mode
> and disabled delete-selection-mode.

Actually, `pc-selection-mode' enables `delete-selection-mode' (hence also
t-m-mode).

FWIW, my own vote is still for `delete-selection-mode', not `pc-selection-mode'
as the default.

Re: delete-selection-mode

[Stefan Monnier]

> The doc for `pc-selection-mode' says that UNshifted arrow keys disable
> the mark (I guess it should say "deactivate", not "disable"). But
> I don't see that happening in Emacs 23. In Emacs 23, the arrow keys
> extend the active region, whether or not they are shifted, and whether
> or not `pc-selection-mode' is turned on.

Unshifted arrow keys indeed deactivate the mark in Emacs-23, but only if
the activation was with shifted arrow keys.

> FWIW, my own vote is still for `delete-selection-mode', not
> `pc-selection-mode' as the default.

I take advantage of this kitchen-sink thread to propose we mark
pc-selection-mode obsolete: as far as I know, in Emacs-23 it does not do
anything more than delete-selection-mode does (since the shift-arrow
selection part of its featureset is now provided by default anyway).


        Stefan

Re: delete-selection-mode

[Chong Yidong]

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

> I take advantage of this kitchen-sink thread to propose we mark
> pc-selection-mode obsolete: as far as I know, in Emacs-23 it does not do
> anything more than delete-selection-mode does (since the shift-arrow
> selection part of its featureset is now provided by default anyway).

100% fine by me.

Re: delete-selection-mode

[Juri Linkov]

> I take advantage of this kitchen-sink thread to propose we mark
> pc-selection-mode obsolete:

There is also lisp/s-region.el that could be marked obsolete.

> as far as I know, in Emacs-23 it does not do
> anything more than delete-selection-mode does (since the shift-arrow
> selection part of its featureset is now provided by default anyway).

It does something more:

  In addition, certain other PC bindings are imitated (to avoid this, set
  the variable `pc-select-selection-keys-only' to t after loading pc-select.el
  but before calling PC Selection mode):

    F6           other-window
    DELETE       delete-char
    C-DELETE     kill-line
    M-DELETE     kill-word
    C-M-DELETE   kill-sexp
    C-BACKSPACE  backward-kill-word
    M-BACKSPACE  undo"
    ;; FIXME: bring pc-bindings-mode here ?

Note the last line.  It suggests that these bindings could be moved
in the opposite direction - from pc-select.el back to pc-mode.el
(pc-bindings-mode).

After that, it seems pc-select.el is no more than delete-selection-mode
and shift-arrow.

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

Permanent shift-select-mode (was: delete-selection-mode)

[Juri Linkov]

> There is also lisp/s-region.el that could be marked obsolete.

s-region.el is now obsolete.  But unfortunately, `shift-select-mode'
is not an exact replacement.  There is an significant difference:
`shift-select-mode' deactivates the mark when a next key is not
shift-translated.

The following patch adds a new option `permanent' to
`shift-select-mode' that doesn't deactivate the mark:

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2010-03-05 12:01:10 +0000
+++ lisp/simple.el	2010-03-20 23:47:55 +0000
@@ -3956,9 +3956,15 @@ (defcustom shift-select-mode t
 by any subsequent point motion key that was not shift-translated, or
 by any action that normally deactivates the mark in Transient Mark mode.
 
+When the value is `permanent', the mark will not be deactivated
+by any subsequent point motion key that was not shift-translated.
+
 See `this-command-keys-shift-translated' for the meaning of
 shift-translation."
-  :type 'boolean
+  :type '(choice (const :tag "Off" nil)
+		 (const :tag "Permanent" permanent)
+		 (other :tag "On" t))
+  :version "23.1"
   :group 'editing-basics)
 
 (defun handle-shift-selection ()
@@ -3978,11 +3984,15 @@ (defun handle-shift-selection ()
 its earlier value."
   (cond ((and shift-select-mode this-command-keys-shift-translated)
          (unless (and mark-active
-                      (eq (car-safe transient-mark-mode) 'only))
-           (setq transient-mark-mode
-                 (cons 'only
-                       (unless (eq transient-mark-mode 'lambda)
-                         transient-mark-mode)))
+                      (or (eq (car-safe transient-mark-mode) 'only)
+			  (eq shift-select-mode 'permanent)))
+	   (setq transient-mark-mode
+                 (if (eq shift-select-mode 'permanent)
+		     (unless (eq transient-mark-mode 'lambda)
+		       transient-mark-mode)
+		   (cons 'only
+			 (unless (eq transient-mark-mode 'lambda)
+			   transient-mark-mode))))
            (push-mark nil nil t)))
         ((eq (car-safe transient-mark-mode) 'only)
          (setq transient-mark-mode (cdr transient-mark-mode))

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

Re: Permanent shift-select-mode

[Stefan Monnier]

>> There is also lisp/s-region.el that could be marked obsolete.
> s-region.el is now obsolete.  But unfortunately, `shift-select-mode'
> is not an exact replacement.  There is an significant difference:
> `shift-select-mode' deactivates the mark when a next key is not
> shift-translated.

> The following patch adds a new option `permanent' to
> `shift-select-mode' that doesn't deactivate the mark:

I'd first wait to hear people actually ask for this feature.


        Stefan

Re: delete-selection-mode

[Johan Bockgård]

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

> I take advantage of this kitchen-sink thread to propose we mark
> pc-selection-mode obsolete: as far as I know, in Emacs-23 it does not
> do anything more than delete-selection-mode does

The pc-select-override-scroll-error feature is something more.

Re: delete-selection-mode

[Juri Linkov]

>> I take advantage of this kitchen-sink thread to propose we mark
>> pc-selection-mode obsolete: as far as I know, in Emacs-23 it does not
>> do anything more than delete-selection-mode does
>
> The pc-select-override-scroll-error feature is something more.

I think it should be moved to simple.el since it is not directly related
to pc-select and is useful globally outside of pc-select.

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

scroll-top-bottom (was: delete-selection-mode)

[Juri Linkov]

>> The pc-select-override-scroll-error feature is something more.
>
> I think it should be moved to simple.el since it is not directly related
> to pc-select and is useful globally outside of pc-select.

This feature is implemented by CUA mode, but it would be very useful
for users who don't use CUA.  To support it in the core, I've implemented
a new user option `scroll-top-bottom' (that defines the scrolling behavior
at the top/bottom of the buffer).

If this is better to implement in Lisp, then `scroll-up' and
`scroll-down' should be moved from window.c to window.el.

=== modified file 'lisp/emulation/pc-select.el'
--- lisp/emulation/pc-select.el	2010-03-12 17:47:22 +0000
+++ lisp/emulation/pc-select.el	2010-03-19 23:59:44 +0000
@@ -93,6 +93,9 @@ (defcustom pc-select-override-scroll-err
 errors are suppressed."
   :type 'boolean
   :group 'pc-select)
+(define-obsolete-variable-alias 'pc-select-override-scroll-error
+                                'scroll-top-bottom
+                                "24.1")
 
 (defcustom pc-select-selection-keys-only nil
   "*Non-nil means only bind the basic selection keys when started.

=== modified file 'lisp/cus-start.el'
--- lisp/cus-start.el	2010-01-13 08:35:10 +0000
+++ lisp/cus-start.el	2010-03-19 23:55:19 +0000
@@ -306,6 +306,12 @@ (let ((all '(;; alloc.c
  		       (const :tag "Off (nil)" :value nil)
  		       (const :tag "Full screen (t)" :value t)
  		       (other :tag "Always" 1)) "22.1")
+ 	     (scroll-top-bottom
+ 	      windows (choice
+ 		       (const :tag "Off (nil)" :value nil)
+ 		       (other :tag "Move to top/bottom (t)" :value t))
+	      "24.1")
 	     (recenter-redisplay windows
 				 (choice
 				  (const :tag "Never (nil)" :value nil)

=== modified file 'src/window.c'
--- src/window.c	2010-01-13 08:35:10 +0000
+++ src/window.c	2010-03-19 23:57:16 +0000
@@ -168,6 +168,11 @@ (at your option) any later version.
 
 Lisp_Object Vscroll_preserve_screen_position;
 
+/* Non-nil means scroll commands move point to top/bottom of buffer
+   before signalling an error.  */
+
+Lisp_Object Vscroll_top_bottom;
+
 /* Non-nil means that text is inserted before window's markers.  */
 
 Lisp_Object Vwindow_point_insertion_type;
@@ -5014,7 +5019,12 @@
 			    - it.current_y + it.max_ascent + it.max_descent);
 	      adjust_glyphs (it.f);
 	    }
-	  else if (noerror)
+	  else if (!NILP (Vscroll_top_bottom) && PT < ZV)
+	    {
+	      SET_PT (ZV);
+	      return;
+	    }
+	  else if (noerror)
 	    return;
 	  else if (n < 0)	/* could happen with empty buffers */
 	    xsignal0 (Qbeginning_of_buffer);
@@ -5027,7 +5037,12 @@
 	    /* The first line was only partially visible, make it fully
 	       visible. */
 	    w->vscroll = 0;
-	  else if (noerror)
+	  else if (!NILP (Vscroll_top_bottom) && PT > BEGV)
+	    {
+	      SET_PT (BEGV);
+	      return;
+	    }
+	  else if (noerror)
 	    return;
 	  else
 	    xsignal0 (Qbeginning_of_buffer);
@@ -5242,7 +5257,12 @@
 
   if (lose)
     {
-      if (noerror)
+      if (!NILP (Vscroll_top_bottom) && PT > BEGV)
+	{
+	  SET_PT (BEGV);
+	  return;
+	}
+      else if (noerror)
 	return;
       else
 	xsignal0 (Qbeginning_of_buffer);
@@ -5328,7 +5348,12 @@
     }
   else
     {
-      if (noerror)
+      if (!NILP (Vscroll_top_bottom) && PT < ZV)
+	{
+	  SET_PT (ZV);
+	  return;
+	}
+      else if (noerror)
 	return;
       else
 	xsignal0 (Qend_of_buffer);
@@ -7268,6 +7293,15 @@
 Any other value means point always keeps its screen position.  */);
   Vscroll_preserve_screen_position = Qnil;
 
+  DEFVAR_LISP ("scroll-top-bottom",
+	       &Vscroll_top_bottom,
+	       doc: /* Controls if scroll commands move point to the top/bottom of the buffer.
+A value of nil means just signal an error if no more scrolling possible.
+A value of t means point moves to the beginning or the end of the buffer
+(depending on scrolling direction) when no more scrolling possible.
+When point is already on that position, then signal an error.  */);
+  Vscroll_top_bottom = Qnil;
+
   DEFVAR_LISP ("window-point-insertion-type", &Vwindow_point_insertion_type,
 	       doc: /* Type of marker to use for `window-point'.  */);
   Vwindow_point_insertion_type = Qnil;

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

Re: scroll-top-bottom

[Stefan Monnier]

>>> The pc-select-override-scroll-error feature is something more.
>> I think it should be moved to simple.el since it is not directly related
>> to pc-select and is useful globally outside of pc-select.
> This feature is implemented by CUA mode, but it would be very useful
> for users who don't use CUA.  To support it in the core, I've implemented
> a new user option `scroll-top-bottom' (that defines the scrolling behavior
> at the top/bottom of the buffer).

When scrolling by a page at a time, this makes sense, but when scrolling
only by a single line at a time, it's very odd for point to suddenly
jump several lines at a time.  So I think the behavior should be refined
so it doesn't just "move to BEGV or ZV" but instead "when scrolling by
N lines can't be done, move by N lines instead".

And yes, I think this would be better done at the Lisp level by
introducing new commands so it doesn't affect other code that calls
scroll-(up|down).

As for using it by default, I don't have a clear opinion on it yet.
It doesn't seem like a bad idea, but I haven't actually tried it.


        Stefan

Re: scroll-top-bottom

[Juri Linkov]

>> This feature is implemented by CUA mode, but it would be very useful
>> for users who don't use CUA.  To support it in the core, I've implemented
>> a new user option `scroll-top-bottom' (that defines the scrolling behavior
>> at the top/bottom of the buffer).
>
> When scrolling by a page at a time, this makes sense, but when scrolling
> only by a single line at a time, it's very odd for point to suddenly
> jump several lines at a time.  So I think the behavior should be refined
> so it doesn't just "move to BEGV or ZV" but instead "when scrolling by
> N lines can't be done, move by N lines instead".

And `cua-scroll-up' and `cua-scroll-down' have the same problem.
I'll try to create new commands based on `cua-scroll-up' and
`cua-scroll-down' but without these problems.

> And yes, I think this would be better done at the Lisp level by
> introducing new commands so it doesn't affect other code that calls
> scroll-(up|down).

I see what you mean.  These new commands should be a wrapper
like `next-line' for `forward-line'.  This will allow to bring
scrolling closer to point-moving commands feature-wise,
e.g. scrolling could also respect the value `goal-column'
like `next-line' does.

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

Scrolling commands (was: scroll-top-bottom)

[Juri Linkov]

>>> This feature is implemented by CUA mode, but it would be very useful
>>> for users who don't use CUA.  To support it in the core, I've implemented
>>> a new user option `scroll-top-bottom' (that defines the scrolling behavior
>>> at the top/bottom of the buffer).
>>
>> When scrolling by a page at a time, this makes sense, but when scrolling
>> only by a single line at a time, it's very odd for point to suddenly
>> jump several lines at a time.  So I think the behavior should be refined
>> so it doesn't just "move to BEGV or ZV" but instead "when scrolling by
>> N lines can't be done, move by N lines instead".

This scrolling behavior is now implemented by the patch below
based on `cua-scroll-up' and `cua-scroll-down'.

> And `cua-scroll-up' and `cua-scroll-down' have the same problem.
> I'll try to create new commands based on `cua-scroll-up' and
> `cua-scroll-down' but without these problems.
>
>> And yes, I think this would be better done at the Lisp level by
>> introducing new commands so it doesn't affect other code that calls
>> scroll-(up|down).
>
> I see what you mean.  These new commands should be a wrapper
> like `next-line' for `forward-line'.

When looking for the command names, I discovered that XEmacs has
such wrapper commands: `scroll-up-command' and `scroll-down-command'.
I think these are good names.  From XEmacs I took only command names.
The code is from `cua-scroll-up' and `cua-scroll-down'.

Also there were requests for commands that scroll only one line.
Actually such commands already exist in Emacs, but are hidden
in emulation/ws-mode.el.  This patch moves them to simple.el
with some modifications:

=== modified file 'lisp/emulation/ws-mode.el'
--- lisp/emulation/ws-mode.el	2010-01-13 08:35:10 +0000
+++ lisp/emulation/ws-mode.el	2010-03-30 22:17:38 +0000
@@ -339,16 +339,6 @@ (defun wordstar-center-line ()
        (+ left-margin
 	  (/ (- fill-column left-margin line-length) 2))))))
 
-(defun scroll-down-line ()
-  "Scroll one line down."
-  (interactive)
-  (scroll-down 1))
-
-(defun scroll-up-line ()
-  "Scroll one line up."
-  (interactive)
-  (scroll-up 1))
-
 ;;;;;;;;;;;
 ;; wordstar special variables:
 
=== modified file 'lisp/simple.el'
--- lisp/simple.el	2010-03-30 18:30:35 +0000
+++ lisp/simple.el	2010-03-30 22:12:17 +0000
@@ -4870,6 +4870,81 @@ (define-globalized-minor-mode global-vis
   visual-line-mode turn-on-visual-line-mode
   :lighter " vl")
 \f
+;;; Scrolling commands.
+
+(defun scroll-up-command (&optional arg)
+  "Scroll text of selected window upward ARG lines; or near full screen if no ARG.
+If `scroll-up' cannot scroll window further, move cursor to the bottom line.
+A near full screen is `next-screen-context-lines' less than a full screen.
+Negative ARG means scroll downward.
+If ARG is the atom `-', scroll downward by nearly full screen."
+  (interactive "^P")
+  (cond
+   ((eq arg '-) (scroll-down-command nil))
+   ((< (prefix-numeric-value arg) 0)
+    (scroll-down-command (- (prefix-numeric-value arg))))
+   ((eobp)
+    (scroll-up arg))  ; signal error
+   (t
+    (condition-case nil
+	(scroll-up arg)
+      (end-of-buffer
+       (if arg
+	   ;; When scrolling by ARG lines can't be done,
+	   ;; move by ARG lines instead.
+	   (forward-line arg)
+	 ;; When ARG is nil for full-screen scrolling,
+	 ;; move to the bottom of the buffer.
+	 (goto-char (point-max))))))))
+
+(put 'scroll-up-command 'isearch-scroll t)
+
+(defun scroll-down-command (&optional arg)
+  "Scroll text of selected window down ARG lines; or near full screen if no ARG.
+If `scroll-down' cannot scroll window further, move cursor to the top line.
+A near full screen is `next-screen-context-lines' less than a full screen.
+Negative ARG means scroll upward.
+If ARG is the atom `-', scroll upward by nearly full screen."
+  (interactive "^P")
+  (cond
+   ((eq arg '-) (scroll-up-command nil))
+   ((< (prefix-numeric-value arg) 0)
+    (scroll-up-command (- (prefix-numeric-value arg))))
+   ((bobp)
+    (scroll-down arg))  ; signal error
+   (t
+    (condition-case nil
+	(scroll-down arg)
+      (beginning-of-buffer
+       (if arg
+	   ;; When scrolling by ARG lines can't be done,
+	   ;; move by ARG lines instead.
+	   (forward-line (- arg))
+	 ;; When ARG is nil for full-screen scrolling,
+	 ;; move to the top of the buffer.
+	 (goto-char (point-min))))))))
+
+(put 'scroll-down-command 'isearch-scroll t)
+
+(defun scroll-up-line (&optional arg)
+  "Scroll text of selected window upward ARG lines; or one line if no ARG.
+If ARG is omitted or nil, scroll upward by one line.
+This is different from `scroll-up-command' that scrolls a full screen."
+  (interactive "p")
+  (scroll-up (or arg 1)))
+
+(put 'scroll-up-line 'isearch-scroll t)
+
+(defun scroll-down-line (&optional arg)
+  "Scroll text of selected window down ARG lines; or one line if no ARG.
+If ARG is omitted or nil, scroll down by one line.
+This is different from `scroll-down-command' that scrolls a full screen."
+  (interactive "p")
+  (scroll-down (or arg 1)))
+
+(put 'scroll-down-line 'isearch-scroll t)
+
+\f
 (defun scroll-other-window-down (lines)
   "Scroll the \"other window\" down.
 For more details, see the documentation for `scroll-other-window'."

=== modified file 'lisp/bindings.el'
--- lisp/bindings.el	2010-01-13 08:35:10 +0000
+++ lisp/bindings.el	2010-03-30 22:14:02 +0000
@@ -873,8 +873,8 @@ (define-key global-map [left]		'backward
 (define-key global-map [up]		'previous-line)
 (define-key global-map [right]		'forward-char)
 (define-key global-map [down]		'next-line)
-(define-key global-map [prior]		'scroll-down)
-(define-key global-map [next]		'scroll-up)
+(define-key global-map [prior]		'scroll-down-command)
+(define-key global-map [next]		'scroll-up-command)
 (define-key global-map [C-up]		'backward-paragraph)
 (define-key global-map [C-down]		'forward-paragraph)
 (define-key global-map [C-prior]	'scroll-right)

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

Re: Scrolling commands (was: scroll-top-bottom)

[Juanma Barranquero]

On Wed, Mar 31, 2010 at 00:27, Juri Linkov <juri@jurta.org> wrote:

> This scrolling behavior is now implemented by the patch below
> based on `cua-scroll-up' and `cua-scroll-down'.

> +(define-key global-map [prior]         'scroll-down-command)
> +(define-key global-map [next]          'scroll-up-command)

I'm currently using CUA-mode, but I do

  (define-key cua-global-keymap [remap scroll-up] nil)
  (define-key cua-global-keymap [remap scroll-down] nil)

because I don't want CUA-style scrolling. How will your patch affect me?

And, BTW, shouldn't you also add scroll-(up|down)-command to the list
around cua-base.el:1494?

    Juanma

Re: Scrolling commands

[Juri Linkov]

>> This scrolling behavior is now implemented by the patch below
>> based on `cua-scroll-up' and `cua-scroll-down'.
>
>> +(define-key global-map [prior]         'scroll-down-command)
>> +(define-key global-map [next]          'scroll-up-command)
>
> I'm currently using CUA-mode, but I do
>
>   (define-key cua-global-keymap [remap scroll-up] nil)
>   (define-key cua-global-keymap [remap scroll-down] nil)
>
> because I don't want CUA-style scrolling. How will your patch affect me?

Yes, you now have to do:

  (define-key cua-global-keymap [remap scroll-up-command]   'scroll-up)
  (define-key cua-global-keymap [remap scroll-down-command] 'scroll-down)

Maybe with a new customizable variable this would be easier to do?

> And, BTW, shouldn't you also add scroll-(up|down)-command to the list
> around cua-base.el:1494?

Yes,

=== modified file 'lisp/emulation/cua-base.el'
--- lisp/emulation/cua-base.el	2010-01-13 08:35:10 +0000
+++ lisp/emulation/cua-base.el	2010-03-31 15:04:43 +0000
@@ -1440,6 +1440,8 @@ (defun cua--init-keymaps ()
   ;; scrolling
   (define-key cua-global-keymap [remap scroll-up]	'cua-scroll-up)
   (define-key cua-global-keymap [remap scroll-down]	'cua-scroll-down)
+  (define-key cua-global-keymap [remap scroll-up-command]   'cua-scroll-up)
+  (define-key cua-global-keymap [remap scroll-down-command] 'cua-scroll-down)
 
   (define-key cua--cua-keys-keymap [(control x) timeout] 'kill-region)
   (define-key cua--cua-keys-keymap [(control c) timeout] 'copy-region-as-kill)
@@ -1499,6 +1501,7 @@ (dolist (cmd
    move-end-of-line move-beginning-of-line
    end-of-buffer beginning-of-buffer
    scroll-up scroll-down
+   scroll-up-command scroll-down-command
    up-list down-list backward-up-list
    end-of-defun beginning-of-defun
    forward-sexp backward-sexp

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

Re: Scrolling commands

[Juanma Barranquero]

On Wed, Mar 31, 2010 at 17:07, Juri Linkov <juri@jurta.org> wrote:

> Yes, you now have to do:
>
>  (define-key cua-global-keymap [remap scroll-up-command]   'scroll-up)
>  (define-key cua-global-keymap [remap scroll-down-command] 'scroll-down)

Of course, silly me. Thanks.

> Maybe with a new customizable variable this would be easier to do?

No, I bet my use of CUA-but-not-CUA-scrolling isn't common enough to
merit an option.

    Juanma

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> delete-selection-mode would be the default too, that's what everything
>>> on the desktop does...
>
> I agree with Richard that the primary concern is doing what is useful
> for newcomers.  One of the most frequent questions they ask is how to do
> what most other editors do - to replace selected text with a typed
> character or with yanked text, and to delete the region by typing <delete>
> without copying it to the kill-ring.
>
> What they are asking for is delete-selection-mode,
> but they can't find it in the documentation because
> the feature name says nothing to beginners, and
> they expect to take this functionality for granted.
>
> Some recent examples of such problems:
>
> http://thread.gmane.org/gmane.emacs.help/60992
> http://thread.gmane.org/gmane.emacs.help/45623
> http://thread.gmane.org/gmane.emacs.help/42402
>
> Is that reason enough to enable delete-selection-mode by default?

Since it interferes with Emacs-typical editing command sequences, my
vote is "no".

The question you appear concerned with is more "how can we make
beginners shut up" rather than "how can we make beginners more
productive with Emacs".

Perhaps we should offer a submenu in "Help" about "Judicious differences
to other editors", with rationales, an introducting section saying "Some
default behaviors we considered useful enough to make them different
from other editors, so we recommend that you try to get acquainted with
the suggested mode of operation before deciding against it", maybe even
with clickable links to customize-variable where you can turn some
feature like delete-selection-mode on (and off again!).

We could even go as far as to mark some customizable variables as
"voteable" and have a mechanism where you can send all of your personal
voteable settings to emacs-votes@gnu.org.

-- 
David Kastrup

AW: delete-selection-mode

[Berndl, Klaus]

Since Emacs editing interferes with typical editing commands today my vote is "yes".

Of course this is a little bit provoking, so please do not feel offened!

But IMHO the following is fact: Today Emacs has very strong competitors concerning "what is the most effective way to code my programs" - a lot of (commercial or free or open source) so called IDEs have adopted some of the pure editing power of Emacs but offer on top some power Emacs still lacks today, as for example real, fast and powerful refactoring, code navigation and other goodies you need much more for effective Code-development than some certain Emacs-specials. Well, with integrating CEDET Emacs has began to go the right direction but far away from the goal. Fact is, a lot of people which do not develop for open source but are employee at IT-companies develop with commercial IDEs cause of the advantages above. But this is not the only reason: Currently there are some quite standards concerning look and feel and also interaction with an editor/IDE. If these standard are the best approaches is not the question, we have simply to accept that there are these standards people expect when working with text-editing. And dealing with selections is one of these standards and it make NO sense to fight against it. IMHO Emacs must drop the inhibition  threshold a lot of people still have to engage in Emacs. But for these Emacs must go out from its corner especially concerning fundamental and basic interactions of the user with its tool. many many user wants to go well known paths here. If this inhibition  threshold falls then Emacs newbies would be more willing to dig into Emacs and to explore the delicacies and "unique selling points" Emacs can offer compared with other IDEs...

Take a look at gimp, one of the most successfull open source piece of code (well, a really big piece ;-): Gimp's success grows a.a. because gimp offers that the user can owrk with gimp in the quite same way as with photoshop - whereas the latter one is a defacto-standard in image editing. next gimp 2.8. will offer a single-window mode simply because people expect it!

Emacs should offer what people want and expect if it wants to have the chance to competite with other powerful IDEs.

To make a long story short: Emacs is a great peace of software and i like it very much (otherwise i would not have developed ECB). And it has really earned the chance to "win" more users, also from the "other side"... Fot this the default setting of Emacs should follow the defacto standards. And all Emacs old-timers should have an easy way to go back to the Emacs-mode to interact with their editor...maybe Emacs could display an hint for new users that there are more - and maybe even better ways - to interact with Emacs - and how to deal with that but the default should be the standard - not the Emacs standard but the "world" standards.

best regards
Klaus
________________________________________
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] im Auftrag von David Kastrup [dak@gnu.org]
Gesendet: Mittwoch, 17. März 2010 11:12
An: emacs-devel@gnu.org
Betreff: Re: delete-selection-mode

Juri Linkov <juri@jurta.org> writes:

>>> delete-selection-mode would be the default too, that's what everything
>>> on the desktop does...
>
> I agree with Richard that the primary concern is doing what is useful
> for newcomers.  One of the most frequent questions they ask is how to do
> what most other editors do - to replace selected text with a typed
> character or with yanked text, and to delete the region by typing <delete>
> without copying it to the kill-ring.
>
> What they are asking for is delete-selection-mode,
> but they can't find it in the documentation because
> the feature name says nothing to beginners, and
> they expect to take this functionality for granted.
>
> Some recent examples of such problems:
>
> http://thread.gmane.org/gmane.emacs.help/60992
> http://thread.gmane.org/gmane.emacs.help/45623
> http://thread.gmane.org/gmane.emacs.help/42402
>
> Is that reason enough to enable delete-selection-mode by default?

Since it interferes with Emacs-typical editing command sequences, my
vote is "no".

The question you appear concerned with is more "how can we make
beginners shut up" rather than "how can we make beginners more
productive with Emacs".

Perhaps we should offer a submenu in "Help" about "Judicious differences
to other editors", with rationales, an introducting section saying "Some
default behaviors we considered useful enough to make them different
from other editors, so we recommend that you try to get acquainted with
the suggested mode of operation before deciding against it", maybe even
with clickable links to customize-variable where you can turn some
feature like delete-selection-mode on (and off again!).

We could even go as far as to mark some customizable variables as
"voteable" and have a mechanism where you can send all of your personal
voteable settings to emacs-votes@gnu.org.

--
David Kastrup

Re: AW: delete-selection-mode

[Andreas Roehler]

Berndl, Klaus wrote:
> Since Emacs editing interferes with typical editing commands today my vote is "yes".
> 
> Of course this is a little bit provoking, so please do not feel offened!
> 
> But IMHO the following is fact: Today Emacs has very strong competitors concerning "what is the most effective way to code my programs" - a lot of (commercial or free or open source) so called IDEs have adopted some of the pure editing power of Emacs but offer on top some power Emacs still lacks today, as for example real, fast and powerful refactoring, code navigation and other goodies you need much more for effective Code-development than some certain Emacs-specials. Well, with integrating CEDET Emacs has began to go the right direction but far away from the goal. Fact is, a lot of people which do not develop for open source but are employee at IT-companies develop with commercial IDEs cause of the advantages above. But this is not the only reason: Currently there are some quite standa
 rds concerning look and feel and also interaction with an editor/IDE. If these standard are the best approaches is not the question, we have simply to accept that there are these standards p
eople expect when working with text-editing. And dealing with selections is one of these standards and it make NO sense to fight against it. IMHO Emacs must drop the inhibition  threshold a lot of people still have to engage in Emacs. But for these Emacs must go out from its corner especially concerning fundamental and basic interactions of the user with its tool. many many user wants to go well known paths here. If this inhibition  threshold falls then Emacs newbies would be more willing to dig into Emacs and to explore the delicacies and "unique selling points" Emacs can offer compared with other IDEs...
> 
> Take a look at gimp, one of the most successfull open source piece of code (well, a really big piece ;-): Gimp's success grows a.a. because gimp offers that the user can owrk with gimp in the quite same way as with photoshop - whereas the latter one is a defacto-standard in image editing. next gimp 2.8. will offer a single-window mode simply because people expect it!
> 
> Emacs should offer what people want and expect if it wants to have the chance to competite with other powerful IDEs.
> 
> To make a long story short: Emacs is a great peace of software and i like it very much (otherwise i would not have developed ECB). And it has really earned the chance to "win" more users, also from the "other side"... Fot this the default setting of Emacs should follow the defacto standards. And all Emacs old-timers should have an easy way to go back to the Emacs-mode to interact with their editor...maybe Emacs could display an hint for new users that there are more - and maybe even better ways - to interact with Emacs - and how to deal with that but the default should be the standard - not the Emacs standard but the "world" standards.
> 
> best regards
> Klaus
> ________________________________________

Hi Klaus,

thanks for this comprehensive statement.

Why not take occasion, telling users at the very beginning about the difference between
Emacs and common usage, about the advantage having delsel-mode off.

People who are not interested in this kind of reflections don't need Emacs.
The other may notice just here, they are right.

Would introduce this item right into the first tutorial.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/

AW: AW: delete-selection-mode

[Berndl, Klaus]

>Why not take occasion, telling users at the very beginning about the difference between
>Emacs and common usage, about the advantage having delsel-mode off.
>People who are not interested in this kind of reflections don't need Emacs.

I completely disagree here - If people need emacs, i.e. if they can take (more or less great) advantages from using Emacs (or switching to Emacs) depends not if they are willing to adopt the emacs-way-of-live or with other words: ...depends not if they are willing to throw away their well known and liked ways of basic(!) interaction with a text-writing-tool. The advantages of Emacs are not its sometimes just special but also sometimes really cryptic ways of basic and fundamental text-editing but:
- very powerful text-based directory- and file-handling as offered by dired
- very powerful integration of (recursive) greps
- in general: the possibilities to handle text-based documents in quite any imaginable way
- the way do deal with a lot of programing languages always in the same way (one editor/environment for all languages)
- some others

IMHO this has nothing to do with these basics how to deal with selections... Why to scare Emacs-newbies with these standards-interfering Emacs-approaches and therefore preventing potential new users from becoming acquainted with these very USP-features i mentioned above...These features above would convince new users that Emacs could be really more powerful than other editors not another way to deal with selections...

Therefore my vote for the standards as defaults...

Best regards
Klaus

>The other may notice just here, they are right

________________________________________
Von: Andreas Roehler [andreas.roehler@online.de]
Gesendet: Mittwoch, 17. März 2010 13:41
An: Berndl, Klaus
Cc: emacs-devel@gnu.org
Betreff: Re: AW: delete-selection-mode

Berndl, Klaus wrote:
> Since Emacs editing interferes with typical editing commands today my vote is "yes".
>
> Of course this is a little bit provoking, so please do not feel offened!
>
> But IMHO the following is fact: Today Emacs has very strong competitors concerning "what is the most effective way to code my programs" - a lot of (commercial or free or open source) so called IDEs have adopted some of the pure editing power of Emacs but offer on top some power Emacs still lacks today, as for example real, fast and powerful refactoring, code navigation and other goodies you need much more for effective Code-development than some certain Emacs-specials. Well, with integrating CEDET Emacs has began to go the right direction but far away from the goal. Fact is, a lot of people which do not develop for open source but are employee at IT-companies develop with commercial IDEs cause of the advantages above. But this is not the only reason: Currently there are some quite standards concerning look and feel and also interaction with an editor/IDE. If these standard are the best approaches is not the question, we have simply to accept that there are these standards p
eople expect when working with text-editing. And dealing with selections is one of these standards and it make NO sense to fight against it. IMHO Emacs must drop the inhibition  threshold a lot of people still have to engage in Emacs. But for these Emacs must go out from its corner especially concerning fundamental and basic interactions of the user with its tool. many many user wants to go well known paths here. If this inhibition  threshold falls then Emacs newbies would be more willing to dig into Emacs and to explore the delicacies and "unique selling points" Emacs can offer compared with other IDEs...
>
> Take a look at gimp, one of the most successfull open source piece of code (well, a really big piece ;-): Gimp's success grows a.a. because gimp offers that the user can owrk with gimp in the quite same way as with photoshop - whereas the latter one is a defacto-standard in image editing. next gimp 2.8. will offer a single-window mode simply because people expect it!
>
> Emacs should offer what people want and expect if it wants to have the chance to competite with other powerful IDEs.
>
> To make a long story short: Emacs is a great peace of software and i like it very much (otherwise i would not have developed ECB). And it has really earned the chance to "win" more users, also from the "other side"... Fot this the default setting of Emacs should follow the defacto standards. And all Emacs old-timers should have an easy way to go back to the Emacs-mode to interact with their editor...maybe Emacs could display an hint for new users that there are more - and maybe even better ways - to interact with Emacs - and how to deal with that but the default should be the standard - not the Emacs standard but the "world" standards.
>
> best regards
> Klaus
> ________________________________________

Hi Klaus,

thanks for this comprehensive statement.

Why not take occasion, telling users at the very beginning about the difference between
Emacs and common usage, about the advantage having delsel-mode off.

People who are not interested in this kind of reflections don't need Emacs.
The other may notice just here, they are right.

Would introduce this item right into the first tutorial.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/

RE: AW: delete-selection-mode

[Drew Adams]

> telling users ... about the advantage having delsel-mode off.

There is none.

Re: AW: delete-selection-mode

[David Kastrup]

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

>> telling users ... about the advantage having delsel-mode off.
>
> There is none.

You can set the mark, move somewhere else, type stuff there, and return
using C-x C-x, again typing stuff there, without destroying anything you
have written.

The mark is, well, a _mark_.  Something you can set temporarily easily,
later to return.

There is no other mechanism, even half as straightforward and easy to
use, for doing that kind of thing.

Your polemics are just showing that you have chosen to willfully ignore
the others' position and the respective advantages they see in the
current defaults.  Is your position so weak that you have to resort to
such tactics?

-- 
David Kastrup

Re: AW: delete-selection-mode

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>> telling users ... about the advantage having delsel-mode off.
>>
>> There is none.
>
> You can set the mark, move somewhere else, type stuff there, and return
> using C-x C-x, again typing stuff there, without destroying anything you
> have written.
>
> The mark is, well, a _mark_.  Something you can set temporarily easily,
> later to return.
>
> There is no other mechanism, even half as straightforward and easy to
> use, for doing that kind of thing.
>
> Your polemics are just showing that you have chosen to willfully ignore
> the others' position and the respective advantages they see in the
> current defaults.  Is your position so weak that you have to resort to
> such tactics?

Anyway, here is some suggestion that might better satisfy you without
sacrificing behavior for others: we already distinguish between
transient regions marked with the mouse and with keyboard, namely with:

mouse-region-delete-keys is a variable defined in `mouse.el'.
Its value is 
([delete]
 [deletechar]
 [backspace])


Documentation:
List of keys that should cause the mouse region to be deleted.

You can customize this variable.

[back]

If this variable would be made to accept keybindings in addition to
keys, one could add self-insert-command to this list.  In that manner,
the normal self-inserting characters would delete a region marked with
the mouse, but not marked with keyboard commands.

I am not sure that distinguishing mouse regions at all is a useful
thing, but while one does that, one could make use of it to silence the
I-want-things-just-like-with-Notepad crowd some more.

-- 
David Kastrup

RE: AW: delete-selection-mode

[Drew Adams]

> the I-want-things-just-like-with-Notepad crowd

Emacs with delete-selection-mode turned on is a beautiful thing. It's the way
Emacs was meant to be by the Great GNU in the Sky. (And no, it does not make
Emacs like Notepad - that's a shiny red herring, if not a boogeyman.)

FYI, I too used Emacs without delete-selection-mode, for years and years. I used
it without a mouse for years and years. And without a menu. And without
faces...and frames... I know all about the Emacs region and mark; thank you.

I suspect (no proof) that most of those who decry delete-selection-mode also do
not use transient-mark-mode. The latter is now the default in Emacs (no thanks
to the Great-Wall-I-dont-want-Emacs-to-adopt-and-adapt crowd).

If one uses transient-mark-mode, IMHO it also makes sense to use
delete-selection-mode. That's really the heart of the question regarding the
default, I believe.

I'd even suggest that if any new light is to be shed onto this thread it will
come from arguments about using transient-mark-mode *without* delsel. The rest
is rehash (and even some of that more narrow focus might be rehash - we'll see).

To put it mildly, folks who do not even use transient-mark-mode or delsel mode,
or at least those who have little experience with them, are perhaps not the best
placed to offer advice on whether delsel would add something to t-m-mode as the
default behavior.

And no, we should not reconsider t-m-mode's status as the default - c'est un
droit acquis ;-). Please, let's not hear the same old arguments that were put
forth to prevent t-m-mode's acceptance as the default (and that's what we've
heard from you, so far, no?). It took us years to settle that question. The Wall
finally crumbled; the anti-t-m-mode crowd lost that battle. Just get over it.
Emacs newbies now get t-m-mode by default. Hoorah.

Let's hear instead from those who use transient-mark-mode *without*
delete-selection-mode (intentionally, not just by default or from ignorance of
delsel). Let us know why t-m-mode without d-s-mode is the right choice as a
default for Emacs.

That could be an interesting discussion. And it alone is really pertinent to the
question at hand.

We should not be contrasting Emacs without t-m-mode to Emacs with delsel mode.
We should be contrasting Emacs with only t-m-mode to Emacs with delsel mode
(which includes t-m-mode). Anything else is noise and obfuscation at this point.

Re: AW: delete-selection-mode

[David Kastrup]

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

>> the I-want-things-just-like-with-Notepad crowd
>
> Emacs with delete-selection-mode turned on is a beautiful thing. It's
> the way Emacs was meant to be by the Great GNU in the Sky. (And no, it
> does not make Emacs like Notepad - that's a shiny red herring, if not
> a boogeyman.)

[Paragraphs of wild rambling elided]

> Let's hear instead from those who use transient-mark-mode *without*
> delete-selection-mode (intentionally, not just by default or from
> ignorance of delsel). Let us know why t-m-mode without d-s-mode is the
> right choice as a default for Emacs.
>
> That could be an interesting discussion.

Since I already gave examples and explained, it is obvious that you
refuse to actually _listen_ to others in this "interesting discussion".

And if it were not bad enough that you don't listen to others _at_
_all_, your monologues do not even contain coherent arguments, but are
just an enumeration of unsupported statements, propaganda and wild
ramblings.

Not only do you _ignore_ the others in the discussion, you do not
contribute anything substantial enough to be actually worth considering.

-- 
David Kastrup

Re: AW: delete-selection-mode

[Stefan Monnier]

> Since I already gave examples and explained, it is obvious that you
> refuse to actually _listen_ to others in this "interesting discussion".

I for one haven't seen any such example.  The only "example" I've seen
was:

> You can set the mark, move somewhere else, type stuff there, and return
> using C-x C-x, again typing stuff there, without destroying anything you
> have written.

But this lacks crucial info about transient-mark-mode: if you don't have
transient-mark-mode enabled, the above example will not be affected by
delsel or any of its siblings.  OTOH if you do have t-m-m enabled, then
you'll probably want to use C-u C-x C-x rather than C-x C-x and also use
C-SPC C-SPC (so as not to activate the mark, to avoid spuriously
highlighting the region while you're moving around), in which case again
delsel will have no impact.

Have you actually tried delete-selection-mode?

I haven't tried delete-selection-mode itself, but I've used
cua-selection-mode for a while, and other than very minor problems (due
to subtle differences of behavior, specific to the cua-* code, which
would clearly need to be ironed out before enabling such a feature),
I was not bothered by it at all.  I did not use its features very much
either, to tell you the truth, but that's beside the point.


        Stefan

Re: AW: delete-selection-mode

[Chong Yidong]

I use delete-selection mode, but mainly for one reason: I want DEL to
delete the region when it's active.

This argument

>> You can set the mark, move somewhere else, type stuff there, and return
>> using C-x C-x, again typing stuff there, without destroying anything you
>> have written.

sounds reasonable, since it's not a priori obvious (apart from the
behavior of other applications) that self-inserting characters should
"operate on the region".  That's why I am not sure about making
delete-selection-mode the default.

However, I do feel that the "DEL acts on the region" part of
delete-selection-mode is strongly intuitive.

Re: AW: delete-selection-mode

[Lennart Borgman]

On Thu, Mar 18, 2010 at 12:01 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> I use delete-selection mode, but mainly for one reason: I want DEL to
> delete the region when it's active.
>
> This argument
>
>>> You can set the mark, move somewhere else, type stuff there, and return
>>> using C-x C-x, again typing stuff there, without destroying anything you
>>> have written.
>
> sounds reasonable, since it's not a priori obvious (apart from the
> behavior of other applications) that self-inserting characters should
> "operate on the region".  That's why I am not sure about making
> delete-selection-mode the default.

In technical questions, can there really be any intuition apart from
that built by experience?

> However, I do feel that the "DEL acts on the region" part of
> delete-selection-mode is strongly intuitive.

Re: AW: delete-selection-mode

[Stefan Monnier]

> I use delete-selection mode, but mainly for one reason: I want DEL to
> delete the region when it's active.

How 'bout this:

Generalize the feature we already have under mouse-region-delete-keys to
apply to the region regardless whether it was activated by the mouse
or not.

This will be a good occasion to get rid of the butt-ugly and
bug-inducing code that implements the feature now.  And it will provide
the DEL part of delete-selection-mode.

I'd be happy to also provide the self-insert behavior of
delete-selection-mode, but at least this intermediate step sounds very
good to me.

The implementation should keep an eye towards generalizing it to
self-insertion keys (i.e. maybe it should just use the code from
delete-selection-mode).


        Stefan

Re: AW: delete-selection-mode

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> This will be a good occasion to get rid of the butt-ugly and
> bug-inducing code that implements the feature now.  And it will provide
> the DEL part of delete-selection-mode.
>
> I'd be happy to also provide the self-insert behavior of
> delete-selection-mode, but at least this intermediate step sounds very
> good to me.
>
> The implementation should keep an eye towards generalizing it to
> self-insertion keys (i.e. maybe it should just use the code from
> delete-selection-mode).

That all sounds perfect.

The "DEL deletes" functionality seems the main thing; a mode which only
did that would probably be fine, and solve 95% of the muscle-memory-
from-other-apps issues.

-Miles

-- 
Liberty, n. One of imagination's most precious possessions.

RE: AW: delete-selection-mode

[Drew Adams]

> > This will be a good occasion to get rid of the butt-ugly and
> > bug-inducing code that implements the feature now.  And it 
> > will provide the DEL part of delete-selection-mode.
> >
> > I'd be happy to also provide the self-insert behavior of
> > delete-selection-mode, but at least this intermediate step 
> > sounds very good to me.
> >
> > The implementation should keep an eye towards generalizing it to
> > self-insertion keys (i.e. maybe it should just use the code from
> > delete-selection-mode).
> 
> That all sounds perfect.
> 
> The "DEL deletes" functionality seems the main thing; a mode 
> which only did that would probably be fine, and solve 95% of
> the muscle-memory-from-other-apps issues.

Why? How will that help users who expect the usual type-to-replace behavior?

What's so special about DEL?  IIUC, your proposal essentially binds DEL to
`delete-region' when the region is active.

I disagree that DEL amounts to 95%, or even 5%, of the use of an active region
in other apps. DEL is simply one minor, special case of type-to-replace. Most of
the time, users of other apps select text to replace it - THAT's the 95% or more
case.

Your proposal is a miniscule improvement, one baby step on the road to the
d-s-mode behavior that newbies expect (and many oldbies prefer). What's the
point of such a watered-down compromise?

An active region should be active, including in the sense that most people
expect: type-to-replace.

If someone doesn't want the region to be active, there are trivial remedies:
turn it off either temporarily (C-g) or permanently (turn off t-m-mode).

Re: AW: delete-selection-mode

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> The "DEL deletes" functionality seems the main thing; a mode 
>> which only did that would probably be fine, and solve 95% of
>> the muscle-memory-from-other-apps issues.
>
> Why? How will that help users who expect the usual type-to-replace behavior?

It won't, but based on what I've seen, I think that people who actually
"type to delete", instead of hitting DEL first and _then_ typing the new
text, are a minority.

[Note that this observation doesn't apply to specialized input fields
like browser address boxes -- they're set up so that "type to delete" is
the usual action -- but they're a very specialized and unusual context,
and should not be treated like standard text buffers.]

[Just to be clear, "DEL" means the `delete-backward-char' key.]

> What's so special about DEL?  IIUC, your proposal essentially binds DEL to
> `delete-region' when the region is active.

Yes, and that's _good_.  It's simple, straight-forward, and has the good
points without the bad points.

The goal is _not_ to turn Emacs into windows, it's to help people with
windows-influenced muscle-memory a bit, when doing so is not harmful.

Clearly there are many controversial issues in this area, so we should
pick off the low-hanging fruit first.

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

Re: AW: delete-selection-mode

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

>> What's so special about DEL?  IIUC, your proposal essentially binds DEL to
>> `delete-region' when the region is active.
>
> Yes, and that's _good_.  It's simple, straight-forward, and has the good
> points without the bad points.
>
> The goal is _not_ to turn Emacs into windows, it's to help people with
> windows-influenced muscle-memory a bit, when doing so is not harmful.

More importantly, it's consistent with the existing semantics of
transient mark mode.  Many Emacs commands act on the region when it's
active, and it seems natural for DEL to be one of these commands.

By contrast, it's not clear to me that self-inserting characters ought
to "act on the region" in the sense of replacing its contents.

Re: AW: delete-selection-mode

[Juri Linkov]

> More importantly, it's consistent with the existing semantics of
> transient mark mode.  Many Emacs commands act on the region when it's
> active, and it seems natural for DEL to be one of these commands.
>
> By contrast, it's not clear to me that self-inserting characters ought
> to "act on the region" in the sense of replacing its contents.

As I understand from counter-arguments, opponents agree with
self-inserting characters replacing the region, but only when
the region is activated explicitly, and not by side-effects of
setting the mark or exchanging the mark and point.

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

Re: AW: delete-selection-mode

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> More importantly, it's consistent with the existing semantics of
>> transient mark mode.  Many Emacs commands act on the region when it's
>> active, and it seems natural for DEL to be one of these commands.
>>
>> By contrast, it's not clear to me that self-inserting characters ought
>> to "act on the region" in the sense of replacing its contents.
>
> As I understand from counter-arguments, opponents agree with
> self-inserting characters replacing the region, but only when
> the region is activated explicitly, and not by side-effects of
> setting the mark or exchanging the mark and point.

I think having magically different types of active region (which look
the same, but act differently) is very confusing, and we should not be
adding more such behavior (I understand the mouse currently has wacky
behavior like this, but That's Bad).

If the region is active, it should act active, regardless of how you got
there.

-Miles

-- 
Inhumanity, n. One of the signal and characteristic qualities of humanity.

RE: AW: delete-selection-mode

[Drew Adams]

> > As I understand from counter-arguments, opponents agree with
> > self-inserting characters replacing the region, but only when
> > the region is activated explicitly, and not by side-effects of
> > setting the mark or exchanging the mark and point.
> 
> I think having magically different types of active region (which look
> the same, but act differently) is very confusing, and we should not be
> adding more such behavior (I understand the mouse currently has wacky
> behavior like this, but That's Bad).

I agree 100%.

> If the region is active, it should act active, regardless of 
> how you got there.

Absolutely.

RE: AW: delete-selection-mode

[Drew Adams]

> > More importantly, it's consistent with the existing semantics of
> > transient mark mode.  Many Emacs commands act on the region 
> > when it's active, and it seems natural for DEL to be one of
> > these commands.
> >
> > By contrast, it's not clear to me that self-inserting 
> > characters ought to "act on the region" in the sense of
> > replacing its contents.
> 
> As I understand from counter-arguments, opponents agree with
> self-inserting characters replacing the region, but only when
> the region is activated explicitly, and not by side-effects of
> setting the mark or exchanging the mark and point.

Not this "opponent". I agree with self-inserting characters replacing the active
region _always_, no matter how it was activated. That's the point of "active".

And I hold that the region should be activated simply by setting the mark or
exchanging the mark and point.

IOW, I disagree (strongly) with changing the behavior of d-s-mode. If you don't
want to make d-s-mode the default, so be it. But please don't mess with
d-s-mode.

Re: AW: delete-selection-mode

[Juri Linkov]

>> As I understand from counter-arguments, opponents agree with
>> self-inserting characters replacing the region, but only when
>> the region is activated explicitly, and not by side-effects of
>> setting the mark or exchanging the mark and point.
>
> Not this "opponent". I agree with self-inserting characters replacing
> the active region _always_, no matter how it was activated. That's the
> point of "active".
>
> And I hold that the region should be activated simply by setting the mark or
> exchanging the mark and point.

That's my position too.  This problem is mostly irrelevant to enabling d-s-m.
Everyone who don't like C-SPC or C-x C-x activating the region can turn off
t-m-m or use additional C-u/C-g.

IOW, t-m-m should go hand in hand with d-s-m.  And turning off t-m-m
should also turn off d-s-m.

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

RE: AW: delete-selection-mode

[Drew Adams]

> >> As I understand from counter-arguments, opponents agree with
> >> self-inserting characters replacing the region, but only when
> >> the region is activated explicitly, and not by side-effects of
> >> setting the mark or exchanging the mark and point.
> >
> > Not this "opponent". I agree with self-inserting characters 
> > replacing the active region _always_, no matter how it was
> > activated. That's the point of "active".
> >
> > And I hold that the region should be activated simply by 
> > setting the mark or exchanging the mark and point.
> 
> That's my position too.  This problem is mostly irrelevant to 
> enabling d-s-m. Everyone who don't like C-SPC or C-x C-x
> activating the region can turn off t-m-m or use additional C-u/C-g.
> 
> IOW, t-m-m should go hand in hand with d-s-m.  And turning off t-m-m
> should also turn off d-s-m.

We agree.

Re: AW: delete-selection-mode

[David Kastrup]

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

>> > More importantly, it's consistent with the existing semantics of
>> > transient mark mode.  Many Emacs commands act on the region 
>> > when it's active, and it seems natural for DEL to be one of
>> > these commands.
>> >
>> > By contrast, it's not clear to me that self-inserting 
>> > characters ought to "act on the region" in the sense of
>> > replacing its contents.
>> 
>> As I understand from counter-arguments, opponents agree with
>> self-inserting characters replacing the region, but only when
>> the region is activated explicitly, and not by side-effects of
>> setting the mark or exchanging the mark and point.
>
> Not this "opponent". I agree with self-inserting characters replacing
> the active region _always_, no matter how it was activated. That's the
> point of "active".

> And I hold that the region should be activated simply by setting the
> mark or exchanging the mark and point.

With delete-selection-mode, commands like push-mark and pop-mark get
side effects that tend to destroy text every time.

-- 
David Kastrup

RE: AW: delete-selection-mode

[Drew Adams]

> > I agree with self-inserting characters replacing
> > the active region _always_, no matter how it was activated. 
> > That's the point of "active".
> 
> > And I hold that the region should be activated simply by setting the
> > mark or exchanging the mark and point.
> 
> With delete-selection-mode, commands like push-mark and pop-mark get
> side effects that tend to destroy text every time.

Care to elaborate?

I use both `push-mark' and `pop-mark' all day long, and I've never had any text
destroyed by either of them.

RE: AW: delete-selection-mode

[Drew Adams]

> >> The "DEL deletes" functionality seems the main thing; a mode 
> >> which only did that would probably be fine, and solve 95% of
> >> the muscle-memory-from-other-apps issues.
> >
> > Why? How will that help users who expect the usual 
> > type-to-replace behavior?
> 
> It won't, but based on what I've seen, I think that people 
> who actually "type to delete", instead of hitting DEL first and _then_ 
> typing the new text, are a minority.

Not based on what I've seen. (And not based on what I do.)

The typical way I see people replace text is to (a) select it by dragging the
mouse over it and then (b) type the replacement text.
 
> The goal is _not_ to turn Emacs into windows,

Windows? WINDOWS? That bugbear again?

99% of the applications out there, on 99% of the computers (on 100% of the
platforms?) have this behavior. (No, I don't have proof of the percentages.)

Your fear of the Windows bogeyman is apparently making you blind to the much
larger reality. Perhaps you live 100% inside Emacs, but many people do not
(including many hard-core Emacs users).

> Clearly there are many controversial issues in this area, so we should
> pick off the low-hanging fruit first.

You see controversy where most people see de facto standard behavior (and useful
behavior, at that). Bill Gates is behind the evil select-and-type-to-replace
virus!

Re: AW: delete-selection-mode

[Stefan Monnier]

> If we do anything short of what people expect, we are going to have this
> discussion again.

We will always have those discussions.  They're normal and expected.


        Stefan

Re: AW: delete-selection-mode

[Chong Yidong]

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

> How 'bout this:
>
> Generalize the feature we already have under mouse-region-delete-keys to
> apply to the region regardless whether it was activated by the mouse
> or not.
>
> This will be a good occasion to get rid of the butt-ugly and
> bug-inducing code that implements the feature now.  And it will provide
> the DEL part of delete-selection-mode.

That would be fine.  Call it `region-delete-keys'?  Should we keep
`region-delete-keys' around still?

Re: AW: delete-selection-mode

[Stefan Monnier]

>> How 'bout this:
>> 
>> Generalize the feature we already have under mouse-region-delete-keys to
>> apply to the region regardless whether it was activated by the mouse
>> or not.
>> 
>> This will be a good occasion to get rid of the butt-ugly and
>> bug-inducing code that implements the feature now.  And it will provide
>> the DEL part of delete-selection-mode.
> That would be fine.  Call it `region-delete-keys'?

No idea.  Maybe we want to "bind" it to commands rather than to keys
(IIRC delete-selection-mode binds it to commands).  Maybe we want to
implement it along the same lines as what we did for shift-selection by
adding something in the `interactive' form of the commands.

> Should we keep `region-delete-keys' around still?

You mean `mouse-region-delete-keys'?  I wouldn't waste too much time
trying to preserve compatibility with user customization of
this variable, no.


        Stefan

Re: AW: delete-selection-mode

[David Kastrup]

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

>> Since I already gave examples and explained, it is obvious that you
>> refuse to actually _listen_ to others in this "interesting discussion".
>
> I for one haven't seen any such example.  The only "example" I've seen
> was:
>
>> You can set the mark, move somewhere else, type stuff there, and return
>> using C-x C-x, again typing stuff there, without destroying anything you
>> have written.
>
> But this lacks crucial info about transient-mark-mode: if you don't have
> transient-mark-mode enabled, the above example will not be affected by
> delsel or any of its siblings.

    delete-selection-mode is an interactive autoloaded Lisp function in
    `delsel.el'.

    When Delete Selection mode is enabled, Transient Mark mode is also
    enabled

-- 
David Kastrup

Re: AW: delete-selection-mode

[Stefan Monnier]

>> But this lacks crucial info about transient-mark-mode: if you don't have
>> transient-mark-mode enabled, the above example will not be affected by
>> delsel or any of its siblings.

>     delete-selection-mode is an interactive autoloaded Lisp function in
>     `delsel.el'.
>     When Delete Selection mode is enabled, Transient Mark mode is also
>     enabled

I think you stopped reading a bit too early, I went on to explain that
when t-m-m is enabled, delsel still doesn't make any significant
difference:

   OTOH if you do have t-m-m enabled, then you'll probably want to use
   C-u C-x C-x rather than C-x C-x and also use C-SPC C-SPC (so as not
   to activate the mark, to avoid spuriously highlighting the region
   while you're moving around), in which case again delsel will have
   no impact.


-- Stefan

Re: AW: delete-selection-mode

[David Kastrup]

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

>>> But this lacks crucial info about transient-mark-mode: if you don't have
>>> transient-mark-mode enabled, the above example will not be affected by
>>> delsel or any of its siblings.
>
>>     delete-selection-mode is an interactive autoloaded Lisp function in
>>     `delsel.el'.
>>     When Delete Selection mode is enabled, Transient Mark mode is also
>>     enabled
>
> I think you stopped reading a bit too early, I went on to explain that
> when t-m-m is enabled, delsel still doesn't make any significant
> difference:
>
>    OTOH if you do have t-m-m enabled, then you'll probably want to use
>    C-u C-x C-x rather than C-x C-x and also use C-SPC C-SPC (so as not
>    to activate the mark, to avoid spuriously highlighting the region
>    while you're moving around), in which case again delsel will have
>    no impact.

The additional brain-power needed for avoiding the highlighting is not
something I invest.

That was different while t-m-m was not the default: in this case, you
_needed_ it when switching on, and so that additional work was invested
for a purpose.  Merely avoiding the highlighting is no comparable
incentive: that's just being anal.  And between me and the computer, I
tend to leave that to the computer.

-- 
David Kastrup

RE: AW: delete-selection-mode

[Drew Adams]

> From: David Kastrup

[rabid foaming at the mouth elided]

> > Let's hear instead from those who use transient-mark-mode *without*
> > delete-selection-mode (intentionally, not just by default or from
> > ignorance of delsel). Let us know why t-m-mode without 
> > d-s-mode is the right choice as a default for Emacs.
> > That could be an interesting discussion.
> 
> Since I already gave examples and explained

It's interesting to see you respond to that call, indicating that you now use
transient-mark-mode, albeit without delete-selection-mode. Good to hear there
has been some progress. What made you switch to t-m-mode?

But you did *not* give any examples or explanation of why t-m-mode without
d-s-mode is a better default than d-s-mode. Not in any mails I received from
you, you didn't. Please point to one such example and explanation.

Did you mean this, perhaps:

> You can set the mark, move somewhere else, type stuff there,
> and return using C-x C-x, again typing stuff there, without
> destroying anything you have written.

Again, that's just a rehash of an argument why we should *not* even have
t-m-mode as the default. Please don't try to start that off-topic battle again.

The question is, "What makes t-m-mode without d-s-mode a better default than
d-s-mode?" Show me where you give an example or argument for that.

[more frothing and foaming trimmed]

Re: AW: delete-selection-mode

[David Kastrup]

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

>> From: David Kastrup
>
> [rabid foaming at the mouth elided]
>
>> > Let's hear instead from those who use transient-mark-mode *without*
>> > delete-selection-mode (intentionally, not just by default or from
>> > ignorance of delsel). Let us know why t-m-mode without 
>> > d-s-mode is the right choice as a default for Emacs.
>> > That could be an interesting discussion.
>> 
>> Since I already gave examples and explained
>
> It's interesting to see you respond to that call, indicating that you
> now use transient-mark-mode, albeit without
> delete-selection-mode. Good to hear there has been some progress. What
> made you switch to t-m-mode?

There was no switch involved.  I stayed with the default, IIRC just like
Richard.  Using non-standard Emacsen makes it much harder to help other
people ("it doesn't do that here") and participate usefully in
discussions.

I don't believe in a culture that gives beginners a dumbed-down tool
while leaving the productivity to the people experienced enough to
recustomize Emacs to more useful behavior.

I also stayed with syntax highlighting once it became the default, and
reported (and experienced) a number of regressions (if you can call
intolerable performance for a feature not even present before a
regression) that were impacting Emacs' usability for large files.

> But you did *not* give any examples or explanation of why t-m-mode
> without d-s-mode is a better default than d-s-mode. Not in any mails I
> received from you, you didn't. Please point to one such example and
> explanation.
>
> Did you mean this, perhaps:
>
>> You can set the mark, move somewhere else, type stuff there, and
>> return using C-x C-x, again typing stuff there, without destroying
>> anything you have written.

If that was not in any mails you received from me, where did you pick it
from?

> Again, that's just a rehash of an argument why we should *not* even
> have t-m-mode as the default.

Huh?  That works fine with transient-mark-mode.

> [more frothing and foaming trimmed]

-- 
David Kastrup

Re: AW: delete-selection-mode

[Richard Stallman]

Actually I have Transient Mark mode enabled.
It is occasionally useful and does not cause inconvenience.

RE: AW: delete-selection-mode

[Drew Adams]

> >> You can set the mark, move somewhere else, type stuff there, and
> >> return using C-x C-x, again typing stuff there, without destroying
> >> anything you have written.
> 
> > Again, that's just a rehash of an argument why we should *not* even
> > have t-m-mode as the default.
> 
> Huh?  That works fine with transient-mark-mode.

Yes, it works with t-m-mode. But there is no reason to have t-m-mode or an
active region, to be able to do that. The example uses nothing about t-m-mode.
That is straight, classic behavior for a non-active region.

As Stefan pointed out, you might or might not have t-m-mode on when doing that,
but you are essentially ignoring t-m-mode and the active region in that example:

Stefan> But this lacks crucial info about transient-mark-mode:
> if you don't have transient-mark-mode enabled, the above example
> will not be affected by delsel or any of its siblings.
>
> OTOH if you do have t-m-m enabled, then you'll probably want
> to use C-u C-x C-x rather than C-x C-x and also use
> C-SPC C-SPC (so as not to activate the mark, to avoid
> spuriously highlighting the region while you're moving around),
> in which case again delsel will have no impact.

It's simple:

a. Without an active region in the sense expected by new users (e.g. with
d-s-mode off), you can do what you described without hitting any extra keys. OK,
fine.

With an active region (e.g. with d-s-mode on), you have to hit C-g to deactivate
the region, but otherwise, your same example applies equally. So: one extra
key-press.

b. OTOH, to get the usual (for most people) type-to-replace behavior with
d-s-mode off, you need to hit C-w (or `delete-region', e.g. DEL). Again: one
extra key-press.

Each approach can be said to have an advantage and a corresponding disadvantage.
You need to hit an extra key (either C-g or C-w/DEL), depending on which
approach you take and whether you want to replace the region or add text
elsewhere.

So the questions are:

1. Which action is more common: replacing selected text or adding text outside
the selection.

2. Which behavior is more expected by new users (since we're talking about the
default).

I use d-s-mode. I have no problem doing the kind of thing you describe. I
regularly use marks that way (navigationally), without being bothered in any way
by the active region.

I can always deactivate it, using C-g. But oddly enough, I find that I rarely
need to use C-g that way. Most of the time, other actions have already
deactivated the region when I need it to be inactive.

Re: delete-selection-mode

[Alan Mackenzie]

Hi, Drew!

On Wed, Mar 17, 2010 at 01:49:23PM -0700, Drew Adams wrote:
> > From: David Kastrup

> [rabid foaming at the mouth elided]

> It's interesting to see you respond to that call, indicating that you
> now use transient-mark-mode, albeit without delete-selection-mode. Good
                                                                     ^^^^
> to hear there has been some progress. What made you switch to t-m-mode?
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [more frothing and foaming trimmed]

All these excerpts from your post are likely to be interpreted as
inflammatory and derogatory.  Topics like this are heated enough as it
is.  Could we all please be careful that what we write here CANNOT be
interpreted as casting aspersions on somebody else.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Wed, Mar 17, 2010 at 01:49:23PM -0700, Drew Adams wrote:
>> > From: David Kastrup
>
>> [rabid foaming at the mouth elided]
>
>> It's interesting to see you respond to that call, indicating that you
>> now use transient-mark-mode, albeit without delete-selection-mode. Good
>                                                                      ^^^^
>> to hear there has been some progress. What made you switch to t-m-mode?
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> [more frothing and foaming trimmed]
>
> All these excerpts from your post are likely to be interpreted as
> inflammatory and derogatory.  Topics like this are heated enough as it
> is.  Could we all please be careful that what we write here CANNOT be
> interpreted as casting aspersions on somebody else.

I don't have the impression that this would be compatible with the point
(or was that the mark?) Drew is trying to make.

> Thanks!

You are welcome.

-- 
David Kastrup

Re: AW: delete-selection-mode

[Juri Linkov]

>>> telling users ... about the advantage having delsel-mode off.
>>
>> There is none.
>
> You can set the mark, move somewhere else, type stuff there, and return
> using C-x C-x, again typing stuff there, without destroying anything you
> have written.
>
> The mark is, well, a _mark_.  Something you can set temporarily easily,
> later to return.

Do you really use this with t-t-m?

There is a simple principle wrt t-t-m: when the region is active then
keys change their usual meaning.  With delete-selection-mode this
includes <delete> and other self-inserting keys in addition to
existing keys that already have a special meaning in t-m-m.

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

Re: AW: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>>> telling users ... about the advantage having delsel-mode off.
>>>
>>> There is none.
>>
>> You can set the mark, move somewhere else, type stuff there, and return
>> using C-x C-x, again typing stuff there, without destroying anything you
>> have written.
>>
>> The mark is, well, a _mark_.  Something you can set temporarily easily,
>> later to return.
>
> Do you really use this with t-t-m?
>
> There is a simple principle wrt t-t-m: when the region is active then
> keys change their usual meaning.

Those "keys" that operate on a region of text, like query-replace.
Different kettle of fish.

> With delete-selection-mode this includes <delete> and other
> self-inserting keys in addition to existing keys that already have a
> special meaning in t-m-m.

Normal text entry is affected, yes.

-- 
David Kastrup

Re: AW: delete-selection-mode

[Harald Hanche-Olsen]

+ David Kastrup <dak@gnu.org>:

> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> >> telling users ... about the advantage having delsel-mode off.
> >
> > There is none.
> 
> You can set the mark, move somewhere else, type stuff there, and return
> using C-x C-x, again typing stuff there, without destroying anything you
> have written.

You can still do that with delete-selection-mode turned on; you just
need to hit C-g to deactivate the mark before starting typing in the
new location.

- Harald

Re: AW: delete-selection-mode

[David Kastrup]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> + David Kastrup <dak@gnu.org>:
>
>> "Drew Adams" <drew.adams@oracle.com> writes:
>> 
>> >> telling users ... about the advantage having delsel-mode off.
>> >
>> > There is none.
>> 
>> You can set the mark, move somewhere else, type stuff there, and return
>> using C-x C-x, again typing stuff there, without destroying anything you
>> have written.
>
> You can still do that with delete-selection-mode turned on; you just
> need to hit C-g to deactivate the mark before starting typing in the
> new location.

And get a bell.  In the course of a normal editing operation.

We are talking about the beginner setup, remember?  The beginner that
did not yet customize things (like visible-bell) because he does not
know how.  The beginner that tries Emacs in an office full of people.

Not that this beginner will have a clue about C-g anyway: he'll just
have to figure out a different way to deactivate the region if he is
ever going to type another character.

-- 
David Kastrup

Re: AW: delete-selection-mode

[Chad Brown]

On Mar 18, 2010, at 1:15 AM, David Kastrup wrote:

> And get a bell.  In the course of a normal editing operation.
> 
> We are talking about the beginner setup, remember?  The beginner that
> did not yet customize things (like visible-bell) because he does not
> know how.  The beginner that tries Emacs in an office full of people.
> 
> Not that this beginner will have a clue about C-g anyway: he'll just
> have to figure out a different way to deactivate the region if he is
> ever going to type another character.

The beginner who finds itself with a highlighted region that it doesn't want highlighted will remove it by clicking with the mouse, like they do in every other editing context that they've ever used.  They will get no bell.  

The slightly more advanced beginner who doesn't want to use the mouse will instead use an arrow key, again like they do in every other editing context that they've ever used.  Again, they will get no bell.

Eventually, if we lay out the breadcrumbs well and if their curiosity leads them in that direction, they will discover that emacs can change this interaction, and that removing the convenience of tmm/delsel (and many, many people find that behavior more convenient) opens up the possibility of a more elaborate set of options.  They'll also learn at that time (again assuming that we handle that part of the documentation adequately) that there are middle grounds between the two extremes, and that, as it says on the very first line of description we show people:  ``GNU Emacs is an extensible, customizable text editor—and more.'' -- and then they will decide for themselves.   

*Chad

Re: AW: delete-selection-mode

[Stefan Monnier]

> The slightly more advanced beginner who doesn't want to use the mouse
> will instead use an arrow key, again like they do in every other
> editing context that they've ever used.  Again, they will get no bell.

Hmm?? The arrow key will not (in general) deactivate the region.


        Stefan

Re: AW: delete-selection-mode

[Chad Brown]

On Mar 18, 2010, at 11:10 AM, Stefan Monnier wrote:

>> The slightly more advanced beginner who doesn't want to use the mouse
>> will instead use an arrow key, again like they do in every other
>> editing context that they've ever used.  Again, they will get no bell.
> 
> Hmm?? The arrow key will not (in general) deactivate the region.

I tested it before I sent my response, just to make sure that it wasn't some setting of mine.  


	With bzr emacs revno 99685
	Run emacs with -Q
	load some multiline chunk of text
	sweep out a chunk of that text with the mouse
	watch it become highlighted

Then:

	hit an arrow key:  the cursor moves and the region deactivates

Or: 
	
	hit delete and see the region deleted

Or:

	hit another self-inserting key and see the region deactivated and the key inserted at the end.

It's only that last that betrays new-user expectations.  If delete-selection-mode is enabled, things proceed as the new user expects.

*Chad

Re: AW: delete-selection-mode

[Stefan Monnier]

>>> The slightly more advanced beginner who doesn't want to use the mouse
>>> will instead use an arrow key, again like they do in every other
>>> editing context that they've ever used.  Again, they will get no bell.
>> Hmm?? The arrow key will not (in general) deactivate the region.
> I tested it before I sent my response, just to make sure that it
> wasn't some setting of mine.  

> 	With bzr emacs revno 99685
> 	Run emacs with -Q
> 	load some multiline chunk of text
> 	sweep out a chunk of that text with the mouse
> 	watch it become highlighted

Ah, but here you do use the mouse.  That's the detail that makes the
arrow key deactivate the region.


        Stefan

Re: AW: delete-selection-mode

[Harald Hanche-Olsen]

+ Chad Brown <yandros@MIT.EDU>:

> The beginner who finds itself with a highlighted region that it doesn't want highlighted will remove it by clicking with the mouse, like they do in every other editing context that they've ever used.  They will get no bell.

I experimented a little with this, and found some slightly annoying discrepancies. Namely:

With no region active, use shift+movement commands to create a region. Hit an unshifted arrow key, and the highlight goes away. So far so good.

Next, repeat this, but hit C-x C-x while the region is still active. Hit an unshifted arrow key, and the highlight goes away. Okay.

Finally, hit C-x C-x again. The region is visible again, but this time, unshifted arrow keys don't make it go away. This seems inconsistent, and might well confuse the beginner who has just started learning about C-x C-x.

Regarding C-g and deactivating the mark: I understand that C-g behaviour is a rather fundamental feature of emacs. Having it do the double duty of deactivating the mark seems odd to me. But if it is to be so, how hard would it be to make it ONLY deactivate the mark, and not ring the bell or do anything else associated with it? Provided the mark is active of course. If it is not, C-g should do its usual thing. This would have to be coded carefully, so that, if deactivating the mark fails (if such a thing is possible) the standard C-g behaviour happens anyhow.

- Harald

Re: AW: delete-selection-mode

[Chong Yidong]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> With no region active, use shift+movement commands to create a
> region. Hit an unshifted arrow key, and the highlight goes away. So
> far so good.
>
> Next, repeat this, but hit C-x C-x while the region is still
> active. Hit an unshifted arrow key, and the highlight goes away. Okay.
>
> Finally, hit C-x C-x again. The region is visible again, but this
> time, unshifted arrow keys don't make it go away. This seems
> inconsistent, and might well confuse the beginner who has just started
> learning about C-x C-x.

shift-selection is an inferior method of marking a region.  We provide
shift-selection because the keybindings don't conflict with the
canonical method, but it is a special case.

"The beginner who has just started learning about C-x C-x" should be
learning about the canonical method of manipulating regions (i.e., using
a proper region, such as by typing C-SPC and moving the point away).

Re: AW: delete-selection-mode

[Lennart Borgman]

On Thu, Mar 18, 2010 at 9:02 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>
> shift-selection is an inferior method of marking a region.

That sounds strange. It is the common way for most editing environment
for selecting text.

> We provide
> shift-selection because the keybindings don't conflict with the
> canonical method, but it is a special case.

Is not the main reason to provide it compatibility?

Re: AW: delete-selection-mode

[Chong Yidong]

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

>> shift-selection is an inferior method of marking a region.
>
> That sounds strange. It is the common way for most editing environment
> for selecting text.

The two statements are not contradictory.

Re: AW: delete-selection-mode

[Lennart Borgman]

On Thu, Mar 18, 2010 at 9:10 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>>> shift-selection is an inferior method of marking a region.
>>
>> That sounds strange. It is the common way for most editing environment
>> for selecting text.
>
> The two statements are not contradictory.


That is true. They apply to different dimensions. The first is your
personal preference. The second refers to a fact.

Wouldn't it be good if we clearly stated when we tell our preferences?
Don't you think that would be a rather easy way to prevent flames
(which are just too boring)?

Re: AW: delete-selection-mode

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>> shift-selection is an inferior method of marking a region.
>>>
>>> That sounds strange. It is the common way for most editing environment
>>> for selecting text.
>>
>> The two statements are not contradictory.
>
> That is true. They apply to different dimensions. The first is your
> personal preference. The second refers to a fact.

C'mon, chill...

-Miles

-- 
Year, n. A period of three hundred and sixty-five disappointments.

Re: AW: delete-selection-mode

[Lennart Borgman]

On Thu, Mar 18, 2010 at 9:34 PM, Miles Bader <miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>>> shift-selection is an inferior method of marking a region.
>>>>
>>>> That sounds strange. It is the common way for most editing environment
>>>> for selecting text.
>>>
>>> The two statements are not contradictory.
>>
>> That is true. They apply to different dimensions. The first is your
>> personal preference. The second refers to a fact.
>
> C'mon, chill...

There are better ways to say that you do not agree.

Re: AW: delete-selection-mode

[Juri Linkov]

>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>>>> shift-selection is an inferior method of marking a region.
>>>>>
>>>>> That sounds strange. It is the common way for most editing environment
>>>>> for selecting text.
>>>>
>>>> The two statements are not contradictory.
>>>
>>> That is true. They apply to different dimensions. The first is your
>>> personal preference. The second refers to a fact.
>>
>> C'mon, chill...
>
> There are better ways to say that you do not agree.

Lennart, I'm surprised that you think shift-selection is not
an inferior method of marking a region.  To me this is one
of the main reasons I can't edit text outside of Emacs:
typing arrow keys deactivates the selection, you can't go
to the beginning of the selection without deactivating it,
and many more disadvantages.

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

Re: AW: delete-selection-mode

[Lennart Borgman]

On Thu, Mar 18, 2010 at 10:34 PM, Juri Linkov <juri@jurta.org> wrote:
>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>>>>> shift-selection is an inferior method of marking a region.
>>>>>>
>>>>>> That sounds strange. It is the common way for most editing environment
>>>>>> for selecting text.
>>>>>
>>>>> The two statements are not contradictory.
>>>>
>>>> That is true. They apply to different dimensions. The first is your
>>>> personal preference. The second refers to a fact.
>>>
>>> C'mon, chill...
>>
>> There are better ways to say that you do not agree.
>
> Lennart, I'm surprised that you think shift-selection is not
> an inferior method of marking a region.  To me this is one
> of the main reasons I can't edit text outside of Emacs:
> typing arrow keys deactivates the selection, you can't go
> to the beginning of the selection without deactivating it,
> and many more disadvantages.

I did not say I do not like the other way of marking a region. I use
it sometimes (and I would not have known about them if it were not for
these discussions).

However most of the time I am quite satisfied with cua-modes way of
doing it. You can mark commands there as "region extenders" so to say.
This is very useful and should in my opinion be used more.

Unfortunately we can not discuss that since we are to occupied with
the kind of discussion we have here. I have no doubt that we will
change Emacs' defaults more and more towards default in other editing
environments. Actually I do believe nearly all of us have the same
thought. The problem is merely how to go there without disruption.

Therefore I would be glad to divide between personal opinions (which
are useful and valuable) and more objective descriptions (which of
course also are valuable and useful). Beeing clear about the division
would make it much easier to be creative in the discussion, both
because we better understand what other involved in the discussion
want and also because those that think angry arguments are heavy will
otherwise have their creativity totally disappearing. (That is how
human beeings functions psychologically.)

RE: AW: delete-selection-mode

[Drew Adams]

> >> You can set the mark, move somewhere else, type stuff 
> >> there, and return using C-x C-x, again typing stuff there,
> >> without destroying anything you have written.
> >
> > You can still do that with delete-selection-mode turned on; you just
> > need to hit C-g to deactivate the mark before starting typing in the
> > new location.
> 
> And get a bell.  In the course of a normal editing operation.

Oh please. Is this what this has boiled down to? The bell?

With d-s-mode, you have to use C-g to deactivate the region - and you'll hear a
bell. Without d-s-mode, you have to hit C-w or DEL to replace the region - no
bell.

So we get rid of the bell for C-g when it deactivates the region. Problem
solved.

Re: AW: delete-selection-mode

[Stefan Monnier]

>> >> You can set the mark, move somewhere else, type stuff 
>> >> there, and return using C-x C-x, again typing stuff there,
>> >> without destroying anything you have written.
>> > You can still do that with delete-selection-mode turned on; you just
>> > need to hit C-g to deactivate the mark before starting typing in the
>> > new location.
>> And get a bell.  In the course of a normal editing operation.
> Oh please. Is this what this has boiled down to? The bell?

C-g *is* a problem.  Not just because of the bell, but also because of
the slight time delay (caused by the bell); because it flushes the
key buffer; because it interrupts a macro-recoding, ...
It's not the end of the world, but it's not a very satisfactory answer.


        Stefan

RE: AW: delete-selection-mode

[Drew Adams]

> >> > you just need to hit C-g to deactivate the mark before
> >> > starting typing in the new location.
>
> >> And get a bell.  In the course of a normal editing operation.
>
> > Oh please. Is this what this has boiled down to? The bell?
> 
> C-g *is* a problem.  Not just because of the bell, but also because of
> the slight time delay (caused by the bell); because it flushes the
> key buffer; because it interrupts a macro-recoding, ...
> It's not the end of the world, but it's not a very 
> satisfactory answer.

Then let's find another key to (only) deactivate.

None of the things you mention, including the bell, have anything intrinsically
to do with an active region, t-m-mode, or d-s-mode.

Re: AW: delete-selection-mode

[Juri Linkov]

>> C-g *is* a problem.  Not just because of the bell, but also because of
>> the slight time delay (caused by the bell); because it flushes the
>> key buffer; because it interrupts a macro-recoding, ...
>> It's not the end of the world, but it's not a very
>> satisfactory answer.
>
> Then let's find another key to (only) deactivate.

  ESC ESC ESC runs the command keyboard-escape-quit,
  which is an interactive compiled Lisp function in `simple.el'.

  It is bound to M-ESC ESC.

  (keyboard-escape-quit)

  Exit the current "mode" (in a generalized sense of the word).
  This command can exit an interactive command such as `query-replace',
  can clear out a prefix argument or a region,
  can get out of the minibuffer or other recursive edit,
  cancel the use of the current buffer (for special-purpose buffers),
  or go back to just one window (by deleting all but the selected window).

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

Re: AW: delete-selection-mode

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> Then let's find another key to (only) deactivate.
>
>   ESC ESC ESC runs the command keyboard-escape-quit,
>   which is an interactive compiled Lisp function in `simple.el'.
>
>   It is bound to M-ESC ESC.

Er, how is that any better?

ESC ESC ESC is supposed to be an idiot-friendly "get me out of here"
command; changing its semantics to overload some sort of "... oh also
you can use it to deactivate the region" exception would defeat the
simplicity which is necessary to make it idiot-friendly.

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.

RE: AW: delete-selection-mode

[Drew Adams]

> >> C-g *is* a problem.  Not just because of the bell, but 
> >> also because of
> >> the slight time delay (caused by the bell); because it flushes the
> >> key buffer; because it interrupts a macro-recoding, ...
> >> It's not the end of the world, but it's not a very
> >> satisfactory answer.
> >
> > Then let's find another key to (only) deactivate.
> 
>   ESC ESC ESC runs the command keyboard-escape-quit,
>   which is an interactive compiled Lisp function in `simple.el'.
> 
>   It is bound to M-ESC ESC.
> 
>   (keyboard-escape-quit)
> 
>   Exit the current "mode" (in a generalized sense of the word).
>   This command can exit an interactive command such as 
> `query-replace',
>   can clear out a prefix argument or a region,
>   can get out of the minibuffer or other recursive edit,
>   cancel the use of the current buffer (for special-purpose buffers),
>   or go back to just one window (by deleting all but the 
> selected window).

Interesting, but I think we need a key that doesn't have any meaning in the
context where a region might be active. Maybe that means we need a key that
isn't yet bound; dunno.

Imagine that you want to use the key for one of the uses described above (e.g.
clear the region or exit the minibuffer or a recursive edit). If the region is
active in the current buffer (e.g. the minibuffer in the latter cases), then
would you be doing ESC ESC ESC ESC ESC ESC? And what if you wanted one of those
behaviors but did not also want to deactivate the region?

Too complicated, IMO. But worth thinking about.

keyboard-escape-quit (was: delete-selection-mode)

[Juri Linkov]

> Interesting, but I think we need a key that doesn't have any meaning in the
> context where a region might be active. Maybe that means we need a key that
> isn't yet bound; dunno.

I use `keyboard-escape-quit' all the time to deactivate the region
without any problem.  Actually I rebound it to the single ESC (because ESC
as a prefix is not needed when Meta M- is available on X and xterm).
And this single ESC to deactivate the region is very convenient.

> Imagine that you want to use the key for one of the uses described above (e.g.
> clear the region or exit the minibuffer or a recursive edit). If the region is
> active in the current buffer (e.g. the minibuffer in the latter cases), then
> would you be doing ESC ESC ESC ESC ESC ESC? And what if you wanted one of those
> behaviors but did not also want to deactivate the region?

I think in `keyboard-escape-quit' deselecting the region should have
a higher priority than deactivating the minibuffer because it's possible
to select the region in the minibuffer, and when the minibuffer is gone
then there is no region to deselect anymore.  IOW, the current behavior
breaks the logic of `keyboard-escape-quit' that should cancel one active
feature per invocation.

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2010-03-05 12:01:10 +0000
+++ lisp/simple.el	2010-03-20 23:52:09 +0000
@@ -5591,13 +5603,13 @@ (defun keyboard-escape-quit ()
 cancel the use of the current buffer (for special-purpose buffers),
 or go back to just one window (by deleting all but the selected window)."
   (interactive)
-  (cond ((eq last-command 'mode-exited) nil)
+  (cond ((region-active-p)
+	 (deactivate-mark))
+	((eq last-command 'mode-exited) nil)
 	((> (minibuffer-depth) 0)
 	 (abort-recursive-edit))
 	(current-prefix-arg
 	 nil)
-	((region-active-p)
-	 (deactivate-mark))
 	((> (recursion-depth) 0)
 	 (exit-recursive-edit))
 	(buffer-quit-function

PS: Or maybe we should handle two cases in `keyboard-escape-quit':
deselecting the region in the minibuffer (with a priority higher than
deactivating the minibuffer) and deselecting the region in normal buffers
(with a priority lower than deactivating the minibuffer)?

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

RE: keyboard-escape-quit (was: delete-selection-mode)

[Drew Adams]

> > Interesting, but I think we need a key that doesn't have 
> > any meaning in the context where a region might be active.
> > Maybe that means we need a key that isn't yet bound; dunno.
> 
> I use `keyboard-escape-quit' all the time to deactivate the region
> without any problem.

FWIW - I never paid any attention to `keyboard-escape-quit', for some reason.
Taking a look now, I am perplexed.

The description of `keyboard-escape-quit' indicates that it means everything and
nothing, does everything and nothing:

  Exit the current "mode" (in a generalized sense of the word).

It apparently cannot even be described clearly. The description refers to a
fuzzy concept of `mode' with no explanation, and it even puts `mode' in quotes,
to make it even fuzzier. Then it adds a parenthetical expression that
generalizes it still more. Hard to get any fuzzier.

As Coluche said, when one can't say anything clearer than that, one might as
well say nothing at all. ;-) The only real take-away from the explanation is
that the command in some sense _exits_ from something or other. What "exiting"
means is left open. What is "exited" from is left open. Deliberately,
presumably. I suppose that's the whole point, but it doesn't help me.

So the rest of the doc string is then a laundry list of examples of different
kinds of "exiting" from different kinds of "modes", presumably to give some
flavor of what the command could be used for:

   This command can exit an interactive command such as
   `query-replace', can clear out a prefix argument or a
   region, can get out of the minibuffer or other recursive
   edit, cancel the use of the current buffer (for
   special-purpose buffers), or go back to just one window
   (by deleting all but the selected window).

That just shows that the meaning is even more nebulous than the first line alone
indicates. And this sorry situation is apparently not new - the Emacs 20 doc
string is the same.

What's also interesting is that this function is apparently not used anywhere in
the Emacs source code, apart from binding it globally to ESC ESC ESC. If used
interactively, it does call `deactivate-mark' to deactivate the region - OK,
that much is clear.

The doc string of `keyboard-escape-quit' also gives the example of exiting
`query-replace', but `ESC ESC ESC' does not do that for me. Instead, a single
ESC seems to exit completely.

`keyboard-escape-quit' would just return nil if it were invoked during
`query-replace' (e.g. by ESC ESC ESC). That would happen because the
`query-replace' code sets `this-command' to `mode-exited' when it encounters an
unrecognized character. And the `query-replace' (`perform-replace') code that
does that has essentially exited at that point, AFAICT. So if it were invoked,
`keyboard-escape-quit' would effectively exit, AFAICT.

However, I don't see how `keyboard-escape-quit' could actually be invoked during
`query-replace', since ESC (not ESC ESC ESC) is bound in `query-replace-map' to
the pseudo-command `exit-prefix', which the code immediately treats as an
unrecognized character (setting `this-command' to `mode-exited').

The impression I get is that `query-replace' essentially just exits when
`perform-replace' handles any unrecognized char (such as a single ESC), and that
the code never goes through `keyboard-escape-quit'. But I admit that what really
happens isn't clear to me. 

`perform-replace' does put the unrecognized char/key onto
`unread-command-events', so maybe there is something special going on wrt an ESC
char in `unread-command-events' and the key sequence ESC ESC ESC (?). But a
single ESC does exit, for me.

Another thing that's unclear to me are the statements in the doc to the effect
that ESC ESC ESC "cancels a prefix arg" or "clears out a prefix arg". Howzat?
What's that about? Can someone give a recipe/example for this?

---

Anyway, I'm not sure what your point about region deactivation is, Juri, but it
seems to me that we would be better off making the key and command that
deactivates the region more specific, not less. To me, it makes sense to have a
dedicated command (and maybe a key) - one that does only that.

Yes, I realize that `keyboard-escape-quit' does the job, it exists, and it is
documented. Still, it seems like a weird mix.

> I think in `keyboard-escape-quit' deselecting the region
> should have a higher priority than deactivating the
> minibuffer because it's possible to select the region in
> the minibuffer, and when the minibuffer is gone
> then there is no region to deselect anymore.  IOW, the 
> current behavior breaks the logic of `keyboard-escape-quit'
> that should cancel one active feature per invocation.

Yes, well it all depends on what behavior one (some code) might want, doesn't
it?

If we try to reuse that key, then we have to define a sequence of priorities, as
you describe. Things become less flexible. What seems odd to me is that we even
defined such a hybrid as `keyboard-escape-quit'.

It seems right to me that we have some key that does only the one thing:
deactivate the region. Whether we then might also want to sometimes combine
deactivation with other actions and bind such a combination to some other key is
another matter.

I can't speak to your point about reordering current priorities for
`keyboard-escape-quit'. I'm not very familiar with it and I haven't thought
about this.

My only point is that if we don't like C-g for region deactivation (and that was
the starting point), it's precisely because C-g means and does other things as
well. And the same is apparently true for ESC ESC ESC: it's a mixed bag.

I think we should pick some unused key for (just) deactivating the region. But
I'm pretty ignorant on this subject - I might well be wrong. I'm going by
intuition more than understanding, here.

Re: keyboard-escape-quit

[Juri Linkov]

> FWIW - I never paid any attention to `keyboard-escape-quit', for some reason.
> Taking a look now, I am perplexed.

`keyboard-escape-quit' is very useful for effective use of Emacs.
You can do several frequent actions with a single key.
It is like undo for a stack of implicit "modes" (or "states").
If you don't use it, please don't try to diminish it.

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

RE: keyboard-escape-quit

[Drew Adams]

> > FWIW - I never paid any attention to 
> > `keyboard-escape-quit', for some reason.
> > Taking a look now, I am perplexed.
> 
> `keyboard-escape-quit' is very useful for effective use of Emacs.
> You can do several frequent actions with a single key.
> It is like undo for a stack of implicit "modes" (or "states").
> If you don't use it, please don't try to diminish it.

You misunderstood my post. I did not try to diminish k-e-q. I tried to explain
how I am perplexed (confused) by its doc. I was asking for clarification, so I
can understand it better.

Please read the post again. If you then think the doc is clear, feel free to
ignore my confusion. Or feel free to help me see what I'm missing.

I would like to understand it better, especially since _you_, in particular,
find it useful. The doc doesn't really help me understand its usefulness.
Perhaps you can elaborate? You can see at least that I tried to understand,
reading the doc and looking at the few source-code uses of it. There's not much
to go on.

Does it work with `query-replace' for you, or is that part of the doc just
wrong? And again, I don't understand some of that q-r code. Whereas the code for
deactivating the region is straightforward, the code for exiting `query-replace'
with ESC ESC ESC is not (to me).

---

My writing about which key to use to deactivate the active region was separate
from my expression of confusion about the k-e-q doc, and I separated it as such
using an explicit separator: `---', as here.

And I don't feel strongly about the key to use to deactivate. As I said, just a
feeling that simpler is probably better.

Re: keyboard-escape-quit

[Juri Linkov]

> Does it work with `query-replace' for you, or is that part of the doc
> just wrong? And again, I don't understand some of that q-r code.
> Whereas the code for deactivating the region is straightforward, the
> code for exiting `query-replace' with ESC ESC ESC is not (to me).

Yes, it works with `query-replace' for me, but that's because I've rebound
`keyboard-escape-quit' to the single ESC :-)  But when I try with `emacs -Q',
the first ESC exits `query-replace'.  Could you please try typing ESC
with `query-replace' in Emacs 20.  Maybe some relatively recent change
broke this feature.

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

RE: keyboard-escape-quit

[Drew Adams]

> > Does it work with `query-replace' for you, or is that part 
> > of the doc just wrong? And again, I don't understand some of that
> > q-r code. Whereas the code for deactivating the region is
> > straightforward, the code for exiting `query-replace' with
> > ESC ESC ESC is not (to me).
> 
> Yes, it works with `query-replace' for me, but that's because 
> I've rebound `keyboard-escape-quit' to the single ESC :-)  But
> when I try with `emacs -Q', the first ESC exits `query-replace'.
> Could you please try typing ESC with `query-replace' in Emacs 20.
> Maybe some relatively recent change broke this feature.

Emacs 20, 22, and 23, including pretest 23.1.92, all behave the same (emacs -Q
on Windows).

But actually it is not that the first ESC exits. I misspoke a bit. What I said I
saw in the code is what actually happens. The first ESC is simply pushed back
onto the `unread-command-events', as is any other key/char that is not
recognized by query-replace. Eventually, with ESC ESC ESC (3 ESC's being pushed
onto `unread-command-events'), `keyboard-escape-quit' is called, and it sees
that `last-command' is `mode-exited', so it returns nil and `query-replace'
exits.

If you wait after hitting ESC, you'll see "ESC" appear in the echo area. If you
then hit `0' (another unrecognized key), you'll see "ESC 0 ", and so on. As long
as you hit an unrecognized key (e.g. `0'), it'll just be added to the echo area:
"ESC 0 0 0 0"....

If you hit left arrow after the first ESC, then you'll see "ESC left" in the
echo area and you will really have exited, since ESC <left> is bound. Same thing
for ESC ESC ESC. But if you use `ESC ESC right' then you'll see "ESC ESC <right>
is undefined" in the echo area. (Not sure why the difference in behavior there -
haven't tried to figure it out.)

So I guess the doc is not totally incorrect wrt ESC ESC ESC for query-replace.
But the q-r code seems more complex than it should need to be in this regard,
and the behavior seems a bit inconsistent (or not obvious, let's put it that
way). But as I said before, I'm probably missing something - it's not real clear
to me.

Seems like `keyboard-escape-quit' could just do something similar to what it
does for `transient-mark-mode': have an explicit test for some `query-replace'
state. Or perhaps `perform-replace' could just set `buffer-quit-function'.
Dunno.

Re: keyboard-escape-quit

[Stefan Monnier]

> But the q-r code seems more complex than it should need to be in this
> regard, and the behavior seems a bit inconsistent (or not obvious,
> let's put it that way). But as I said before, I'm probably missing
> something - it's not real clear to me.

You're right: the q-r code should use a recursive-edit (or something
else with the same kind of effect, like isearch's
overriding-terminal-map) rather than build its own ad-hoc event loop.
q-r's current loop suffers from various misfeatures because that.


        Stefan

Re: AW: delete-selection-mode

[Stefan Monnier]

>>> C-g *is* a problem.  Not just because of the bell, but also because of
>>> the slight time delay (caused by the bell); because it flushes the
>>> key buffer; because it interrupts a macro-recoding, ...
>>> It's not the end of the world, but it's not a very
>>> satisfactory answer.
>> Then let's find another key to (only) deactivate.

>   ESC ESC ESC runs the command keyboard-escape-quit,
>   which is an interactive compiled Lisp function in `simple.el'.

If the side-effects of C-g are considered problematic, then I think it's
pretty clear that the additional side effects of ESC ESC ESC will be
even less acceptable.


        Stefan

Re: AW: delete-selection-mode

[Juri Linkov]

> And get a bell.  In the course of a normal editing operation.
>
> We are talking about the beginner setup, remember?  The beginner that
> did not yet customize things (like visible-bell) because he does not
> know how.  The beginner that tries Emacs in an office full of people.

IIRC, we decided to turn off the bell by default and use visible-bell
in the next release:

http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01050.html

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

Re: AW: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> And get a bell.  In the course of a normal editing operation.
>>
>> We are talking about the beginner setup, remember?  The beginner that
>> did not yet customize things (like visible-bell) because he does not
>> know how.  The beginner that tries Emacs in an office full of people.
>
> IIRC, we decided to turn off the bell by default and use visible-bell
> in the next release:
>
> http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01050.html

I'm not actually sure that C-g warrants ringing either bell.

-- 
David Kastrup

Re: AW: delete-selection-mode

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> I'm not actually sure that C-g warrants ringing either bell.

I agree; the bell is a holdover from more barbaric times.

Re: AW: delete-selection-mode

[Stefan Monnier]

>> I'm not actually sure that C-g warrants ringing either bell.
> I agree; the bell is a holdover from more barbaric times.

I see we all agree.  Could someone send a patch to make C-g send an SMS?


        Stefan

Re: AW: delete-selection-mode

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> I'm not actually sure that C-g warrants ringing either bell.
>> I agree; the bell is a holdover from more barbaric times.
>
> I see we all agree.  Could someone send a patch to make C-g send an SMS?

Too modern for Emacs. Use pigeons.

>         Stefan

SCNR, Michael.

Re: AW: delete-selection-mode

[Miles Bader]

Michael Albinus <michael.albinus@gmx.de> writes:
>>>> I'm not actually sure that C-g warrants ringing either bell.
>>> I agree; the bell is a holdover from more barbaric times.
>>
>> I see we all agree.  Could someone send a patch to make C-g send an SMS?
>
> Too modern for Emacs. Use pigeons.

Ah, a tweet?

-Miles

-- 
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.

Bell (was: delete-selection-mode)

[Juri Linkov]

>>> I'm not actually sure that C-g warrants ringing either bell.
>> I agree; the bell is a holdover from more barbaric times.
>
> I see we all agree.  Could someone send a patch to make C-g send an SMS?

In http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01291.html
I proposed to add a new symbol property `error-bell' by analogy with
properties `error-message' and `error-conditions' and with possible
values t, nil and `visible', and to put this property with the value nil
on `beginning-of-buffer', `end-of-buffer' and `keyboard-quit'.
This makes possible to add more values later, e.g. `user-error'
or even `send-sms' and `send-tweet'.

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

RE: Bell (was: delete-selection-mode)

[Drew Adams]

> >>> I'm not actually sure that C-g warrants ringing either bell.
> 
> In http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01291.html
> I proposed to add a new symbol property `error-bell' by analogy with
> properties `error-message' and `error-conditions' and with possible
> values t, nil and `visible', and to put this property with 
> the value nil
> on `beginning-of-buffer', `end-of-buffer' and `keyboard-quit'.
> This makes possible to add more values later, e.g. `user-error'
> or even `send-sms' and `send-tweet'.

Besides that approach (which is OK, I think), it would be useful to be able to
let-bind a variable whose value could mute `ding'. IOW, make `ding' sensitive to
that variable. That way, you could easily mute `ding' throughout other scopes,
besides just function definitions.

Re: Bell

[Stefan Monnier]

>>>> I'm not actually sure that C-g warrants ringing either bell.
>>> I agree; the bell is a holdover from more barbaric times.
>> I see we all agree.  Could someone send a patch to make C-g send an SMS?
> In http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01291.html
> I proposed to add a new symbol property `error-bell' by analogy with
> properties `error-message' and `error-conditions' and with possible
> values t, nil and `visible', and to put this property with the value nil
> on `beginning-of-buffer', `end-of-buffer' and `keyboard-quit'.
> This makes possible to add more values later, e.g. `user-error'
> or even `send-sms' and `send-tweet'.

This is a separate issue.
The first issue is "when we decided we want to ring the bell, how do we
do it".  Personally I *hate* it when my computer makes a "beep", so the
only option I consider acceptable is the visual bell.

For this reason, I strongly advocate we use a visual bell by default.
If some people don't like the currentl visual bell, maybe we can come up
with a better one.


        Stefan


PS: As for deciding when to ring a bell, maybe your proposition is
a good one, but for me it is a minor issue compared to the choice of
which bell to use.

Re: Bell

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> If some people don't like the currentl visual bell, maybe we can come up
> with a better one.

http://www.emacswiki.org/emacs/MilesBader#echo-area-bell

-Miles

-- 
Virtues, n. pl. Certain abstentions.

RE: Bell

[Drew Adams]

> > If some people don't like the currentl visual bell, maybe 
> > we can come up with a better one.
> 
> http://www.emacswiki.org/emacs/MilesBader#echo-area-bell

What's pointed out by the discussion so far is not that the bell should go away,
or that it should be replaced by the visual bell, or that the visual bell should
be improved, or that `ding' should be called less, or that `ding' should be
removed, or that `C-g' should not ring the bell.

Rather, what's called for is a way to mute `ding' in a flexible way. What Juri
suggested wrt putting a silence property on function symbols, and what I
suggested wrt binding a silence variable, would provide what's needed. And maybe
there are other suggestions.

Once we have ways to flexibly silence `ding' in various contexts, then we can
decide just where to do so. And users themselves will be able to easily do
likewise.

Re: Bell

[Juri Linkov]

>> > If some people don't like the currentl visual bell, maybe
>> > we can come up with a better one.
>>
>> http://www.emacswiki.org/emacs/MilesBader#echo-area-bell

> Rather, what's called for is a way to mute `ding' in a flexible way. What Juri
> suggested wrt putting a silence property on function symbols, and what I
> suggested wrt binding a silence variable, would provide what's needed. And maybe
> there are other suggestions.

Maybe what Miles suggested would be a better ring bell function?
What I like is an error message highlighted in the echo-area.

Currently in most cases a flashing screen is accompanied
with an error message.  I think it's a bug when there is
no error message displayed.  For instance, typing C-b or M-v
at the beginning of the buffer displays "Beginning of buffer",
but typing C-p doesn't display this error message.  I think
it is a bug that should be fixed with this patch:

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2010-03-05 12:01:10 +0000
+++ lisp/simple.el	2010-03-20 23:57:09 +0000
@@ -4105,9 +4115,10 @@ (defun next-line (&optional arg try-vscr
 	    (insert (if use-hard-newlines hard-newline "\n")))
 	(line-move arg nil nil try-vscroll))
     (if (called-interactively-p 'interactive)
-	(condition-case nil
+	(condition-case err
 	    (line-move arg nil nil try-vscroll)
-	  ((beginning-of-buffer end-of-buffer) (ding)))
+	  ((beginning-of-buffer end-of-buffer)
+	   (ding (message "%s" (error-message-string err)))))
       (line-move arg nil nil try-vscroll)))
   nil)
 
@@ -4135,9 +4146,10 @@ (defun previous-line (&optional arg try-
   (interactive "^p\np")
   (or arg (setq arg 1))
   (if (called-interactively-p 'interactive)
-      (condition-case nil
+      (condition-case err
 	  (line-move (- arg) nil nil try-vscroll)
-	((beginning-of-buffer end-of-buffer) (ding)))
+	((beginning-of-buffer end-of-buffer)
+	 (ding (message "%s" (error-message-string err)))))
     (line-move (- arg) nil nil try-vscroll))
   nil)

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

Re: Bell

[Lennart Borgman]

On Sun, Mar 21, 2010 at 12:59 AM, Juri Linkov <juri@jurta.org> wrote:
>>> > If some people don't like the currentl visual bell, maybe
>>> > we can come up with a better one.
>>>
>>> http://www.emacswiki.org/emacs/MilesBader#echo-area-bell
>
>> Rather, what's called for is a way to mute `ding' in a flexible way. What Juri
>> suggested wrt putting a silence property on function symbols, and what I
>> suggested wrt binding a silence variable, would provide what's needed. And maybe
>> there are other suggestions.
>
> Maybe what Miles suggested would be a better ring bell function?
> What I like is an error message highlighted in the echo-area.
>
> Currently in most cases a flashing screen is accompanied
> with an error message.  I think it's a bug when there is
> no error message displayed.

I agree to that.

We had a discussion a while ago related to this. There are a lot of
error raised that are not really errors. Raising an error is instead
used as a simple mean to go to top level. I proposed implementing
instead something like

  (throw 'top-level msg)

for this, but Stefan replied it would be better implement user-error
for this. I sent a patch for this:

  http://article.gmane.org/gmane.emacs.devel/117892

but it must have hit a black hole or something. Since it is around
again maybe we should consider that now?

Re: Bell

[Juri Linkov]

> We had a discussion a while ago related to this. There are a lot of
> error raised that are not really errors. Raising an error is instead
> used as a simple mean to go to top level. I proposed implementing
> instead something like
>
>   (throw 'top-level msg)
>
> for this, but Stefan replied it would be better implement user-error
> for this. I sent a patch for this:
>
>   http://article.gmane.org/gmane.emacs.devel/117892
>
> but it must have hit a black hole or something. Since it is around
> again maybe we should consider that now?

I see that's a way of getting rid of `debug-ignored-errors'
(pattern-matching on error messages in `debug-ignored-errors' is too ugly).

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

Re: Bell

[Stefan Monnier]

> for this, but Stefan replied it would be better implement user-error
> for this. I sent a patch for this:

>   http://article.gmane.org/gmane.emacs.devel/117892

> but it must have hit a black hole or something.

It just hit a bad time.

> Since it is around again maybe we should consider that now?

Yes, definitely.  Now is a good time to install it on the trunk.


        Stefan

Re: Bell

[Juri Linkov]

> Currently in most cases a flashing screen is accompanied
> with an error message.  I think it's a bug when there is
> no error message displayed.  For instance, typing C-b or M-v
> at the beginning of the buffer displays "Beginning of buffer",
> but typing C-p doesn't display this error message.  I think
> it is a bug that should be fixed with this patch:

Actually, `ding' with the error message deactivates the active region.
Better to use `signal' that doesn't deactivate the region:

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2010-03-05 12:01:10 +0000
+++ lisp/simple.el	2010-03-20 23:57:09 +0000
@@ -4105,9 +4115,10 @@ (defun next-line (&optional arg try-vscr
 	    (insert (if use-hard-newlines hard-newline "\n")))
 	(line-move arg nil nil try-vscroll))
     (if (called-interactively-p 'interactive)
-	(condition-case nil
+	(condition-case err
 	    (line-move arg nil nil try-vscroll)
-	  ((beginning-of-buffer end-of-buffer) (ding)))
+	  ((beginning-of-buffer end-of-buffer)
+	   (signal (car err) nil)))
       (line-move arg nil nil try-vscroll)))
   nil)
 
@@ -4135,9 +4146,10 @@ (defun previous-line (&optional arg try-
   (interactive "^p\np")
   (or arg (setq arg 1))
   (if (called-interactively-p 'interactive)
-      (condition-case nil
+      (condition-case err
 	  (line-move (- arg) nil nil try-vscroll)
-	((beginning-of-buffer end-of-buffer) (ding)))
+	((beginning-of-buffer end-of-buffer)
+	 (signal (car err) nil)))
     (line-move (- arg) nil nil try-vscroll))
   nil)

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

Re: Bell

[Stefan Monnier]

> +	   (signal (car err) nil)))

Is there a particular reason why you used nil rather than (cdr err) as
second argument?


        Stefan

Re: Bell

[Juri Linkov]

>> +	   (signal (car err) nil)))
>
> Is there a particular reason why you used nil rather than (cdr err) as
> second argument?

The only reason is that other line-oriented commands in simple.el
call `signal' explicitly with the second arg nil like:

  (signal 'beginning-of-buffer nil)
  (signal 'end-of-buffer nil)

If it's more reliable with (cdr err), I will add it.

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

Re: Bell

[Stefan Monnier]

>>> +	   (signal (car err) nil)))
>> Is there a particular reason why you used nil rather than (cdr err) as
>> second argument?
> The only reason is that other line-oriented commands in simple.el
> call `signal' explicitly with the second arg nil like:

>   (signal 'beginning-of-buffer nil)
>   (signal 'end-of-buffer nil)

> If it's more reliable with (cdr err), I will add it.

It's not that it's more reliable, it's just that (cdr err) holds the
info that was provided in the second arg of `signal' in the the signal
caught by the condition-case, so it makes sense to propagate it further,
whether it's nil or not.
I.e. (signal (car err) (cdr err)) is the canonical way to re-throw
a signal previously caught by condition-case.


        Stefan

Re: Bell

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 30 Mar 2010 20:24:11 -0400
> Cc: emacs-devel@gnu.org
> 
> I.e. (signal (car err) (cdr err)) is the canonical way to re-throw
> a signal previously caught by condition-case.

I added this to the ELisp manual.

Re: Bell

[Stefan Monnier]

> What's pointed out by the discussion so far is not that the bell
> should go away, or that it should be replaced by the visual bell, or
> that the visual bell should be improved, or that `ding' should be
> called less, or that `ding' should be removed, or that `C-g' should
> not ring the bell.

> Rather, what's called for is a way to mute `ding' in a flexible
> way. What Juri suggested wrt putting a silence property on function
> symbols, and what I suggested wrt binding a silence variable, would
> provide what's needed. And maybe there are other suggestions.

> Once we have ways to flexibly silence `ding' in various contexts, then
> we can decide just where to do so. And users themselves will be able
> to easily do likewise.

I understand what you say, but I disagree.
#include "my earlier post"


        Stefan

RE: Bell

[Drew Adams]

> > What's pointed out by the discussion so far is not that the bell
> > should go away, or that it should be replaced by the visual bell, or
> > that the visual bell should be improved, or that `ding' should be
> > called less, or that `ding' should be removed, or that `C-g' should
> > not ring the bell.
> 
> > Rather, what's called for is a way to mute `ding' in a flexible
> > way. What Juri suggested wrt putting a silence property on function
> > symbols, and what I suggested wrt binding a silence variable, would
> > provide what's needed. And maybe there are other suggestions.
> 
> > Once we have ways to flexibly silence `ding' in various 
> > contexts, then we can decide just where to do so. And users
> > themselves will be able to easily do likewise.
> 
> I understand what you say, but I disagree.
> #include "my earlier post"

No idea what earlier post you mean. What's your argument, in summary? And what
is it that you disagree with?

Re: Bell

[Juri Linkov]

> The first issue is "when we decided we want to ring the bell, how do we
> do it".  Personally I *hate* it when my computer makes a "beep", so the
> only option I consider acceptable is the visual bell.
>
> For this reason, I strongly advocate we use a visual bell by default.

It's hard to find a user who doesn't hate a beep ;)

Visually impaired people would prefer audible feedback,
but I suppose emacspeak takes care of this setting.

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

Re: AW: delete-selection-mode

[David Kastrup]

"Berndl, Klaus" <klaus.berndl@capgemini-sdm.com> writes:

> Since Emacs editing interferes with typical editing commands today my
> vote is "yes".
>
> Of course this is a little bit provoking, so please do not feel
> offened!
>
> But IMHO the following is fact: Today Emacs has very strong
> competitors concerning "what is the most effective way to code my
> programs" - a lot of (commercial or free or open source) so called
> IDEs have adopted some of the pure editing power of Emacs but offer on
> top some power Emacs still lacks today, as for example real, fast and
> powerful refactoring, code navigation and other goodies you need much
> more for effective Code-development than some certain
> Emacs-specials.

If they offer real, fast and powerful refactoring, code navigation and
other goodies, then the way to compete with them is to add powerful
refactoring, code navigation and other goodies to Emacs.  If we make
Emacs the same as them, only worse, that won't help us.

Efficient user interaction is one area that Emacs is good in, partly due
to long discussions and diligent and carefully planned changes of
semantics.  Why should we sacrifice that before the problems in
connection with normal user operation have found solutions?

Emacs has useful syntax highlighting, useful transient marks, useful GUI
integration, in particular when compared with the "pathbreaker" XEmacs,
and part of the reason is that those features were not enabled until the
problems around them have found satisfactory solutions.

"Everybody else does it" is no substitute for efficient and useful
semantics.

-- 
David Kastrup

RE: AW: delete-selection-mode

[Drew Adams]

> > But IMHO the following is fact: Today Emacs has very strong
> > competitors concerning "what is the most effective way to code my
> > programs" - a lot of (commercial or free or open source) so called
> > IDEs have adopted some of the pure editing power of Emacs 
> > but offer on
> > top some power Emacs still lacks today, as for example 
> > real, fast and
> > powerful refactoring, code navigation and other goodies you 
> > need much
> > more for effective Code-development than some certain
> > Emacs-specials.
> 
> If they offer real, fast and powerful refactoring, code navigation and
> other goodies, then the way to compete with them is to add powerful
> refactoring, code navigation and other goodies to Emacs.  If we make
> Emacs the same as them, only worse, that won't help us.
> 
> Efficient user interaction is one area that Emacs is good in, 
> partly due
> to long discussions and diligent and carefully planned changes of
> semantics.  Why should we sacrifice that before the problems in
> connection with normal user operation have found solutions?
> 
> Emacs has useful syntax highlighting, useful transient marks, 
> useful GUI
> integration, in particular when compared with the 
> "pathbreaker" XEmacs,
> and part of the reason is that those features were not 
> enabled until the
> problems around them have found satisfactory solutions.
> 
> "Everybody else does it" is no substitute for efficient and useful
> semantics.

So now we're off onto a wide-open discussion of Emacs vs The Others, and Emacs
vs The World.

Sheesh. And I sardonically warned about the discussion going off into the
boondocks of cua-mode, pc-selection-mode, and mice vs keyboards. I shoulda known
that net wasn't wide enough... Anyway, you've provided an illustration in
spades.

Re: AW: delete-selection-mode

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> If they offer real, fast and powerful refactoring, code navigation and
> other goodies, then the way to compete with them is to add powerful
> refactoring, code navigation and other goodies to Emacs.  If we make
> Emacs the same as them, only worse, that won't help us.

Yes, I agree with this.

Looking at questions by Emacs noobs (e.g. on #emacs), people by and
large _don't_ seem to ask "how do I make the little thing exactly the
same as X" -- they generally seem to understand that Emacs is a bit
different, and are prepared (and often almost excited) to deal with
that.  What gets asked much more often is "How do I make Emacs do
<whizzy IDE feature Z>?"

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: delete-selection-mode

[Stefan Monnier]

> Perhaps we should offer a submenu in "Help" about "Judicious differences
> to other editors",

We should indeed have such a section in the manual, and maybe a link
from the help menu for it.  Care to give it a first shot?


        Stefan

Re: delete-selection-mode

[David Kastrup]

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

>> Perhaps we should offer a submenu in "Help" about "Judicious
>> differences to other editors",
>
> We should indeed have such a section in the manual, and maybe a link
> from the help menu for it.  Care to give it a first shot?

For personal reasons, I am mostly crippled to making more or less useful
suggestions.  I don't have the resources to actually work on them.

-- 
David Kastrup

Re: delete-selection-mode

[joakim]

David Kastrup <dak@gnu.org> writes:

> Juri Linkov <juri@jurta.org> writes:
>
>>>> delete-selection-mode would be the default too, that's what everything
>>>> on the desktop does...
>>
>> I agree with Richard that the primary concern is doing what is useful
>> for newcomers.  One of the most frequent questions they ask is how to do
>> what most other editors do - to replace selected text with a typed
>> character or with yanked text, and to delete the region by typing <delete>
>> without copying it to the kill-ring.
>>
>> What they are asking for is delete-selection-mode,
>> but they can't find it in the documentation because
>> the feature name says nothing to beginners, and
>> they expect to take this functionality for granted.
>>
>> Some recent examples of such problems:
>>
>> http://thread.gmane.org/gmane.emacs.help/60992> http://thread.gmane.org/gmane.emacs.help/45623> http://thread.gmane.org/gmane.emacs.help/42402>
>> Is that reason enough to enable delete-selection-mode by default?
>
> Since it interferes with Emacs-typical editing command sequences, my
> vote is "no".
>
> The question you appear concerned with is more "how can we make
> beginners shut up" rather than "how can we make beginners more
> productive with Emacs".
>
> Perhaps we should offer a submenu in "Help" about "Judicious differences
> to other editors", with rationales, an introducting section saying "Some
> default behaviors we considered useful enough to make them different
> from other editors, so we recommend that you try to get acquainted with
> the suggested mode of operation before deciding against it", maybe even
> with clickable links to customize-variable where you can turn some
> feature like delete-selection-mode on (and off again!).
>
> We could even go as far as to mark some customizable variables as
> "voteable" and have a mechanism where you can send all of your personal
> voteable settings to emacs-votes@gnu.org.

On a related note, I'm often wondering how Emacs-veterans would solve
a problem(having used Emacs only since '88 I can only count myself as
newbie). This information could be gathered automatically with a command
frequency collector that posted to a central repos. If I, as a newbie
were wondering how often dak@gnu.org invokes the scrollbar, maybe I
would find 0. Maybe I could find out all sorts of interesting things
that bother me, like how others jumps to a particular window
efficiently(I use windmove on shift-arrows which I'm not completely
comfortable with).

Maybe people could be persuaded to also post relevant sections of their
.emacs to ELPA? Then a new user could quickly try out how various people
with mouse centric, or keyboard centric, views where using Emacs, and
build their own opinion.

-- 
Joakim Verona

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Alan Mackenzie]

Hi, Juri,

On Wed, Mar 17, 2010 at 02:54:50AM +0200, Juri Linkov wrote:
> >> delete-selection-mode would be the default too, that's what everything
> >> on the desktop does...

> I agree with Richard that the primary concern is doing what is useful
> for newcomers.

You have misconstrued Richard's post.  He went on to say that what is
useful for newcomers isn't necessarily what they expect or "want".
There's thus no indication there that he would support the rest of your
argument.

> One of the most frequent questions they ask is how to do what most
> other editors do - to replace selected text with a typed character or
> with yanked text, and to delete the region by typing <delete> without
> copying it to the kill-ring.

The answer is to ask them why they want this.  C-w is easy to type, as is
<delete>.  delete-select-mode is such an irritating distraction that it
should only be enabled for those who really, truly want it.  Emacs is
rare amongst editing software in that it imposes very few irritations on
users in its default mode of operation.  (That Emacs can be configured is
irrelevant here; we're talking only about it's default settings.)

> What they are asking for is delete-selection-mode, but they can't find
> it in the documentation because the feature name says nothing to
> beginners, and they expect to take this functionality for granted.

Emacs isn't about taking things for granted.  It's about efficiency,
about minimising keystrokes, about not getting in the users' way.  How
about improving the documentation/menu-settings/whatever so that these
beginners find what they're looking for?

> Some recent examples of such problems:

> http://thread.gmane.org/gmane.emacs.help/60992
> http://thread.gmane.org/gmane.emacs.help/45623
> http://thread.gmane.org/gmane.emacs.help/42402

> Is that reason enough to enable delete-selection-mode by default?

No.  We do not want to send Emacs down the slippery slope towards lowest
common denominator editors.  We want to encourage Emacs users to use
Emacs efficiently, taking advantage of its many features.  What you are
proposing would have the opposite effect.

We've had this discussion often enough in the past.  Do we really have to
go through these motions yet again?

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

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Lennart Borgman]

Hi Alan,

On Wed, Mar 17, 2010 at 3:35 PM, Alan Mackenzie <acm@muc.de> wrote:
>
>> I agree with Richard that the primary concern is doing what is useful
>> for newcomers.
>
> You have misconstrued Richard's post.  He went on to say that what is
> useful for newcomers isn't necessarily what they expect or "want".
> There's thus no indication there that he would support the rest of your
> argument.

Juri can of course be correct too when he interpret this basic part of
RMS message. You can also be that. However I see no reason why Juri
can't argue that way.

> The answer is to ask them why they want this.

Have not that been done many, many times - in the context of Emacs and
in research on user-computer interaction. As far as I understand the
answer is that new users most often want it to behave as they are used
to from other applications. They want that exactly because it saves
them time and avoids confusion (which also costs them time).

I for one agree with that argument.

> C-w is easy to type, as is <delete>.

It is of course not about "easy to type".

> delete-select-mode is such an irritating distraction that it
> should only be enabled for those who really, truly want it.

I am glad you care. Of course for those who thinks it is disturbing it
should be turned off. But those are not the newcomers as far as I can
see.

> Emacs is
> rare amongst editing software in that it imposes very few irritations on
> users in its default mode of operation.

You might have forgotten a negation somewhere. Emacs is well known for
beeing difficult for most beginners. And one reason is that it does
not follow usual defaults where it could have done so.

You may think this is a small problem, but I do not. Adding a lot of
small differences makes each one of them much harder for the beginner.

> No.  We do not want to send Emacs down the slippery slope towards lowest
> common denominator editors.  We want to encourage Emacs users to use
> Emacs efficiently, taking advantage of its many features.  What you are
> proposing would have the opposite effect.

We all care about efficiency. Where we differ is what we think is efficient.

> We've had this discussion often enough in the past.  Do we really have to
> go through these motions yet again?

As long as Emacs does not disappear and attracts some new users it
will pop up. I can see no way to avoid that.

Re: delete-selection-mode

[David Kastrup]

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

> On Wed, Mar 17, 2010 at 3:35 PM, Alan Mackenzie <acm@muc.de> wrote:
>>
>>> I agree with Richard that the primary concern is doing what is useful
>>> for newcomers.
>>
>> You have misconstrued Richard's post.  He went on to say that what is
>> useful for newcomers isn't necessarily what they expect or "want".
>> There's thus no indication there that he would support the rest of your
>> argument.
>
> Juri can of course be correct too when he interpret this basic part of
> RMS message. You can also be that. However I see no reason why Juri
> can't argue that way.
>
>> The answer is to ask them why they want this.
>
> Have not that been done many, many times - in the context of Emacs and
> in research on user-computer interaction. As far as I understand the
> answer is that new users most often want it to behave as they are used
> to from other applications. They want that exactly because it saves
> them time

Once.

> and avoids confusion (which also costs them time).
>
> I for one agree with that argument.

It is valid, but an O(1) type of argument.  It will not outweigh O(n)
arguments even with a small factor eventually.  If something costs time
repeatedly, saving startup time is not worth the trouble when we are
catering about being efficient on a continuing base.

I already gave a recipe for making mouse-centric people happy with a
mouse-centric subset of delete-selection-mode.

Nobody even bothered to read it, apparently.

-- 
David Kastrup

Re: delete-selection-mode

[Lennart Borgman]

On Wed, Mar 17, 2010 at 8:38 PM, David Kastrup <dak@gnu.org> wrote:
>>> The answer is to ask them why they want this.
>>
>> Have not that been done many, many times - in the context of Emacs and
>> in research on user-computer interaction. As far as I understand the
>> answer is that new users most often want it to behave as they are used
>> to from other applications. They want that exactly because it saves
>> them time
>
> Once.
>
>> and avoids confusion (which also costs them time).
>>
>> I for one agree with that argument.
>
> It is valid, but an O(1) type of argument.


It is a funny argument, but hardly valid. You must look much more
carefully into the problem to see what is gained and what is lost.

I have tried to explain that using defaults that are uncommon is very
bad because it raises the complexity in an already complex situation
for newcomers.

You might compare the way the n-back game works for example. This sort
of game is actually by some researchers believed to increase working
memory and intelligence, something that was thought to be impossible
before. It does this, however, by gradually making the game more
difficult as the user gets better at playing it. If a user is started
on a difficult level no gains or slow gains will be made.


> It will not outweigh O(n)
> arguments even with a small factor eventually.  If something costs time
> repeatedly, saving startup time is not worth the trouble when we are
> catering about being efficient on a continuing base.
>
> I already gave a recipe for making mouse-centric people happy with a
> mouse-centric subset of delete-selection-mode.
>
> Nobody even bothered to read it, apparently.


I hope some mouse-centric people will read it. However Emacs users
normally do not use the mouse very much. Maybe some newcomers do.

Re: delete-selection-mode

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

[snip]

> It is valid, but an O(1) type of argument.  It will not outweigh O(n)
> arguments even with a small factor eventually.  If something costs time
> repeatedly, saving startup time is not worth the trouble when we are
> catering about being efficient on a continuing base.

Saving startup time is one of the most important qualities a product can
have. Otherwise the potential user wonders "should I invest so much
effort on this?"

I gave up on Emacs twice before someone who I highly respect recommended
it to me. That was the needed motivation for the painful process of
adapting my habits to Emacs. Since years ago, young users need a strong
motivation for switching to Emacs as it is no longer an editor that
provides obvious benefits over competing products.

People will start using Emacs thanks to the availability of modes for
almost all languages, or thanks to features like org-mode. Nobody will
start using Emacs for enjoying the virtues of micro features that go
against their learned practice. You can try preaching those features on
them, but always *after* they are converted to Emacs. Otherwise you risk
scaring them away.

Really, Emacs need to lower the entry barrier as much as possible if we
want to attract new users.

[snip]

Re: delete-selection-mode

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>
> [snip]
>
>> It is valid, but an O(1) type of argument.  It will not outweigh O(n)
>> arguments even with a small factor eventually.  If something costs time
>> repeatedly, saving startup time is not worth the trouble when we are
>> catering about being efficient on a continuing base.
>
> Saving startup time is one of the most important qualities a product
> can have.

"appealing", not "important".

> Since years ago, young users need a strong motivation for switching to
> Emacs as it is no longer an editor that provides obvious benefits over
> competing products.
>
> People will start using Emacs thanks to the availability of modes for
> almost all languages, or thanks to features like org-mode.

At one point of time you will have to decide either arguing that Emacs
provides obvious benefits over competing products, or not.

When your argument requires _both_ premises, it is worthless.

> Really, Emacs need to lower the entry barrier as much as possible if
> we want to attract new users.

That goal takes a second place to providing the best editor to long-term
users.  Keeping old users is more important than attracting new ones.
Since new ones eventually become old ones anyway.

-- 
David Kastrup

Re: delete-selection-mode

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

>> Saving startup time is one of the most important qualities a product
>> can have.
>
> "appealing", not "important".

To be appealing is very important.

>> Since years ago, young users need a strong motivation for switching to
>> Emacs as it is no longer an editor that provides obvious benefits over
>> competing products.
>>
>> People will start using Emacs thanks to the availability of modes for
>> almost all languages, or thanks to features like org-mode.
>
> At one point of time you will have to decide either arguing that Emacs
> provides obvious benefits over competing products, or not.

I can expose Emacs' benefits to others. Another issue (and that was what
I was talking about) is that potential users perceive them as such
*overall*. That means that they must reach the conclussion that Emacs'
benefits are compelling enough to make the effort of switching. If
switching is hard, you'll need very strong benefits, and those are
diminishing as other editors turns better.

> When your argument requires _both_ premises, it is worthless.
>
>> Really, Emacs need to lower the entry barrier as much as possible if
>> we want to attract new users.
>
> That goal takes a second place to providing the best editor to long-term
> users.

Both things can be achieved.

> Keeping old users is more important than attracting new ones.

Who is going to stop using Emacs because he doesn't want to add a few
setq's to his .emacs file?

> Since new ones eventually become old ones anyway.

You are assuming that there will be new ones.

Re: delete-selection-mode

[Stefan Monnier]

> At one point of time you will have to decide either arguing that Emacs
> provides obvious benefits over competing products, or not.

Compared to things like Eclipse, I see the following significant
advantages:

- does not impose a particular workflow or combination of tools.

That's it.  To me there are of course many more advantages (e.g. it also
works in a tty; I can read my email with it reusing the familiar and
powerful editing features; lightweight (who'd have thought!?); ...).


        Stefan

RE: delete-selection-mode

[Drew Adams]

> > At one point of time you will have to decide either arguing 
> > that Emacs provides obvious benefits over competing products,
> > or not.
> 
> Compared to things like Eclipse, I see the following significant
> advantages:
> 
> - does not impose a particular workflow or combination of tools.
> 
> That's it.  To me there are of course many more advantages 
> (e.g. it also works in a tty; I can read my email with it
> reusing the familiar and powerful editing features; lightweight
> (who'd have thought!?); ...).

Please, folks, lets keep to the topic as raised by Juri: `whether the default
should be d-s-mode or just t-m-mode'.

Why submerge that pointed topic under a sea of general discussion about Emacs vs
The Other? Doing that helps ensure that the real topic will be lost and go
nowhere. Please start another thread for the general stuff.

There really is only one question to discuss in this thread: "Which is better as
the default behavior, d-s-mode or t-m-mode?". T-m-mode is the current default;
Juri proposed changing the default to d-s-mode.

That question is plenty big enough. We can still bring in questions of who the
default behavior (for this) should be most aimed at, and other relevant
questions that have already been broached.

But it works against deciding the question at hand to widen the discussion to
anything and everything about Emacs and various ways of using Emacs.

Re: delete-selection-mode

[Juri Linkov]

> Please, folks, lets keep to the topic as raised by Juri: `whether the default
> should be d-s-mode or just t-m-mode'.

Why not discuss other related questions at the same time?
Or do you object for doing this without changing the Subject line?

> That question is plenty big enough. We can still bring in questions of who the
> default behavior (for this) should be most aimed at, and other relevant
> questions that have already been broached.

Maybe this question needs a poll.  I suspect the outcome will be
something around 95% vs 5% ;-)

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

RE: delete-selection-mode

[Drew Adams]

> > Please, folks, lets keep to the topic as raised by Juri: 
> > `whether the default should be d-s-mode or just t-m-mode'.
> 
> Why not discuss other related questions at the same time?
> Or do you object for doing this without changing the Subject line?

Well, I already mentioned that _related_ questions were appropriate (in the very
text you quote below: "other relevant questions").

What can defeat dealing with the topic at hand are the wide-open, far-ranging
discussions about Emacs vs other editors (without regard to the question of text
selection) or keyboard vs mouse or no t-m-mode vs t-m-mode; etc.

There's nothing wrong with questions that relate to the question at hand and
help us find its answer. But throwing up arguments against the use of t-m-mode
is essentially drowning the fish, whether intentional or not.

> > That question is plenty big enough. We can still bring in 
> > questions of who the default behavior (for this) should be
> > most aimed at, and other relevant questions that have
> > already been broached.
> 
> Maybe this question needs a poll.  I suspect the outcome will be
> something around 95% vs 5% ;-)

I've heard talk of user polls for quite some time now. RMS brings it up
occasionally. I have yet to see a user poll, however. I know that Richard has
said that polls were carried out sometimes in the past.

User polls can provide useful info. On their own, they don't (shouldn't) decide
a question, but their info can be helpful input when deciding.

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Please, folks, lets keep to the topic as raised by Juri: `whether the
>> default should be d-s-mode or just t-m-mode'.
>
> Why not discuss other related questions at the same time?
> Or do you object for doing this without changing the Subject line?
>
>> That question is plenty big enough. We can still bring in questions
>> of who the default behavior (for this) should be most aimed at, and
>> other relevant questions that have already been broached.
>
> Maybe this question needs a poll.  I suspect the outcome will be
> something around 95% vs 5% ;-)

The German graphics card provider ELSA at one time produced high end
graphics cards.  Then they also provided more affordable cards.  Their
cards were renowned for driver support for whatever you threw at them:
X11, NextStep, OS/2, Windows (including NT which was quite different at
that time), DOS and so on, working well.

People in charge of acquiring computer parts picked them in spite of
having to fork over a few more DM.  Not all that much, but noticeably.
At least 95% of those cards ended up in Windows PCs.  While those making
the technical decisions often used other operating systems personally,
that's what the bulk of the deployed cards worked in.

Then the company decided to go optimize the expensive 5% away, compete
in the Windows-only market, with Windows-only support.

There was no real or virtual incentive left for paying the premium.
They went bust by focusing on the 95% exclusively.

If we focus on being attractive to those users who never read a manual
and never learn more than a few keystrokes, we will foster users who
don't care about anything, have no compelling reason, whether moral or
technical, to stay with Emacs, and will never reach the level where they
contribute back.

There is nothing wrong with that, but there is nothing right with that
either.  It is not an important metric.

-- 
David Kastrup

Re: delete-selection-mode

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Compared to things like Eclipse, I see the following significant
> advantages:
>
> - does not impose a particular workflow or combination of tools.

Yeah, that's what drives me crazy about Eclipse... it has some very
powerful features (and even a vaguely usable Emacs-key-bindings mode),
but it feels so _rigid_... :(

-Miles

-- 
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city.  Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere
islands of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]

Re: delete-selection-mode

[Juri Linkov]

> Keeping old users is more important than attracting new ones.
> Since new ones eventually become old ones anyway.

I suspect old users who won't like delete-selection-mode,
already turned transient-mark-mode off anyway.
So enabling delete-selection-mode should not affect them.

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

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Keeping old users is more important than attracting new ones.
>> Since new ones eventually become old ones anyway.
>
> I suspect old users who won't like delete-selection-mode,
> already turned transient-mark-mode off anyway.

I am not an old user then, and neither is Richard (I think that he stays
with the defaults in that respect).

So wrong on count #1.

> So enabling delete-selection-mode should not affect them.

    delete-selection-mode is an interactive autoloaded Lisp function in
    `delsel.el'.

[...]

    When Delete Selection mode is enabled, Transient Mark mode is also
    enabled and typed text replaces the selection if the selection is
    active.  Otherwise, typed text is just inserted at point regardless
    of any selection.

So wrong on count #2 as well.

-- 
David Kastrup

Re: delete-selection-mode

[Stefan Monnier]

>> So enabling delete-selection-mode should not affect them.

>     delete-selection-mode is an interactive autoloaded Lisp function in
>     `delsel.el'.

> [...]

>     When Delete Selection mode is enabled, Transient Mark mode is also
>     enabled and typed text replaces the selection if the selection is
>     active.  Otherwise, typed text is just inserted at point regardless
>     of any selection.

> So wrong on count #2 as well.

I take it for granted that if we enable something like
delete-selection-mode, we'll only make it do something when the region
is active, so people who turned t-m-m off will only be affected when
they do C-u C-x C-x or when they do C-SPC C-SPC to explicitly activate
the region (or when they select with the mouse).  In this sense, people
who turned off t-m-m pretty much won't be affected.


        Stefan

RE: delete-selection-mode

[Drew Adams]

> I take it for granted that if we enable something like
> delete-selection-mode, we'll only make it do something when the region
> is active, so people who turned t-m-m off will only be affected when
> they do C-u C-x C-x or when they do C-SPC C-SPC to explicitly activate
> the region (or when they select with the mouse).  In this 
> sense, people who turned off t-m-m pretty much won't be affected.

Absolutely.

Re: delete-selection-mode

[Juri Linkov]

>>> So enabling delete-selection-mode should not affect them.
>
>>     delete-selection-mode is an interactive autoloaded Lisp function in
>>     `delsel.el'.
>
>> [...]
>
>>     When Delete Selection mode is enabled, Transient Mark mode is also
>>     enabled and typed text replaces the selection if the selection is
>>     active.  Otherwise, typed text is just inserted at point regardless
>>     of any selection.
>
>> So wrong on count #2 as well.
>
> I take it for granted that if we enable something like
> delete-selection-mode, we'll only make it do something when the region
> is active, so people who turned t-m-m off will only be affected when
> they do C-u C-x C-x or when they do C-SPC C-SPC to explicitly activate
> the region (or when they select with the mouse).  In this sense, people
> who turned off t-m-m pretty much won't be affected.

Yes, this is exactly what I meant.  That's why I said "delete-selection-mode
SHOULD NOT affect them".  Sorry I didn't elaborate more in my previous post.

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

Re: delete-selection-mode

[Manoj Srivastava]

On Thu, Mar 18 2010, Stefan Monnier wrote:


> I take it for granted that if we enable something like
> delete-selection-mode, we'll only make it do something when the region
> is active, so people who turned t-m-m off will only be affected when
> they do C-u C-x C-x or when they do C-SPC C-SPC to explicitly activate
> the region (or when they select with the mouse).  In this sense, people
> who turned off t-m-m pretty much won't be affected.

        I like the functionality of highlighting the region whenever the
 mark is active -- which is the only reason I have t-m-m turned on. Is
 there another way of achieving that, without having all the highlighted
 region disappearing on me accidentally, as it does now?

        manoj
-- 
"The Amiga is the only personal computer where you can run a multitasking
operating system and get realtime performance, out of the box."-- Peter da Silva
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Re: delete-selection-mode

[David Kastrup]

Manoj Srivastava <srivasta@ieee.org> writes:

> On Thu, Mar 18 2010, Stefan Monnier wrote:
>
>
>> I take it for granted that if we enable something like
>> delete-selection-mode, we'll only make it do something when the region
>> is active, so people who turned t-m-m off will only be affected when
>> they do C-u C-x C-x or when they do C-SPC C-SPC to explicitly activate
>> the region (or when they select with the mouse).  In this sense, people
>> who turned off t-m-m pretty much won't be affected.
>
>         I like the functionality of highlighting the region whenever
>  the mark is active -- which is the only reason I have t-m-m turned
>  on. Is there another way of achieving that, without having all the
>  highlighted region disappearing on me accidentally, as it does now?

While I would love to use your experience to bolster my stance,
delete-selection-mode has not been enabled by default yet.

So it would appear that we should find a different culprit.  Either
delete-selection-mode has been enabled by your distribution defaults, or
you are experiencing a different problem.

It would be good to know.  Do you consider any of the following likely?

a) you marked the region with the mouse, then hit DEL or backspace.
   This currently deletes the whole active region.

b) you clicked on one end of the region with mouse-3 _twice_.  That is
   the Emacs way to kill a region with the mouse.

I don't have a good idea what, short of delete-selection-mode, would
cause your pains.  So what is the output of

M-: delete-selection-mode RET

for you?

-- 
David Kastrup

Re: delete-selection-mode

[Manoj Srivastava]

On Sun, Mar 21 2010, David Kastrup wrote:

> Manoj Srivastava <srivasta@ieee.org> writes:
>
>> On Thu, Mar 18 2010, Stefan Monnier wrote:
>>
>>
>>> I take it for granted that if we enable something like
>>> delete-selection-mode, we'll only make it do something when the region
>>> is active, so people who turned t-m-m off will only be affected when
>>> they do C-u C-x C-x or when they do C-SPC C-SPC to explicitly activate
>>> the region (or when they select with the mouse).  In this sense, people
>>> who turned off t-m-m pretty much won't be affected.
>>
>>         I like the functionality of highlighting the region whenever
>>  the mark is active -- which is the only reason I have t-m-m turned
>>  on. Is there another way of achieving that, without having all the
>>  highlighted region disappearing on me accidentally, as it does now?
>
> While I would love to use your experience to bolster my stance,
> delete-selection-mode has not been enabled by default yet.
>
> So it would appear that we should find a different culprit.  Either
> delete-selection-mode has been enabled by your distribution defaults, or
> you are experiencing a different problem.
>
> It would be good to know.  Do you consider any of the following likely?
>
> a) you marked the region with the mouse, then hit DEL or backspace.
>    This currently deletes the whole active region.

        I often use my mouse to highlight the region. I might have hit
 backspace, though I thinhk it is more likely that I pasted something
 with my mouse. Could that have caused the region to be delete?

        (I have now set it so that only [delete] actually depetes the
 highlighted region, not backspace or c-d)

> b) you clicked on one end of the region with mouse-3 _twice_.  That is
>    the Emacs way to kill a region with the mouse.

        No, that I was aware of, and my fingers  are trained not to do so.

> I don't have a good idea what, short of delete-selection-mode, would
> cause your pains.  So what is the output of
>
> M-: delete-selection-mode RET
>
> for you?

        Well, it is nil now.  I do not think I it turned on, though. I
 definitely know that I would _not_ want it turned on; and I would like
 to request the Emacs developers to consider that long time Emacs users
 who are not necesarrily elisp experts or follow eacs devel list are
 also a resource that should nto be squandered; and so _always_
 prioritizing potential new users over older users might turn out to be
 counter productive.

        The potential new users are often fickel, us old times have
 loyally stuck with  Emacs. Changing the defauls ought to come with
 warnings, and explicit instructions on how to get the old behaviour
 back, for those of us who merely use Emacs as a tool, and do not follow
 development. 

        I still miss the old behaviour of copying text by using
 shift-button 3 over an area of text to past the text at point (though I
 now have a local hack to enable it for me)

        manoj
-- 
Q: How many WASPs does it take to change a lightbulb? A: One.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Re: delete-selection-mode

[Lennart Borgman]

On Sun, Mar 21, 2010 at 4:33 PM, Manoj Srivastava <srivasta@ieee.org> wrote:
>
> Changing the defauls ought to come with
>  warnings, and explicit instructions on how to get the old behaviour
>  back, for those of us who merely use Emacs as a tool, and do not follow
>  development.

That is a good suggestion. Maybe there should be a speical section in
News for this? (BTW, should perhaps etc/news now use org-mode?)

Re: delete-selection-mode

[Richard Stallman]

I have had delete-selection-mode enabled for several days
and I have not noticed it at all.  It's possible that it caused
a deleteion I did not notice, but I don't think so.

This personal experience is not enough to convince me that it is ok to
make self-inserting chars delete the region when it was activated with
C-SPC.  Different people have different editing styles.
I activate the region very rarely; someone else who uses it more
might experience more problems.

It would be good to get reports from other people about how it affects
them.

Re: delete-selection-mode

[Harald Hanche-Olsen]

+ David Kastrup <dak@gnu.org>:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
> 
> > On Wed, Mar 17, 2010 at 3:35 PM, Alan Mackenzie <acm@muc.de> wrote:
> > [...]
> > to from other applications. They want that exactly because it saves
> > them time
> 
> Once.
> 
> > and avoids confusion (which also costs them time).
> >
> > I for one agree with that argument.
> 
> It is valid, but an O(1) type of argument.  It will not outweigh O(n)
> arguments even with a small factor eventually.

Surely, O(n) outweighs O(1), but I am not convinced that the argument
is O(1). I can only offer anecdotal evidence (myself). I have been an
emacs user since the late '80s; I can certainly remember 18.54 being
THE emacs for a long time. As a result, I am far from mouse centric,
and I pretty much have most basic emacs keystrokes firmly embedded in
my muscle memory.

However, I do an ever increasing amount of text entry in things that
aren't emacs: In web browsers (that web 2.0 thing), in computer
algebra systems with their own GUIs, in OpenOffice, and even (hating
every keystroke, but sometimes a man's gotta do what a man's gotta do)
MS Word, and they ALL behave in you-know-what way. As a result, habits
from those other places have started encroaching on my ingrained emacs
habits, and I now do find myself, with distressing regularity, trying
to delete the selection in emacs by just typing. For my part, this has
ceased being an O(1) phenomenon and is now strictly O(n). So I'll
experiment with having del-sel-mode turned on from now on. I didn't
know it existed - imagine that! It's been around since 1992, if the
comments in delsel.el are to be believed.

I won't take a firm stand on whether it should be made default, but if
not, I agree with those who say its existence needs to be made
abundantly clear to users - in whatever fashion this can be done.

- Harald

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Richard Stallman]

Someone (Alan) wrote:

    > You have misconstrued Richard's post.  He went on to say that what is
    > useful for newcomers isn't necessarily what they expect or "want".
    > There's thus no indication there that he would support the rest of your
    > argument.

He is right about what I said, as a general point.
Whether it is relevant to this issue, I am not sure.

If delete-selection-mode affects only what DEL does after a
mouse-selection, then it should have no effect on editing in the
normal Emacs way with keyboard commands.  Perhaps there is no
particular reason to do, here, anything other than what beginning
users ask for.

Re: delete-selection-mode

[Stefan Monnier]

> If delete-selection-mode affects only what DEL does after a
> mouse-selection, then it should have no effect on editing in the
> normal Emacs way with keyboard commands.  Perhaps there is no
> particular reason to do, here, anything other than what beginning
> users ask for.

It does have many more effects.  The most significant one is that any
self-inserting key typed when the region is active will cause the region
to be deleted before the char is inserted.

If the fact that the region is active at that point "is right"
(i.e. you indeed intended to highlight that region), then deleting it is
probably the right thing to do.

But if the region is active by accident (e.g. the fact that it's
highlighted is something you grudgingly live with since t-m-m was made
the default), then you may get annoyed that merely inserting a char at
point ends up deleting all the text that happened to be highlighted.

I think delete-selection-mode makes sense, FWIW, but I can also see that
it might annoy some users, although these should pretty much only be the
users who don't like t-m-m but don't hate it enough to go through the
trouble of turning it off.  Not sure how many of them might be
out there.


        Stefan

Re: delete-selection-mode

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> If the fact that the region is active at that point "is right"
> (i.e. you indeed intended to highlight that region), then deleting it is
> probably the right thing to do.
>
> But if the region is active by accident (e.g. the fact that it's
> highlighted is something you grudgingly live with since t-m-m was made
> the default), then you may get annoyed that merely inserting a char at
> point ends up deleting all the text that happened to be highlighted.

Yeah, and what's worse is if a _little_ text is inadvertently
highlighted (say, a single comma or a space, because you accidentally
dragged a little whwen you meant to click), and you don't actually
notice it being deleted when you start typing...

I'm burned by that regularly in other apps, to the point where I think
"deletion upon typing" is a positively harmful feature.  Viewed in
isolation, it's "clever", but really offers nothing significant over
just hitting DEL before typing. in a general context (i.e., not in a
specialized context like a browser address bar).

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: delete-selection-mode

[Richard Stallman]

    It does have many more effects.  The most significant one is that any
    self-inserting key typed when the region is active will cause the region
    to be deleted before the char is inserted.

Is this true even when the region has been activated by keyboard commands?
If so, perhaps it is a bug.  Perhaps the feature should only apply when
you make the region using the mouse.

It would be useful to see precisely what the beginners said who
complained about the current defaults.  What were their use cases?
Did they make the selections with the mouse, or with the keyboard?
Writing to them now to discuss this could also be useful.

My guess is that they were using the mouse to select, and that they
would be happy if we made mouse-made selections interact with the
following editing in the way they are used to, while keyboard-made
selections could act in the traditional Emacs way.

This might make everyone happy, and we could painlessly make it the
new default.

I could also be mistaken, so it is useful to see what they say
about the idea.

Re: delete-selection-mode

[Lennart Borgman]

On Thu, Mar 18, 2010 at 5:37 PM, Richard Stallman <rms@gnu.org> wrote:
>    It does have many more effects.  The most significant one is that any
>    self-inserting key typed when the region is active will cause the region
>    to be deleted before the char is inserted.
>
> Is this true even when the region has been activated by keyboard commands?
> If so, perhaps it is a bug.  Perhaps the feature should only apply when
> you make the region using the mouse.


I think it would be a very bad idea to introduce an invisible state
this way. (I agree with Klaus here - if I do not misunderstand him.)


> It would be useful to see precisely what the beginners said who
> complained about the current defaults.  What were their use cases?


I think they simple want the behaviour that they are used to from
editing taks in other application. (This requirement is the really big
obstacle not only for Emacs but for the whole free software movement.)

AW: delete-selection-mode

[Berndl, Klaus]

On Thu, Mar 18, 2010 at 5:37 PM, Richard Stallman <rms@gnu.org> wrote:
>>>    It does have many more effects.  The most significant one is that any
>>>    self-inserting key typed when the region is active will cause the region
>>>    to be deleted before the char is inserted.
>
>> Is this true even when the region has been activated by keyboard commands?
>> If so, perhaps it is a bug.  Perhaps the feature should only apply when
>> you make the region using the mouse.

>I think it would be a very bad idea to introduce an invisible state
>this way. (I agree with Klaus here - if I do not misunderstand him.)

You have understood right. It should not matter if the selection has been
made by mouse or keyboard. This yould be very inconsistant and even more confusing.
I intentionally write "selection" and not "region" because what i have i mind is
the concept that a user can highlight some text and then can do something with it.
Because this is named a selection in all other apps i name it also selection.
Probably t-m-m active is the equivalent in emacs. I write "probably" because currently
there are too many confusing screws for this and similar toics: there is t-m-m,
there is d-s-m, there is cua-mode, there is mouse-region-delete-keys and probably
some other i have never heard...

1. Emacs should support exactly this "selection" conxept in exactly that way all other
   apps does
2. This should be the default behavior
3. There should as few as possible screws to modify the behavior - currently there are too
   many and i assume some of them are not really disjunct but somehow overlapping.

Re: delete-selection-mode

[Harald Hanche-Olsen]

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

> On Thu, Mar 18, 2010 at 5:37 PM, Richard Stallman <rms@gnu.org> wrote:
> > Is this true even when the region has been activated by keyboard commands?
> > If so, perhaps it is a bug.  Perhaps the feature should only apply when
> > you make the region using the mouse.
> 
> 
> I think it would be a very bad idea to introduce an invisible state
> this way. (I agree with Klaus here - if I do not misunderstand him.)

One way to solve that might be to use a different face for the region
depending on whether it was mouse selected or keyboard generated.
Maybe using a more scary (reddish?) colour if typing something is
going to delete it.

- Harald

Re: delete-selection-mode

[Richard Stallman]

    > It would be useful to see precisely what the beginners said who
    > complained about the current defaults.  What were their use cases?

    I think they simple want the behaviour that they are used to from
    editing taks in other application.

I am sure that is true, but the question is a specific one.
Precisely which use cases are these people concerned about?

Re: delete-selection-mode

[Chad Brown]

On Mar 19, 2010, at 8:56 AM, Richard Stallman wrote:

>> It would be useful to see precisely what the beginners said who
>> complained about the current defaults.  What were their use cases?
> 
>    I think they simple want the behaviour that they are used to from
>    editing taks in other application.
> 
> I am sure that is true, but the question is a specific one.
> Precisely which use cases are these people concerned about?

Back when I was in a position to notice on a day-to-day basis (helping newly arrived college students used to `home computers' adapt to MIT's campus-wide unix workstation infrastructure), the use case seemed to be:

* start an editor (emacs was the default editor, so it would be started in a great number of different contexts)
* somehow generate text
* sweep out an area with the mouse
* type replacement text

I saw much confusion when people noticed that the replacement text was added rather than replacing, and also frequent situations where the user had clearly simply assumed that the text was being replaced and didn't notice that it wasn't (fortunately, they'd often catch these cases on a spell-check step, since the usual selection mechanism resulted in the added text being glommed directly on to the end of the intended-replaced text).

I'm my observations, users who created/extended the selection using the keyboard were quite rare, and I would be comfortable saying that they were all familiar enough with emacs to be aware of the situation (and either work around or customize around it).  This experience is not particularly recent, but everything I have seen with new users since then suggests that this sort of interaction is even more strongly ingrained in users (since so many of them generate their early user experiences inside web browsers, including text edit boxes).

I hope this helps,
*Chad

Re: delete-selection-mode

[Richard Stallman]

    * start an editor (emacs was the default editor, so it would be started in a great number of different contexts)
    * somehow generate text
    * sweep out an area with the mouse
    * type replacement text

Thanks.  That is what I would have guessed.
So they care what happens when they type a self-inserting character
after mouse-selection, but they don't care what happens
when they type a self-inserting character after C-SPC selection
or C-x C-x selection.

However, note what Alan wrote.  Maybe some of the users of
those other programs think that Emacs is better.

    > I've just spoken to my sister, an "ordinary" computer user.  She says
    > she normally uses the <delete> key after marking text before typing
    > further.  She also gets annoyed "every now and then" when marked text
    > gets accidentally deleted by typing, though "it's not too bad" if
    > there's an undo key sequence.

    Yes, that is normal today since that is how it works during most of
    the editing people do today.

Alan's point is that one ordinary user dislikes what most programs do
today.  She dislikes it in the other programs, and she would dislike
it in Emacs too if we made Emacs do it.

Re: delete-selection-mode

[Lennart Borgman]

On Sat, Mar 20, 2010 at 3:24 AM, Richard Stallman <rms@gnu.org> wrote:
>
>    > I've just spoken to my sister, an "ordinary" computer user.  She says
>    > she normally uses the <delete> key after marking text before typing
>    > further.  She also gets annoyed "every now and then" when marked text
>    > gets accidentally deleted by typing, though "it's not too bad" if
>    > there's an undo key sequence.
>
>    Yes, that is normal today since that is how it works during most of
>    the editing people do today.
>
> Alan's point is that one ordinary user dislikes what most programs do
> today.  She dislikes it in the other programs, and she would dislike
> it in Emacs too if we made Emacs do it.


I happened to dislike it myself the first time it happened to me.
However I got used to it. There could be other ways but I can see no
real reason they are better (at least not the versions I can think
of).

My conclusion here is: follow the de facto standards - as long as the
key sequences used belongs to these standards.

Re: delete-selection-mode

[Uwe Siart]

Richard Stallman <rms@gnu.org> writes:

> However, note what Alan wrote.  Maybe some of the users of
> those other programs think that Emacs is better.
> [...]
> Alan's point is that one ordinary user dislikes what most programs do
> today.  She dislikes it in the other programs, and she would dislike
> it in Emacs too if we made Emacs do it.

Absolutely right. That's the point. Full ACK. So called "modern user
interfaces" really suck. To tell my story I came to Emacs exactly
because I hated the way how other editors work. Can't work with 'em.
They drive me crazy with their buttons and tabs. Emacs is a lot better.
But certainly you have to practice it just like you have to practice
playing musical instruments. But you can't seriously argue that an
electronic toy keyboard is better than a grand piano because newbies get
faster results with it.

Please don't adapt Emacs too much to "modern applications". We don't
need this. There are plenty such editors for those who like them. What
we need is Emacs as an efficient alternative to those crappy user
interfaces everywhere around.

-- 
Uwe

Re: delete-selection-mode

[Richard Stallman]

We have testimony that some ordinary users want self-inserting
characters to delete the region (which they have made with the mouse).
We have testimony that one ordinary user thinks that same behavior is
a pain.  I am sure both reports are factually accurate, but where do
we go from there?

It would be useful to find out what some larger number of ordinary
users think.  How many want self-inserting characters to delete the
mouse-selected region, how many are glad it doesn't, and how many
don't care?

Re: delete-selection-mode

[Lennart Borgman]

On Sat, Mar 20, 2010 at 5:49 PM, Richard Stallman <rms@gnu.org> wrote:
> We have testimony that some ordinary users want self-inserting
> characters to delete the region (which they have made with the mouse).
> We have testimony that one ordinary user thinks that same behavior is
> a pain.  I am sure both reports are factually accurate, but where do
> we go from there?

That user is probably not very used to computers. An experienced user
will think this is natural since almost all editing environment
behaves this way.

And most new user will be very used to computers. So to me the way to
go seems very clear.

Re: delete-selection-mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> We have testimony that some ordinary users want self-inserting
> characters to delete the region (which they have made with the mouse).
> We have testimony that one ordinary user thinks that same behavior is
> a pain.  I am sure both reports are factually accurate, but where do
> we go from there?
>
> It would be useful to find out what some larger number of ordinary
> users think.  How many want self-inserting characters to delete the
> mouse-selected region, how many are glad it doesn't, and how many
> don't care?

With mouse-selected regions, I don't care.  Alan has stated that he
often inadvertantly marks one-character regions when intending to merely
position.  I don't think that this happens often to me.

With shift-selected regions, I don't care either.

Both selection methods are something that focuses on marking a region: I
don't think one would use shift-cursor movements just so that one can
jump backwards conveniently with C-x C-x.

We don't want too many different region types if it can be avoided.

I we might all be able to get agreement on the following (anybody in
disagreement please holler):

Let's make shift-selection and mouse-selection _identical_ with regard
to the outcome, with regard to visuals and semantics.

Both of those selection methods (unless done accidentally) very much
focus on marking a _region_, not on putting point somewhere and cleverly
leaving a mark somewhere else.

I think (or hope so) that we all can converge on _those_ two cases
better being the same.  And I don't even think we need customization to
allow making them different.  I would also think shift-extending a mouse
region and vice versa should work fine.  So I don't think we need to
keep a history telling those two things apart.

If we can all agree on that, we have removed some of the complexity for
further decisions.

-- 
David Kastrup

AW: delete-selection-mode

[Berndl, Klaus]

Fully agree with David - IMHO a very constructive and success-oriented suggestion.
_marking_ a region with mouse or shifted keys - as described by David - should be handled
in the same way and should be handled exactly as by all other apps (in the world ;-)

Klaus
________________________________________
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] im Auftrag von David Kastrup [dak@gnu.org]
Gesendet: Samstag, 20. März 2010 18:15
An: emacs-devel@gnu.org
Betreff: Re: delete-selection-mode

Richard Stallman <rms@gnu.org> writes:

> We have testimony that some ordinary users want self-inserting
> characters to delete the region (which they have made with the mouse).
> We have testimony that one ordinary user thinks that same behavior is
> a pain.  I am sure both reports are factually accurate, but where do
> we go from there?
>
> It would be useful to find out what some larger number of ordinary
> users think.  How many want self-inserting characters to delete the
> mouse-selected region, how many are glad it doesn't, and how many
> don't care?

With mouse-selected regions, I don't care.  Alan has stated that he
often inadvertantly marks one-character regions when intending to merely
position.  I don't think that this happens often to me.

With shift-selected regions, I don't care either.

Both selection methods are something that focuses on marking a region: I
don't think one would use shift-cursor movements just so that one can
jump backwards conveniently with C-x C-x.

We don't want too many different region types if it can be avoided.

I we might all be able to get agreement on the following (anybody in
disagreement please holler):

Let's make shift-selection and mouse-selection _identical_ with regard
to the outcome, with regard to visuals and semantics.

Both of those selection methods (unless done accidentally) very much
focus on marking a _region_, not on putting point somewhere and cleverly
leaving a mark somewhere else.

I think (or hope so) that we all can converge on _those_ two cases
better being the same.  And I don't even think we need customization to
allow making them different.  I would also think shift-extending a mouse
region and vice versa should work fine.  So I don't think we need to
keep a history telling those two things apart.

If we can all agree on that, we have removed some of the complexity for
further decisions.

--
David Kastrup

Re: AW: delete-selection-mode

[David Kastrup]

"Berndl, Klaus" <klaus.berndl@capgemini-sdm.com> writes:

> Fully agree with David - IMHO a very constructive and success-oriented
> suggestion.  _marking_ a region with mouse or shifted keys - as
> described by David - should be handled in the same way

That was my suggestion.

> and should be handled exactly as by all other apps (in the world ;-)

That was supposed to be left open to customization and default
discussions.

-- 
David Kastrup

Re: delete-selection-mode

[Richard Stallman]

    Let's make shift-selection and mouse-selection _identical_ with regard
    to the outcome, with regard to visuals and semantics.

That seems like a good idea to me.

Re: delete-selection-mode

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Let's make shift-selection and mouse-selection _identical_ with regard
>     to the outcome, with regard to visuals and semantics.
>
> That seems like a good idea to me.

_All_ types of visible selection should be the same, including t-m-m
(C-SPC + movement) selections, to the greatest extent possible.

Having multiple "types" of selection that are
sorta-the-same-but-sorta-different is just going to make Emacs harder to
use for everybody, and harder to learn for beginners.

If a beginner tries to use (superior) Emacs-style marking (t-m-m),
suddenly habits which seemed to work for them when using the mouse will
fail.  This is bad.

If an expert user wants to use DEL to delete a t-m-m region, that will
fail, for no good reason.  This is stupid.

Yeah, I know, mouse-selection is currently "special".   It shouldn't
be -- that was a bad decision.  Adding shift-selection to the mix just
makes things worse.

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: delete-selection-mode

[Juri Linkov]

> Richard Stallman <rms@gnu.org> writes:
>>     Let's make shift-selection and mouse-selection _identical_ with regard
>>     to the outcome, with regard to visuals and semantics.
>>
>> That seems like a good idea to me.
>
> _All_ types of visible selection should be the same, including t-m-m
> (C-SPC + movement) selections, to the greatest extent possible.
>
> Having multiple "types" of selection that are
> sorta-the-same-but-sorta-different is just going to make Emacs harder to
> use for everybody, and harder to learn for beginners.
>
> If a beginner tries to use (superior) Emacs-style marking (t-m-m),
> suddenly habits which seemed to work for them when using the mouse will
> fail.  This is bad.
>
> If an expert user wants to use DEL to delete a t-m-m region, that will
> fail, for no good reason.  This is stupid.
>
> Yeah, I know, mouse-selection is currently "special".   It shouldn't
> be -- that was a bad decision.  Adding shift-selection to the mix just
> makes things worse.

Unfortunately, shift-selection is already fundamentally different
from selecting the region with C-SPC and C-x C-x.  With shift-selection
typing a key that is not shift-translated deactivates the region.
It seems this difference is impossible to avoid because typing non-shifted
keys is how beginners expect to deselect the region.

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

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> Unfortunately, shift-selection is already fundamentally different from
> selecting the region with C-SPC and C-x C-x.  With shift-selection
> typing a key that is not shift-translated deactivates the region.  It
> seems this difference is impossible to avoid because typing
> non-shifted keys is how beginners expect to deselect the region.

My original point was to make shift-selection the same as
mouse-selection.  I don't know shift-selection well enough to say with
confidence that your argument would also apply to folding it with
mouse-selection.  I don't think so.

-- 
David Kastrup

Re: delete-selection-mode

[Lennart Borgman]

On Mon, Mar 22, 2010 at 2:04 AM, Miles Bader <miles@gnu.org> wrote:
>
> Having multiple "types" of selection that are
> sorta-the-same-but-sorta-different is just going to make Emacs harder to
> use for everybody, and harder to learn for beginners.


Could you please be more specific? This is a bit too general to be
understandable.

If you for example mean that shift selection should go away then I
disagree. If you mean that we should work towards getting selection
working the same whenever possible then I agree.

Howevere moving towards the common denominator for different editing
environments is in my opinion most important. Repeating myself I once
again stress that this needs creativity to not destroy (and any kind
of negative remarks will diminish creativity and may make it
impossible to reach a good result).

Re: delete-selection-mode

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> Having multiple "types" of selection that are
>> sorta-the-same-but-sorta-different is just going to make Emacs harder to
>> use for everybody, and harder to learn for beginners.
>
> Could you please be more specific? This is a bit too general to be
> understandable.
>
> If you for example mean that shift selection should go away then I
> disagree. If you mean that we should work towards getting selection
> working the same whenever possible then I agree.

No, I don't think shift-selection should go away.  It's a fine feature,
helps interoperability, and does not interfere with other Emacs
features.

Shift-selection _is_ inherently "special" in one way:  the region is
deactivated by certain actions, where a t-m-m region wouldn't be.
This is an inherent part of the shift-select interaction model, as
defined externally to Emacs, so it's necessary.  Given the way people
use shift-select, this does not seem a real problem (and there's obvious
visual feedback).

But other than that, shift-selection should be the same as t-m-m-style
selection as far as possible -- for instance, there should not be a
different set of commands available for "shift-selected" regions than
there are for regions created using traditional Emacs commands.

Actually, perhaps a good analogue would be the Emacs shift-select
implementation: it works _consistently_, and shift-selection can be
used with traditional Emacs movement commands (e.g., C-f) exactly the
same as with arrow-keys etc.  This helps people learn Emacs, because
they can gradually extend their command repertoire without
encountering jarring discontinuities in the way things work.  Someone
can learn Emacs-style movement keys while still using shift-selection,
or they can learn Emacs-style selection while still using arrow keys;
because there's no artificial linkage between the two, the learning
curve for traditional Emacs features becomes shallower.  There's no
"windows/mac-style-usage ghetto" in Emacs, and we shouldn't add one.

-Miles

-- 
Virtues, n. pl. Certain abstentions.

Re: delete-selection-mode

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> But other than that, shift-selection should be the same as t-m-m-style
> selection as far as possible -- for instance, there should not be a
> different set of commands available for "shift-selected" regions than
> there are for regions created using traditional Emacs commands.

What commands are you referring to?

Re: delete-selection-mode

[Lennart Borgman]

On Mon, Mar 22, 2010 at 3:04 AM, Miles Bader <miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>> Having multiple "types" of selection that are
>>> sorta-the-same-but-sorta-different is just going to make Emacs harder to
>>> use for everybody, and harder to learn for beginners.
>>
>> Could you please be more specific? This is a bit too general to be
>> understandable.
>>
>> If you for example mean that shift selection should go away then I
>> disagree. If you mean that we should work towards getting selection
>> working the same whenever possible then I agree.
>
> No, I don't think shift-selection should go away.  It's a fine feature,
> helps interoperability, and does not interfere with other Emacs
> features.
>
> Shift-selection _is_ inherently "special" in one way:  the region is
> deactivated by certain actions, where a t-m-m region wouldn't be.
> This is an inherent part of the shift-select interaction model, as
> defined externally to Emacs, so it's necessary.  Given the way people
> use shift-select, this does not seem a real problem (and there's obvious
> visual feedback).
>
> But other than that, shift-selection should be the same as t-m-m-style
> selection as far as possible -- for instance, there should not be a
> different set of commands available for "shift-selected" regions than
> there are for regions created using traditional Emacs commands.


I think some of these problems have been addressed in cua-mode. Maybe
it would be good to use what is in cua-mode more?

Re: delete-selection-mode

[Lennart Borgman]

On Mon, Mar 22, 2010 at 4:29 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> I think some of these problems have been addressed in cua-mode. Maybe
> it would be good to use what is in cua-mode more?


I just found that org-mode failed to support cua-mode. It only
supports shift-select-mode when the option org-support-shift-select is
set.

So the current organisation of this may difficult to support. I
suggest that the support of shift select should be based on that
support in cua-mode. I think that would remove some confusion and make
it easier for both old timers and newcomers. (But the main thing then
is of course that cua-mode does what it is supposed to do.)

Re: delete-selection-mode

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> But other than that, shift-selection should be the same as t-m-m-style
>> selection as far as possible -- for instance, there should not be a
>> different set of commands available for "shift-selected" regions than
>> there are for regions created using traditional Emacs commands.
>
> I think some of these problems have been addressed in cua-mode. Maybe
> it would be good to use what is in cua-mode more?

Er, what "problems" do you mean?  Shift-select (without CUA mode) works
quite well currently.  What I'm arguing against is David/RMS's apparent
goal of making shift-select _worse_...

[and CUA mode is generally such a mess that I'm very skeptical of
adopting anything from it...]

-Miles

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

Re: delete-selection-mode

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>> But other than that, shift-selection should be the same as t-m-m-style
>>> selection as far as possible -- for instance, there should not be a
>>> different set of commands available for "shift-selected" regions than
>>> there are for regions created using traditional Emacs commands.
>>
>> I think some of these problems have been addressed in cua-mode. Maybe
>> it would be good to use what is in cua-mode more?
>
> Er, what "problems" do you mean?  Shift-select (without CUA mode) works
> quite well currently.  What I'm arguing against is David/RMS's apparent
> goal of making shift-select _worse_...

I was proposing folding the semantics of shift-select and mouse-select.
You think that would imply making shift-select worse, but we could
probably achieve it by making mouse-select better instead.

-- 
David Kastrup

Re: delete-selection-mode

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> I was proposing folding the semantics of shift-select and mouse-select.
> You think that would imply making shift-select worse, but we could
> probably achieve it by making mouse-select better instead.

I would support such a move!

-Miles

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

Re: delete-selection-mode

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> I was proposing folding the semantics of shift-select and mouse-select.
> You think that would imply making shift-select worse, but we could
> probably achieve it by making mouse-select better instead.

mouse-select and shift-select semantics are already unified to a large
extent.  Try it: drag a region of text with the mouse, then extend the
region with the shift-arrow keys.  Internally, both work by setting the
value of `transient-mark-mode' to `only'.

Do you have a specific suggestion for improvement?

Re: delete-selection-mode

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I was proposing folding the semantics of shift-select and mouse-select.
>> You think that would imply making shift-select worse, but we could
>> probably achieve it by making mouse-select better instead.
>
> mouse-select and shift-select semantics are already unified to a large
> extent.  Try it: drag a region of text with the mouse, then extend the
> region with the shift-arrow keys.  Internally, both work by setting the
> value of `transient-mark-mode' to `only'.
>
> Do you have a specific suggestion for improvement?

mouse-region-delete-keys

-- 
David Kastrup

Re: delete-selection-mode

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

>> mouse-select and shift-select semantics are already unified to a large
>> extent.  Try it: drag a region of text with the mouse, then extend the
>> region with the shift-arrow keys.  Internally, both work by setting the
>> value of `transient-mark-mode' to `only'.
>>
>> Do you have a specific suggestion for improvement?
>
> mouse-region-delete-keys

Yes, the current plan is to make this apply to all active regions.

Re: delete-selection-mode

[Juri Linkov]

>>> Do you have a specific suggestion for improvement?
>>
>> mouse-region-delete-keys
>
> Yes, the current plan is to make this apply to all active regions.

What do you think about marking commands that should delete the active
region with a new interactive character (like "^" is used to call
`handle-shift-selection'), so e.g. a new function `handle-delete-region'
could delete the active region before running a command?

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

RE: delete-selection-mode

[Drew Adams]

> What do you think about marking commands that should delete the active
> region with a new interactive character (like "^" is used to call
> `handle-shift-selection'), so e.g. a new function
> `handle-delete-region' could delete the active region before
> running a command?

Delete-selection mode has just such a property: `delete-selection'. (But it is
simply a symbol property.)

This is precisely how it allows control over which commands delete the active
region and what behavior that deletion entails. It is the basis/essence of
`delete-selection-mode'.

The possible values of property `delete-selection' are:

kill        - kill region
yank        - delete region; adjust kill-ring for the yank 
supersede   - delete region only (ignore current command)
t (non-nil) - delete region (current command inserts text)

Property values for the commands handled by default:

kill: open-line
yank: (clipboard-)yank
t:    self-insert-(command|iso)
      insert-register
      newline(-and-indent)

As an example of how users can take advantage of this, I put a value of t also
on `insert-parentheses' and
`completion-separator-self-insert-(command|autofilling)' (from completion.el).

Re: delete-selection-mode

[Juri Linkov]

> The possible values of property `delete-selection' are:
>
> kill        - kill region
> yank        - delete region; adjust kill-ring for the yank
> supersede   - delete region only (ignore current command)
> t (non-nil) - delete region (current command inserts text)

Maybe these settings should be moved to simple.el:

(put 'self-insert-command 'delete-selection t)
(put 'self-insert-iso 'delete-selection t)
(put 'yank 'delete-selection 'yank)
(put 'clipboard-yank 'delete-selection 'yank)
(put 'insert-register 'delete-selection t)
(put 'delete-backward-char 'delete-selection 'supersede)
(put 'backward-delete-char-untabify 'delete-selection 'supersede)
(put 'delete-char 'delete-selection 'supersede)
(put 'newline-and-indent 'delete-selection t)
(put 'newline 'delete-selection t)
(put 'open-line 'delete-selection 'kill)

so `handle-delete-region' could use them.

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

Re: delete-selection-mode

[Stefan Monnier]

> Maybe these settings should be moved to simple.el:

> (put 'self-insert-command 'delete-selection t)
> (put 'self-insert-iso 'delete-selection t)
> (put 'yank 'delete-selection 'yank)
> (put 'clipboard-yank 'delete-selection 'yank)
> (put 'insert-register 'delete-selection t)
> (put 'delete-backward-char 'delete-selection 'supersede)
> (put 'backward-delete-char-untabify 'delete-selection 'supersede)
> (put 'delete-char 'delete-selection 'supersede)
> (put 'newline-and-indent 'delete-selection t)
> (put 'newline 'delete-selection t)
> (put 'open-line 'delete-selection 'kill)

> so `handle-delete-region' could use them.

Just as for shift-select-mode, I'd rather not use symbol properties to
put this information, because it's a property of the command, not of
its name.


        Stefan

Re: delete-selection-mode

[Juri Linkov]

>> Maybe these settings should be moved to simple.el:
>
>> (put 'self-insert-command 'delete-selection t)
>> (put 'self-insert-iso 'delete-selection t)
>> (put 'yank 'delete-selection 'yank)
>> (put 'clipboard-yank 'delete-selection 'yank)
>> (put 'insert-register 'delete-selection t)
>> (put 'delete-backward-char 'delete-selection 'supersede)
>> (put 'backward-delete-char-untabify 'delete-selection 'supersede)
>> (put 'delete-char 'delete-selection 'supersede)
>> (put 'newline-and-indent 'delete-selection t)
>> (put 'newline 'delete-selection t)
>> (put 'open-line 'delete-selection 'kill)
>
>> so `handle-delete-region' could use them.
>
> Just as for shift-select-mode, I'd rather not use symbol properties to
> put this information, because it's a property of the command, not of
> its name.

This means introducing 4 new `interactive' code letters for:

;;  'yank
;;      For commands which do a yank; ensures the region about to be
;;      deleted isn't yanked.
;;  'supersede
;;      Delete the active region and ignore the current command,
;;      i.e. the command will just delete the region.
;;  'kill
;;      `kill-region' is used on the selection, rather than
;;      `delete-region'.  (Text selected with the mouse will typically
;;      be yankable anyhow.)
;;  non-nil
;;      The normal case: delete the active region prior to executing
;;      the command which will insert replacement text.

But we are short of available code letters.  And it's not clear
how to choose a letter with good mnemonics for their effects.

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

Re: delete-selection-mode

[Stefan Monnier]

>> Just as for shift-select-mode, I'd rather not use symbol properties to
>> put this information, because it's a property of the command, not of
>> its name.
> This means introducing 4 new `interactive' code letters for:

Of course not.  We can do it without any letter at all (use the Lisp
form of `interactive' specification), or with just one letter (with an
argument specifying which kind of d-s-m applies).  I.e. this is
a non-issue.

> But we are short of available code letters.

Actually I don't see we're short at all.  We have 32 chars used right
now, and while we can't use all of ASCII, there are more than 64
chars available.

> And it's not clear how to choose a letter with good mnemonics for
> their effects.

How 'bout ASCII 127 (aka C-?) ?


        Stefan

Re: delete-selection-mode

[Juri Linkov]

>>> Just as for shift-select-mode, I'd rather not use symbol properties to
>>> put this information, because it's a property of the command, not of
>>> its name.
>> This means introducing 4 new `interactive' code letters for:
>
> Of course not.  We can do it without any letter at all (use the Lisp
> form of `interactive' specification), or with just one letter (with an
> argument specifying which kind of d-s-m applies).  I.e. this is
> a non-issue.

I think without any letter is better than trying to find suitable
letters whose mnemonics is not obvious.

  (interactive
    (list
      (progn
        (handle-delete-region 'supersede)
        current-prefix-arg)))

is not hard to use for a few commands.

Wouldn't it be even better to allow using symbols in the interactive spec?
Something like (combining symbols and existing letters):

  (interactive '(delete-region-supersede "p"))

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

Re: delete-selection-mode

[Stefan Monnier]

> I think without any letter is better than trying to find suitable
> letters whose mnemonics is not obvious.

>   (interactive
>     (list
>       (progn
>         (handle-delete-region 'supersede)
>         current-prefix-arg)))

> is not hard to use for a few commands.

Fine by me.  For DEL in any case, the behavior is trickier because it
should end up not even executing the function (all the processing is
done in the interactive spec).


        Stefan

Re: delete-selection-mode

[Kevin Rodgers]

Juri Linkov wrote:
> But we are short of available code letters.  And it's not clear
> how to choose a letter with good mnemonics for their effects.

There is all of Unicode to consider as mnemonic code letters.  :-)

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: delete-selection-mode

[Daniel Colascione]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/26/10 1:04 AM, Kevin Rodgers wrote:
> Juri Linkov wrote:
>> But we are short of available code letters.  And it's not clear
>> how to choose a letter with good mnemonics for their effects.
>
> There is all of Unicode to consider as mnemonic code letters.  :-)
>

Yes, life is complete when Emacs binds something to C-x ?

:-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAkusQhoACgkQ17c2LVA10VvPJwCgut6Re/67H2fXP08sIjQZqh7X
Z1YAn0tfghyw1YoGkirrdsq535H87q6B
=Vu6J
-----END PGP SIGNATURE-----

Re: delete-selection-mode

[Juri Linkov]

>> But we are short of available code letters.  And it's not clear
>> how to choose a letter with good mnemonics for their effects.
>
> There is all of Unicode to consider as mnemonic code letters.  :-)

Ok, let's use Unicode characters:

␡ - handle-delete-region non-nil

⚔ - handle-delete-region 'supersede

☠ - handle-delete-region 'kill

♲ - handle-delete-region 'yank

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

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> But we are short of available code letters.  And it's not clear
>>> how to choose a letter with good mnemonics for their effects.
>>
>> There is all of Unicode to consider as mnemonic code letters.  :-)
>
> Ok, let's use Unicode characters:
>
> ␡ - handle-delete-region non-nil
>
> ⚔ - handle-delete-region 'supersede
>
> ☠ - handle-delete-region 'kill
>
> ♲ - handle-delete-region 'yank

To be entered with an "interactive-codes" input method?

-- 
David Kastrup

Re: delete-selection-mode

[Stefan Monnier]

> What do you think about marking commands that should delete the active
> region with a new interactive character (like "^" is used to call
> `handle-shift-selection'), so e.g. a new function `handle-delete-region'
> could delete the active region before running a command?

Sounds very good, indeed,


        Stefan "who suggested something like that earlier ;-)"

Re: delete-selection-mode

[Lennart Borgman]

On Tue, Mar 23, 2010 at 10:52 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> What do you think about marking commands that should delete the active
>> region with a new interactive character (like "^" is used to call
>> `handle-shift-selection'), so e.g. a new function `handle-delete-region'
>> could delete the active region before running a command?
>
> Sounds very good, indeed,


To me it looks a bit inflexible. Wouldn't it be better with something
that later could be customized?

Re: delete-selection-mode

[Stefan Monnier]

>>> What do you think about marking commands that should delete the active
>>> region with a new interactive character (like "^" is used to call
>>> `handle-shift-selection'), so e.g. a new function `handle-delete-region'
>>> could delete the active region before running a command?
>> Sounds very good, indeed,
> To me it looks a bit inflexible.  Wouldn't it be better with something
> that later could be customized?

We've been through that already when implementing the
shift-selection code.


        Stefan

Re: delete-selection-mode

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> What do you think about marking commands that should delete the active
>> region with a new interactive character (like "^" is used to call
>> `handle-shift-selection'), so e.g. a new function `handle-delete-region'
>> could delete the active region before running a command?
>
> Sounds very good, indeed,

Isn't this redundant with the idea of replacing mouse-region-delete-keys
with a more general variable that affects all active regions?  That
sounds more appealing than assigning more interactive codes.

Re: delete-selection-mode

[Stefan Monnier]

>>> What do you think about marking commands that should delete the active
>>> region with a new interactive character (like "^" is used to call
>>> `handle-shift-selection'), so e.g. a new function `handle-delete-region'
>>> could delete the active region before running a command?
>> Sounds very good, indeed,
> Isn't this redundant with the idea of replacing mouse-region-delete-keys
> with a more general variable that affects all active regions?  That
> sounds more appealing than assigning more interactive codes.

No, what I want is to replace the code that implements the feature
linked to mouse-region-delete-keys by new code which implements
a similar feature that covers more cases (not linked to
mouse-selection).

Whether that new code uses a variable like foo-region-delete-keys is
an "implementation detail".
And I think relying on keys (as is done currently by
mouse-region-delete-keys), or on symbol names (as is done currently by
d-s-m) is wrong: the behavior should depend on the actual command, so it
needs to be part of the command's definition, which basically means part
of its interactive spec.  Again, the reasoning is exactly the same as
the one that lead to the "^" for shift-select.


        Stefan

RE: delete-selection-mode

[Drew Adams]

> And I think relying on ... symbol names (as is done currently by
> d-s-m) is wrong: the behavior should depend on the actual 
> command, so it needs to be part of the command's definition,
> which basically means part of its interactive spec.  Again, the
> reasoning is exactly the same as the one that lead to the "^"
> for shift-select.

That reasoning was somewhat controversial and not very conclusive. I just looked
again at that long thread ("Shift selection using interactive spec" from 2008).
There were some good arguments on both sides (and there were more than 2 sides).
It's good to keep in mind the pros and cons, and not just consider this
simplistically as a closed question.

See what Kim, Juri, and others said, to understand why it can be important to
support symbol properties in addition to coding the behavior in the command's
`interactive' spec.

As Richard put it: "I think we should support both ways, but prefer the
interactive spec". IOW, (a) `interactive' spec and (b) function symbol
properties.

(a) is good for specifying the default behavior of a command: it gives the
command's own, a priori view of its intended behavior. (b) is good for
specifying alternative, additional, or otherwise custom behavior for the
command, as determined by the particular runtime context.

Using symbol properties in this way is, well, as Lispy as you can get. Making
the command's definition the be-all and end-all is akin to hard-coding the
behavior once and for all - it is not particularly Lispy. (But yes, it is
cleaner - Lisp has never been a paragon of cleanliness.) 

A string `interactive' arg means the earliest possible binding of the behavior:
at command definition time. In principle, using `interactive' with a non-string
arg allows plenty of flexibility (later binding of the interactive behavior),
but it still relies on defining the (runtime) behavior in terms of a foreseen
context.

Letting the context influence the behavior in unforeseen ways means still later
binding, and one reasonable way to do that is via the command's symbol
properties.[*]

But no, that is not foolproof. A function is not a symbol, and in Emacs Lisp
there is no way to attach a property to a function itself. And if a function
symbol with a property is bypassed then behavior can be inconsistent. That is
nothing new.

But people have been attaching properties to function symbols since Lisp-Day 1
as ways of controlling behavior in different ways depending on the context. And
Emacs itself does this all the time.

And even the `interactive-form' symbol property is manipulable this way - with
the same possibility of inconsistency (e.g.
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg02575.html).

Here is one piece of that 2008 thread, from Kim, to give an idea of the debate.
The point is that things are not as definitive as you present them.

> That's the beauty of CUA's command property approach - you can fix
> it simply by setting a property on the problematic commands in
> your own .emacs -- no need to mess inside the source code.
> 
> And it is the same for the delete-selection feature -- you can
> make external packages delete-selection aware simply by setting
> a suitable property.
> 
> I.e. if someone complaints that package xxx doesn't work, it is
> much easier to tell them to "add these two lines to your .emacs"
> rather than "you need to find file xxx.el and edit the interactive
> spec of commands xxx-forward and xxx-backward, and then byte-compile
> the file".
> 
> But I've given up already - it seems that most people making decisions
> on this issue don't use shift-select or delete-selection themselves,
> and they are not interested in listening to those who use it and have
> proven experience in implementing it (and having spent a lot of time
> making it work very well).


[*] Advising a command provides even later binding and even more flexibility
than does using properties set on its function symbol. And it is consequently
even less foolproof and more problematic.

Using predefined symbol properties is midway along the spectrum, with
`interactive' string arg near one end and things like `defadvice' near the
other.

It adheres to a predefined framework of known symbol values and their
corresponding behaviors, but it separates (1) the binding of those behaviors to
particular commands from (2) the internal definitions of those commands. And the
predefined framework itself is extensible (without needing to modify existing
command definitions).

Yes, anytime you intentionally separate things this way, defining some of the
behavior here at this time, and some of it over there at that time, you
introduce the possibility of a disconnect, and you can increase the
code-maintenance burden. That's the price of flexibility. Nothing new.

Re: delete-selection-mode

[Lennart Borgman]

On Fri, Mar 26, 2010 at 6:29 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> See what Kim, Juri, and others said, to understand why it can be important to
> support symbol properties in addition to coding the behavior in the command's
> `interactive' spec.
>
> As Richard put it: "I think we should support both ways, but prefer the
> interactive spec". IOW, (a) `interactive' spec and (b) function symbol
> properties.
>
> (a) is good for specifying the default behavior of a command: it gives the
> command's own, a priori view of its intended behavior. (b) is good for
> specifying alternative, additional, or otherwise custom behavior for the
> command, as determined by the particular runtime context.


I agree to this (as I have already said somewhere in this thread).

Re: delete-selection-mode

[Richard Stallman]

Has anyone else here begun trying delete-selection-mode?
If so, what are your experiences with it?

Re: delete-selection-mode

[joakim]

Richard Stallman <rms@gnu.org> writes:

> Has anyone else here begun trying delete-selection-mode?
> If so, what are your experiences with it?

I've turned it on and so far I've experienced no difference.

>
-- 
Joakim Verona

Re: delete-selection-mode

[Teemu Likonen]

* 2010-03-25 23:51 (-0400), Richard Stallman wrote:

> Has anyone else here begun trying delete-selection-mode?
> If so, what are your experiences with it?

I have, and I think it's a useful feature. Haven't experienced any
disadvantages, only advantages, so I will keep it turned on.

Re: delete-selection-mode

[Juri Linkov]

>> I was proposing folding the semantics of shift-select and mouse-select.
>> You think that would imply making shift-select worse, but we could
>> probably achieve it by making mouse-select better instead.
>
> mouse-select and shift-select semantics are already unified to a large
> extent.  Try it: drag a region of text with the mouse, then extend the
> region with the shift-arrow keys.  Internally, both work by setting the
> value of `transient-mark-mode' to `only'.
>
> Do you have a specific suggestion for improvement?

I have a suggestion: to add a single option that toggles between
1. temporary t-m-m (the value `only') of mouse-select and shift-select
2. and normal t-m-m of C-SPC and C-x C-x.

So when set, mouse-select and shift-select will behave like normal t-m-m.

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

Re: delete-selection-mode

[Lennart Borgman]

On Tue, Mar 23, 2010 at 5:58 AM, Miles Bader <miles@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>> But other than that, shift-selection should be the same as t-m-m-style
>>> selection as far as possible -- for instance, there should not be a
>>> different set of commands available for "shift-selected" regions than
>>> there are for regions created using traditional Emacs commands.
>>
>> I think some of these problems have been addressed in cua-mode. Maybe
>> it would be good to use what is in cua-mode more?
>
> Er, what "problems" do you mean?  Shift-select (without CUA mode) works
> quite well currently.  What I'm arguing against is David/RMS's apparent
> goal of making shift-select _worse_...

Extending the region with movement commands.

> [and CUA mode is generally such a mess that I'm very skeptical of
> adopting anything from it...]


I do not think such general negative remarks are helpful.

cua-mode is useful, very useful for us that are used and use other
editing environments too. It solves some nearly unsolveable problems
in Emacs - in my opinion the best way it could be solved with the
support that was possible to get when cua-mode was written.

So part of the structure of cua-mode possibly comes from the
resistance to it. If you care about that structure, please make
suggestions for how to improve it (it will may require changes to
Emacs in other ways).

RE: delete-selection-mode

[Drew Adams]

> cua-mode is useful, very useful for us that are used and use other
> editing environments too. It solves some nearly unsolveable problems
> in Emacs - in my opinion the best way it could be solved with the
> support that was possible to get when cua-mode was written.
> 
> So part of the structure of cua-mode possibly comes from the
> resistance to it. If you care about that structure, please make
> suggestions for how to improve it (it will may require changes to
> Emacs in other ways).

Ah. Just as I predicted at the beginning of this can-of-worms thread:

> we've been around this block a few times before. Here we 
> go, round and round. Folks will chime in again about cua-mode,
> cua-selection-mode, pc-selection-mode, transient-mark-mode,...
> The antimouse will raise its medusa head again... Round and
> round and round we go... Are we having fun yet?

Every part of that forecast has now come to fruition. Cua was the last to arrive
at the party, but all are now assembled and frantically flinging champagne and
confetti in the air.

Of course by now most of the partygoers are already well wasted. Cua will need
to indulge quickly to catch up. Not to worry...

Re: delete-selection-mode

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>>     Let's make shift-selection and mouse-selection _identical_ with regard
>>     to the outcome, with regard to visuals and semantics.
>>
>> That seems like a good idea to me.
>
> _All_ types of visible selection should be the same, including t-m-m
> (C-SPC + movement) selections, to the greatest extent possible.

Could we agree to focus on the things first on which we can agree?  To a
degree that we don't think anybody will need to customize them?

It narrows down the remaining fights.

> Yeah, I know, mouse-selection is currently "special".  It shouldn't be
> -- that was a bad decision.  Adding shift-selection to the mix just
> makes things worse.

There were reasons for making mouse-selection special.  Enough reasons
that people might want it to _be_ special even if we might end up with a
non-special default.

But I think that we can make shift-selection the same as mouse-selection
and save us _another_ special case to worry about with regard to
semantics and customization.

-- 
David Kastrup

Re: delete-selection-mode

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>> _All_ types of visible selection should be the same, including t-m-m
>> (C-SPC + movement) selections, to the greatest extent possible.
>
> Could we agree to focus on the things first on which we can agree?  To a
> degree that we don't think anybody will need to customize them?

This is not a minor issue.  It's a question of doing it properly so that
it will help Emacs be more useful, and more usable (for everybody, but
especially people learning Emacs).

Putting shift-selection in the "mouse region" ghetto does not help,
it just makes a currently problematic special case even _bigger_.

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: delete-selection-mode

[Stefan Monnier]

> Could we agree to focus on the things first on which we can agree?  To a
> degree that we don't think anybody will need to customize them?

I'm still waiting for someone to post a patch that does what
I requested: make DEL delete the active region (which gets us rid of the
special case when the region was created with the mouse).


        Stefan

RE: delete-selection-mode

[Drew Adams]

> >     Let's make shift-selection and mouse-selection 
> >     _identical_ with regard
> >     to the outcome, with regard to visuals and semantics.
> >
> > That seems like a good idea to me.
> 
> _All_ types of visible selection should be the same, including t-m-m
> (C-SPC + movement) selections, to the greatest extent possible.
> 
> Having multiple "types" of selection that are
> sorta-the-same-but-sorta-different is just going to make 
> Emacs harder to use for everybody, and harder to learn for
> beginners.
> 
> If a beginner tries to use (superior) Emacs-style marking (t-m-m),
> suddenly habits which seemed to work for them when using the 
> mouse will fail.  This is bad.
> 
> If an expert user wants to use DEL to delete a t-m-m region, that will
> fail, for no good reason.  This is stupid.
> 
> Yeah, I know, mouse-selection is currently "special".   It shouldn't
> be -- that was a bad decision.  Adding shift-selection to the mix just
> makes things worse.

On this question of mouse-selection specialness I agree with Miles. I wrote the
same thing before. I disagreed with our adding the special treatment of mouse
selection (e.g. DEL) and shift-selection.

1. That's one reason my preference would be for vanilla `delete-selection-mode'
to be the default. Both mouse selection and non-mouse region behaviors would be
type-to-replace by default - they would be the same in all respects.

Since d-s-mode anyway provides type-to-replace behavior, we can remove any
exceptional mouse-selection behavior. DEL-to-delete for the mouse, added in
Emacs 22, is a special case of type-to-replace, and it is provided by d-s-mode
(it's where `delete-selection-mode' gets its name).

That way, users who turn off d-s-mode would never be bothered by its behavior,
even for mouse selection: no type-to-replace. And newbies would get the mouse
behavior they expect, by default.

There would be no inconsistency between mouse selection and ordinary region, for
either newbies or old-timers, whether you like or dislike type-to-replace.

1a. What about shift-selection? Dunno. My own inclination would be to forget
about it, and just teach newbies to use C-SPC. They would have the
mouse-selection they expect, and if they are going to use the keyboard more and
more, then they might as well learn C-SPC.

Using shift-arrow keys to select is anyway not available everywhere, unlike
mouse selection. It is typically available only for editable fields, not for
read-only text. In Internet Explorer, for example (to cite the devil), it is
available only for input fields such as a URL, not for read-only Web-page text.
(For page text, the shift-arrow keys scroll the window horizontally.)

But as I say, I dunno about shift-selection. What Miles wrote in another mail
about it (defending it) also makes sense to me. If people feel that it is
important, then we should keep it. But the behavior of the resulting selection
should nevertheless be identical to that of the active region (whether in
d-s-mode or just t-m-mode).

2. Alternatively, we could remove mouse-selection specialness, as #1, but not
make d-s-mode the default. That is, revert the mouse-selection exceptional
behavior so it becomes the same as the ordinary region behavior, but turn off
d-s-mode by default. That would satisfy those who don't like type-to-replace or
are worried about its "dangers" for the ordinary region.

But in that case, we would need to take special measures to let newbies know
that d-s-mode exists to give them the type-to-replace behavior they expect, in
particular for mouse selection (which is what they're used to).

3. A third route would be to do what David and Richard are proposing for the
default: make it type-to-replace, but only for mouse selection.

In that case, the mouse behavior would be quite different from the normal region
behavior, not only by default, but always, whether d-s-mode is enabled or
disabled. Users would have no way to control the mouse-selection behavior to
turn off type-to-select and DEL-to-delete (the latter restriction is already the
case, AFAIK).

But at least the mouse behavior would be similar to what new users are used to.

I think #3 is not the best approach, including for the reasons Miles cited. But
I also think that we should somehow help new users to find the mouse-select +
type-to-replace behavior that they are used to.

Re: delete-selection-mode

[Richard Stallman]

    _All_ types of visible selection should be the same, including t-m-m
    (C-SPC + movement) selections, to the greatest extent possible.

    Having multiple "types" of selection that are
    sorta-the-same-but-sorta-different is just going to make Emacs harder to
    use for everybody, and harder to learn for beginners.

We have multiple "types" of selection now, which behave differently
in regard to DEL.  Is there any empirical sign that this makes Emacs
harder to use -- for anyone?  Or harder to learn -- for anyone?

RE: delete-selection-mode

[Drew Adams]

>     _All_ types of visible selection should be the same, 
>     including t-m-m (C-SPC + movement) selections, to the
>     greatest extent possible.
> 
>     Having multiple "types" of selection that are
>     sorta-the-same-but-sorta-different is just going to make 
>     Emacs harder to use for everybody, and harder to learn
>     for beginners.
> 
> We have multiple "types" of selection now, which behave differently
> in regard to DEL.

Yes, and that's a defect that Miles (I think - I, at least) would like to get
rid of. And certainly not add to.

> Is there any empirical sign that this makes Emacs
> harder to use -- for anyone?  Or harder to learn -- for anyone?

Empirical studies that demonstrate that? Dunno. I certainly haven't researched
it, myself. Have you? Any empirical indication that it does *not* make life more
difficult? Just because people get by with the feature and don't complain
doesn't mean that it is a blessing.

While waiting for empirical evidence (either way), it makes sense logically, no?
More things to deal with, to understand, to figure out, to manipulate. Makes
sense that that doesn't make things any easier.

 - Occam

Re: delete-selection-mode

[Richard Stallman]

    > Is there any empirical sign that this makes Emacs
    > harder to use -- for anyone?  Or harder to learn -- for anyone?

    Empirical studies that demonstrate that? Dunno. I certainly haven't researched
    it, myself. Have you? Any empirical indication that it does *not* make life more
    difficult?

My guess is that it has very little effect either way.

Re: delete-selection-mode

[David Reitter]

On Mar 24, 2010, at 11:15 AM, Drew Adams wrote:
>> 
>> Is there any empirical sign that this makes Emacs
>> harder to use -- for anyone?  Or harder to learn -- for anyone?
> 
> Empirical studies that demonstrate that? Dunno. I certainly haven't researched
> it, myself. Have you? Any empirical indication that it does *not* make life more
> difficult? Just because people get by with the feature and don't complain
> doesn't mean that it is a blessing.

Somebody will complain sooner or later.

We've had d-s-m switched on in Aquamacs from the very beginning (2005), and I remember seeing only one complaint ever.  
If text gets overwritten inadvertently it is easy to undo.  Of course, transient mark mode has been on as well, so that the interaction w.r.t. the region makes sense.  One caveat is that the Aquamacs demographic is not the same as the Emacs one.

Second, people who don't like it may either turn it off manually (which they often do, rather than complain), or use an older version.  Both is fine.

It has been my philosophy in Aquamacs to not try to make too many people happy, but get the interaction right for certain target users.  Emacs would do well to do the same:  you can't make novel users and traditionalists happy at the same time.  Whatever you do, do it well.  Pick your poison and stick with it.  (Different distributions, as with Aquamacs, address the issue!)

RE: delete-selection-mode

[Drew Adams]

> We have testimony that some ordinary users want self-inserting
> characters to delete the region (which they have made with the mouse).
> We have testimony that one ordinary user thinks that same behavior is
> a pain.  I am sure both reports are factually accurate, but where do
> we go from there?

As a wise man once said, "Poll the users".

> It would be useful to find out what some larger number of ordinary
> users think.  How many want self-inserting characters to delete the
> mouse-selected region, how many are glad it doesn't, and how many
> don't care?

Failing a useful poll (and we seem to be failing to poll users, so far), we
could offer our own guesses as to the number of ordinary users in each camp. You
know what my guess would be. Other guesses?


However, there are other things to consider in this regard, I think, including
at least the following:

1. Is the proper comparison here merely the _number_ of (ordinary) users in each
camp? Shouldn't the _relative cost_ in pain and suffering be factored in?

I thought that Alan's strongest point was not merely that he and his sister
think the usual behavior (hors Emacs) is a pain, but that it is a ***PAIN***, a
"serious problem" that "causes distress", imposes "massive inconvenience", and
inflicts "a lot of pain on lots of people". This was _very_ clear from his
report.

If this is the case - and it must be as credible as the rest of the
sister-sample info ("factually accurate", at least as far as that one ordinary
user is concerned, plus Alan), then I don't see how we can merely count and
compare numbers of users in each camp. That would be downright dangerous, if not
immoral.

Surely, imposing massive pain, distress, and inconvenience is not warranted,
even for only a few users, let alone the "countless" minority that Alan
estimates would suffer (and are already suffering, out there).

2. A countervailing consideration is that Alan's sister specifically added that
"'it's not too bad' if there's an undo key sequence." I don't know how much pain
relief she had in mind, but Emacs does have a very good undo.

3. Also, Alan's sister reportedly does _not_ use type-to-replace outside Emacs,
in any case. She explicitly hits the delete key before typing replacement text.
IOW, she has presumably already learned to avoid the pain for the most part. Can
we assume the same would likely be true of the other users in her camp?

#2 and #3 would indicate that those users who are likely to experience pain
would have at least some relief, whether outside or inside Emacs. Dunno whether
that compensates completely for #1, but these are all things to be weighed.

Re: delete-selection-mode

[Richard Stallman]

    1. Is the proper comparison here merely the _number_ of (ordinary) users in each
    camp? Shouldn't the _relative cost_ in pain and suffering be factored in?

We should consider that.  If you teach a beginner to use Emacs, you
can take note of the details of the scenario and how the person
reacts.

I expect that the pain will be similar in the two cases, because in
both cases it does something undesired to your text and you need to
fix it.

    3. Also, Alan's sister reportedly does _not_ use type-to-replace
    outside Emacs, in any case. She explicitly hits the delete key
    before typing replacement text.  IOW, she has presumably already
    learned to avoid the pain for the most part. Can we assume the
    same would likely be true of the other users in her camp?

Whether they have all learned habits to protect themselves against
the painful situation is relevant, as you say.

However, the practice of typing DEL explicitly when she wants to
delete does not protect against an unintended deletion when she
doesn't want that.

Re: delete-selection-mode

[Richard Stallman]

I wrote

    > Is this true even when the region has been activated by keyboard commands?
    > If so, perhaps it is a bug.  Perhaps the feature should only apply when
    > you make the region using the mouse.

You replied

    I think it would be a very bad idea to introduce an invisible state
    this way. (I agree with Klaus here - if I do not misunderstand him.)

This distinction already exists.  Now that I've been reminded of it, I
recall why I implemented it.

Making DEL delete the whole region after a mouse selection did not
affect experienced Emacs users, who edit mainly with the keyboard.  So
I saw no reason not to do this by default.

Making DEL delete the region whenever it is active would be an
incompatible change for us, so I rejected it as a default.

Some have claimed here that such an "invisible" distinction would be
intolerable, but let's check the facts.  Have there been any
complaints about it?  Would someone like to check the bug tracker?

Extending the region-deletion behavior to cover self-insertion as well
as DEL is a natural change.  Extending it to shift-arrow selection
makes sense too.  These can increase effective compatibility because
the whole editing scenario (select a region and then operate on it) is
compatible between Emacs and the other relevant programs.

In addition, neither of those two changes will affect experiencd Emacs
users.  There is no practical argument against those changes.

The case that could very well be painful to change is that of marking
the region with the traditional Emacs editing commands.  In addition,
that change would give no effective increase in compatibility with
other programs, because these Emacs commands are totally incompatible
with those programs.

We should not break most every user's editing habits for a partial
compatibility which is too partial to be of real use.  Such a change
could lead to a rebellion of the users.

However, there remains the question of whether enabling
delete-selection-mode would really break our habits.  Will it really
bother experienced users like me?

How about if we find out empirically.

I have enabled delete-selection-mode, and I will try editing with it.
I'll see if it is a real pain or not.  I suggest that others also try
turning it on.  Then we will know whether it is a real pain in the
neck, rather than arguing theoretically that it is or isn't.

Re: delete-selection-mode

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> However, there remains the question of whether enabling
> delete-selection-mode would really break our habits.  Will it really
> bother experienced users like me?
>
> How about if we find out empirically.
>
> I have enabled delete-selection-mode, and I will try editing with it.
> I'll see if it is a real pain or not.  I suggest that others also try
> turning it on.  Then we will know whether it is a real pain in the
> neck, rather than arguing theoretically that it is or isn't.

Thank you, this will be a useful thing.

RE: delete-selection-mode

[Drew Adams]

> I wrote
> 
>     > Is this true even when the region has been activated by 
>     > keyboard commands? If so, perhaps it is a bug.  Perhaps
>     > the feature should only apply when
>     > you make the region using the mouse.
> 
> You replied
> 
>     I think it would be a very bad idea to introduce an 
>     invisible state this way. (I agree with Klaus here -
>     if I do not misunderstand him.)
> 
> This distinction already exists.  Now that I've been reminded of it, I
> recall why I implemented it.

"Why I implemented it" is almost always important info. Thanks. It would be
great if such info were recorded more often, preferably at the time of the
change.

> Making DEL delete the whole region after a mouse selection did not
> affect experienced Emacs users, who edit mainly with the keyboard.  So
> I saw no reason not to do this by default.
> 
> Making DEL delete the region whenever it is active would be an
> incompatible change for us, so I rejected it as a default.
> 
> Some have claimed here that such an "invisible" distinction would be
> intolerable, but let's check the facts.  Have there been any
> complaints about it?  Would someone like to check the bug tracker?
> 
> Extending the region-deletion behavior to cover self-insertion as well
> as DEL is a natural change.  Extending it to shift-arrow selection
> makes sense too.  These can increase effective compatibility because
> the whole editing scenario (select a region and then operate on it) is
> compatible between Emacs and the other relevant programs.
> 
> In addition, neither of those two changes will affect experiencd Emacs
> users.  There is no practical argument against those changes.
> 
> The case that could very well be painful to change is that of marking
> the region with the traditional Emacs editing commands.  In addition,
> that change would give no effective increase in compatibility with
> other programs, because these Emacs commands are totally incompatible
> with those programs.
> 
> We should not break most every user's editing habits for a partial
> compatibility which is too partial to be of real use.  Such a change
> could lead to a rebellion of the users.

All well reasoned and clearly explained, IMO.

I disagree that it's a great idea to have the mouse behavior be different
(special, inconsistent, incompatible - whatever word you like), but I recognize
your reasons and they are _good_ ones.

I agree that many veteran Emacs users would not be affected by what you describe
because they do not use the mouse (this way) anyway. I disagree that this means
all or even perhaps most Emacs veterans (dunno). I am one who uses both the
mouse (this way) and the keyboard. But I don't claim to represent the majority.

As long as we have some clean way to get a consistent behavior between mouse and
keyboard, I'm OK with our also providing an inconsistent mix such as you
describe. And yes, it could even be the default behavior.

I'd argue against it in general because consistency often means simplicity and
lack of surprise. I like my selection using the mouse to behave the same as my
selection using keys. And I think it helps learners when the behavior is
consistent that way. But consistency is not the only consideration, ever.

Thanks for presenting the mouse-behavior history clearly, and especially for
providing the rationale behind the design decisions. We could use more such
explanation when changes are made, IMO.

> However, there remains the question of whether enabling
> delete-selection-mode would really break our habits.  Will it really
> bother experienced users like me?
> 
> How about if we find out empirically.
> 
> I have enabled delete-selection-mode, and I will try editing with it.
> I'll see if it is a real pain or not.  I suggest that others also try
> turning it on.  Then we will know whether it is a real pain in the
> neck, rather than arguing theoretically that it is or isn't.

Bonne initiative.

Re: delete-selection-mode

[Stephen J. Turnbull]

Richard Stallman writes:

 > How about if we find out empirically.

The way to do this is to turn it on by default, *provisionally* for
*one* pretest[1], and listen for the screams.  Otherwise people who just
update but don't read these interminable and terminally boring threads
won't be part of the test, and the results will be seriously biased.

Note that making an effort to gather data on less active posters
and/or inexperienced users does *not* mean that their responses should
be interpreted the same way as you do those of experienced users.  
You stil have to factor in the question of "dynamic efficiency" (ie,
whether having Emacs behave similarly to other apps in this respect
might inhibit the process of learning to use Emacs effectively).  We
can hope that their posts will include comments that can be used to
infer the strength of such effects.

Of course the beta testers should be warned, eg, in the splash screen
and in NEWS.

Footnotes: 
[1]  Or perhaps the current pretest process is too advanced for this
kind of thing, and it should be pushed back to the first pretest of
the next release.

Re: delete-selection-mode

[Richard Stallman]

    The way to do this is to turn it on by default, *provisionally* for
    *one* pretest[1], and listen for the screams.

That could be a good idea as an experiment,
if the smaller experiments that we here can carry out
give a preliminary green light to the idea.

RE: delete-selection-mode

[Drew Adams]

>     It does have many more effects.  The most significant one 
>     is that any self-inserting key typed when the region is
>     active will cause the region to be deleted before the
>     char is inserted.
> 
> Is this true even when the region has been activated by 
> keyboard commands?

Yes.

> If so, perhaps it is a bug.

No.

> Perhaps the feature should only apply when you make the region
> using the mouse.

If people are unfamiliar with `delete-selection-mode' and do not want to make it
the default behavior, fine. But please do not mess with the behavior of
`delete-selection-mode'. It does not need to be "fixed".

If you don't like it, then don't use it. If you don't want it to be the default,
then don't make it the default. But leave it alone, at least, for those of us
who appreciate it.

Re: delete-selection-mode

[Richard Stallman]

    If people are unfamiliar with `delete-selection-mode' and do not want to make it
    the default behavior, fine. But please do not mess with the behavior of
    `delete-selection-mode'. It does not need to be "fixed".

If some users like `delete-selection-mode' as it stands, there is no
reason to change it.

This discussion was started as a response to requests from beginners.
Enabling `delete-selection-mode' by default was proposed as a way to
satisfy them.  But if we change the default, we don't have to use
`delete-selection-mode'.  We could use something different for this
purpose if it is more suitabe.

RE: delete-selection-mode

[Drew Adams]

>     If people are unfamiliar with `delete-selection-mode' and 
>     do not want to make it the default behavior, fine. But
>     please do not mess with the behavior of
>     `delete-selection-mode'. It does not need to be "fixed".
> 
> If some users like `delete-selection-mode' as it stands, there is no
> reason to change it.
> 
> This discussion was started as a response to requests from beginners.
> Enabling `delete-selection-mode' by default was proposed as a way to
> satisfy them.  But if we change the default, we don't have to use
> `delete-selection-mode'.  We could use something different for this
> purpose if it is more suitabe.

Thank you.

Let's finish with the original proposal, at least, to get that out of the way
one way or the other. Depending on that decision, we can always consider other
changes.

Given d-s-mode _as it is_, do people think it should be enabled by default?
That's the question.

If the consensus is strong enough that in its current form it should not become
the default, fine. But let's at least give Juri's proposal a clear judgment.

Re: delete-selection-mode

[Juri Linkov]

>> This discussion was started as a response to requests from beginners.
>> Enabling `delete-selection-mode' by default was proposed as a way to
>> satisfy them.  But if we change the default, we don't have to use
>> `delete-selection-mode'.  We could use something different for this
>> purpose if it is more suitabe.
>
> Thank you.
>
> Let's finish with the original proposal, at least, to get that out of the way
> one way or the other. Depending on that decision, we can always consider other
> changes.
>
> Given d-s-mode _as it is_, do people think it should be enabled by default?
> That's the question.
>
> If the consensus is strong enough that in its current form it should not become
> the default, fine. But let's at least give Juri's proposal a clear judgment.

No, that's not what I meant.

Even though I referred to delete-selection-mode, that's only because
it is the mode that currently implements the necessary functionality.

Often moving some functionality into the core requires redesigning its API.
For instance, implementing shift-arrows required adding a new option
shift-select-mode instead of enabling the equivalent functionality
from an existing package like s-region.el or pc-select.el.

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

RE: delete-selection-mode

[Drew Adams]

> >> This discussion was started as a response to requests from 
> >> beginners. Enabling `delete-selection-mode' by default was
> >> proposed as a way to satisfy them.  But if we change the
> >> default, we don't have to use `delete-selection-mode'.
> >> We could use something different for this
> >> purpose if it is more suitabe.
> >
> > Thank you.
> >
> > Let's finish with the original proposal, at least, to get 
> > that out of the way one way or the other. Depending on that
> > decision, we can always consider other changes.
> >
> > Given d-s-mode _as it is_, do people think it should be 
> > enabled by default? That's the question.
> >
> > If the consensus is strong enough that in its current form 
> > it should not become the default, fine. But let's at least
> > give Juri's proposal a clear judgment.
> 
> No, that's not what I meant.
> 
> Even though I referred to delete-selection-mode, that's only because
> it is the mode that currently implements the necessary functionality.
> 
> Often moving some functionality into the core requires 
> redesigning its API.
> For instance, implementing shift-arrows required adding a new option
> shift-select-mode instead of enabling the equivalent functionality
> from an existing package like s-region.el or pc-select.el.

Then I think we've already effectively moved on, saying that d-s-mode as is is
not quite the right default. And you seem (like me) to agree with Richard that
"We could use something different for this purpose." 

Finding a new behavior for the default is one thing. Changing d-s-mode itself is
another. I object to the second. I have no objection to the first, even if that
new behavior ends up being similar in some ways to d-s-mode.

Re: delete-selection-mode

[Richard Stallman]

    Given d-s-mode _as it is_, do people think it should be enabled by default?
    That's the question.

    If the consensus is strong enough that in its current form it should not become
    the default,

That criterion is absolutely wrong.

This is an incompatible change, so it should not be made unless it
is clearly right.




The change should not be made if there is substantial opposition based
on real experience.

RE: delete-selection-mode

[Drew Adams]

>     Given d-s-mode _as it is_, do people think it should be 
>     enabled by default? That's the question.
> 
>     If the consensus is strong enough that in its current 
>     form it should not become the default,
                     ^^^

> That criterion is absolutely wrong.
> This is an incompatible change, so it should not be made unless it
> is clearly right.
> 
> The change should not be made if there is substantial opposition based
> on real experience.

How does anything you wrote contradict what I wrote?
I certainly do not disagree with what you wrote, in any case.

If you want to add "based on real experience" after "If the consensus is strong
enough", I certainly support that.

And note the "not" in what I wrote. I certainly was not proposing that we make
an incompatible change based on no real experience.

Re: delete-selection-mode

[Richard Stallman]

    If you want to add "based on real experience" after "If the consensus is strong
    enough", I certainly support that.

To reject a proposed incompatible change does not require a consensus
against it.

RE: delete-selection-mode

[Drew Adams]

> To reject a proposed incompatible change does not require a consensus
> against it.

Ah, yes, of course. If that's what your correction meant, yes indeed.

Re: delete-selection-mode

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> Is this true even when the region has been activated by keyboard commands?
> If so, perhaps it is a bug.  Perhaps the feature should only apply when
> you make the region using the mouse.

I think it should also apply when the region is made using the S-arrow
keys, as that is another common way of making a region which we have
provided for those same new users.

Personally I think that the traditional Emacs way of setting mark should
have neither delete-selection nor transient-mark by default.  The reason
is that Emacs has two distinct uses for the mark - as a mark, and as one
end of the region. Transient-mark-mode and delete-selection-mode really
only apply when the mark is used as one end of the region, and get in
the way when the intention is to use the mark as a mark.

RE: delete-selection-mode

[Drew Adams]

> > Is this true even when the region has been activated by 
> > keyboard commands? If so, perhaps it is a bug.  Perhaps
> > the feature should only apply when you make the region
> > using the mouse.
> 
> I think it should also apply when the region is made using the S-arrow
> keys, as that is another common way of making a region which we have
> provided for those same new users.
> 
> Personally I think that the traditional Emacs way of setting 
> mark should have neither delete-selection nor transient-mark
> by default. 

Please, don't even think about messing with d-s-mode or t-m-mode.

Don't change the default behavior to d-s-mode, if you don't want to.

But do not - please do NOT - change the behavior of d-s-mode (or t-m-mode).
 
> The reason is that Emacs has two distinct uses for the mark -
> as a mark, and as one end of the region.

No, no, no. The mark is *ALWAYS* one of the region. By definition.

Yes, the text within the region is not always used, for some uses of the mark -
e.g. navigation. Yes, there are different uses of the region and the mark.

And yes, for purely navigational uses (e.g. jumping to the mark or a previous
mark position) you sometimes do not need or want the region to be active.

> Transient-mark-mode and delete-selection-mode really
> only apply when the mark is used as one end of the region,

Which is always the case, by definition.

> and get in the way when the intention is to use the mark as a mark.

The region being active can get in the way when you don't want it to be active.
;-) Yes. And that is mainly when you are using the mark navigationally.

Most generalizations of the kind "you don't need the region to be active when"
are wrong _as generalizations_. When you select a sexp using `C-M-@', do you
want the region to be active? It all depends. (But generally, yes, I do.)

Re: delete-selection-mode

[David Kastrup]

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

>> The reason is that Emacs has two distinct uses for the mark - as a
>> mark, and as one end of the region.
>
> No, no, no. The mark is *ALWAYS* one of the region. By definition.

push-mark and pop-mark are not region-centric commands.

-- 
David Kastrup

RE: delete-selection-mode

[Drew Adams]

> >> The reason is that Emacs has two distinct uses for the mark - as a
> >> mark, and as one end of the region.
> >
> > No, no, no. The mark is *ALWAYS* one of the region. By definition.
> 
> push-mark and pop-mark are not region-centric commands.

And?  No one said they were. (Although they certainly do affect the region.)

I was plenty clear that there are other uses of the mark (_and the region_),
besides type-to-replace the region text. I specifically mentioned navigational
use of previous mark positions and the mark.

Although there are different ways to use the mark (and the region), it is not
correct to say that one way uses the mark as a mark and the other uses the mark
as the end of the region.

Some uses of the mark don't care where point is and don't care which text is in
the region. Granted. But the mark is always one end of the region, and the
region is always positioned at the mark. There is no mark without the region
(even an empty one) and no region without the mark.

And some (many) uses of the region that do care about both of its ends and its
text have nothing to do with type-to-replace. Even if select-and-type-to-replace
is a common operation, it constitutes only one way to use the mark and region.

Re: delete-selection-mode

[Richard Stallman]

    Personally I think that the traditional Emacs way of setting mark should
    have neither delete-selection nor transient-mark by default.  The reason
    is that Emacs has two distinct uses for the mark - as a mark, and as one
    end of the region. Transient-mark-mode and delete-selection-mode really
    only apply when the mark is used as one end of the region, and get in
    the way when the intention is to use the mark as a mark.

The reason I don't agree with this is that Transient Mark mode
is very useful with the traditional Emacs mark commands.
(I have mark-even-if-inactive set to t, which is what makes
Transient Mark mode acceptable.)

Re: delete-selection-mode

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     Personally I think that the traditional Emacs way of setting mark should
>     have neither delete-selection nor transient-mark by default.  The reason
>     is that Emacs has two distinct uses for the mark - as a mark, and as one
>     end of the region. Transient-mark-mode and delete-selection-mode really
>     only apply when the mark is used as one end of the region, and get in
>     the way when the intention is to use the mark as a mark.
>
> The reason I don't agree with this is that Transient Mark mode
> is very useful with the traditional Emacs mark commands.
> (I have mark-even-if-inactive set to t, which is what makes
> Transient Mark mode acceptable.)

Can we perhaps highlight the region in a different color, so the user is
not so surprised that it acts differently than a region set using the
mouse.

Re: delete-selection-mode

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> Can we perhaps highlight the region in a different color, so the user is
> not so surprised that it acts differently than a region set using the
> mouse.

How about instead we make them not different.

-Miles

-- 
Politics, n. A strife of interests masquerading as a contest of
principles. The conduct of public affairs for private advantage.

Re: delete-selection-mode

[Lennart Borgman]

On Sat, Mar 20, 2010 at 4:53 AM, Jason Rumney <jasonr@gnu.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>>     Personally I think that the traditional Emacs way of setting mark should
>>     have neither delete-selection nor transient-mark by default.  The reason
>>     is that Emacs has two distinct uses for the mark - as a mark, and as one
>>     end of the region. Transient-mark-mode and delete-selection-mode really
>>     only apply when the mark is used as one end of the region, and get in
>>     the way when the intention is to use the mark as a mark.
>>
>> The reason I don't agree with this is that Transient Mark mode
>> is very useful with the traditional Emacs mark commands.
>> (I have mark-even-if-inactive set to t, which is what makes
>> Transient Mark mode acceptable.)
>
> Can we perhaps highlight the region in a different color, so the user is
> not so surprised that it acts differently than a region set using the
> mouse.


I think it is a very good suggestion to be able to have one color for
regions that act in way compatible with almost every editing
environment and one that acts in the way special to Emacs.

Re: delete-selection-mode

[Richard Stallman]

    I think it is a very good suggestion to be able to have one color for
    regions that act in way compatible with almost every editing
    environment and one that acts in the way special to Emacs.

I have nothing against this feature, but I point out that choosing
another color, and making it properly distinctive in two different
color environments (dark background and light background), is not
going to be easy.

Re: delete-selection-mode

[Lennart Borgman]

On Sat, Mar 20, 2010 at 5:50 PM, Richard Stallman <rms@gnu.org> wrote:
>    I think it is a very good suggestion to be able to have one color for
>    regions that act in way compatible with almost every editing
>    environment and one that acts in the way special to Emacs.
>
> I have nothing against this feature, but I point out that choosing
> another color, and making it properly distinctive in two different
> color environments (dark background and light background), is not
> going to be easy.

Maybe use secondary-selection for the Emacs version?

RE: delete-selection-mode

[Drew Adams]

> >    I think it is a very good suggestion to be able to have 
> >    one color for regions that act in way compatible with almost
> >    every editing environment and one that acts in the way special
> >    to Emacs.
> >
> > I have nothing against this feature, but I point out that choosing
> > another color, and making it properly distinctive in two different
> > color environments (dark background and light background), is not
> > going to be easy.
> 
> Maybe use secondary-selection for the Emacs version?

No thanks. We're looking for less confusion, not more.

Re: delete-selection-mode

[Lennart Borgman]

On Sat, Mar 20, 2010 at 6:37 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >    I think it is a very good suggestion to be able to have
>> >    one color for regions that act in way compatible with almost
>> >    every editing environment and one that acts in the way special
>> >    to Emacs.
>> >
>> > I have nothing against this feature, but I point out that choosing
>> > another color, and making it properly distinctive in two different
>> > color environments (dark background and light background), is not
>> > going to be easy.
>>
>> Maybe use secondary-selection for the Emacs version?
>
> No thanks. We're looking for less confusion, not more.

Please explain. Is anyone really using secondary-selection? (I do have
one library using it, but I do not use x so I am not sure whether it
is used otherwise.)

RE: delete-selection-mode

[Drew Adams]

> >> >    I think it is a very good suggestion to be able to have
> >> >    one color for regions that act in way compatible with almost
> >> >    every editing environment and one that acts in the way special
> >> >    to Emacs.
> >> >
> >> > I have nothing against this feature, but I point out 
> >> > that choosing another color, and making it properly
> >> > distinctive in two different color environments (dark
> >> > background and light background), is not going to be easy.
> >>
> >> Maybe use secondary-selection for the Emacs version?
> >
> > No thanks. We're looking for less confusion, not more.
> 
> Please explain. Is anyone really using secondary-selection? (I do have
> one library using it, but I do not use x so I am not sure whether it
> is used otherwise.)

Explanation: Face `secondary-selection' is for the secondary selection. End of
story.

Anyone use it?  I, for one, use the secondary selection all of the time.

1. I use my own extensions for it, including a secondary ring, analogous to the
kill ring.

I bind `C-M-y' to a `secondary-dwim' command that I use to both set the
secondary and yank it. `M-y' cycles the normal kill ring or the secondary ring,
depending on whether it follows `C-y' or `C-M-y'.
http://www.emacswiki.org/emacs/SecondarySelection#secondary-sel.el

2. I also use the secondary with the mouse - especially handy with
`delete-selection-mode'. Double-click, yank secondary - here and there. My guess
is that others do this too. If not, I don't know why not (unless they never use
a mouse).

3. I also use the secondary with isearch. I have `C-SPC' during isearch toggle
putting the active region around the search hit when you exit. When that's on, I
can selectively replace search targets with the secondary.
http://www.emacswiki.org/emacs/IsearchPlus

The beauty of the secondary selection is that it isn't affected by the changes
to the `kill-ring' or where the region is. Extending the single secondary
selection to a ring has the same effect as the vanilla Emacs extension of a
single-item clipboard to the kill ring.

Re: delete-selection-mode

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     I think it is a very good suggestion to be able to have one color for
>     regions that act in way compatible with almost every editing
>     environment and one that acts in the way special to Emacs.
>
> I have nothing against this feature, but I point out that choosing
> another color, and making it properly distinctive in two different
> color environments (dark background and light background), is not
> going to be easy.

Even if you can find good colors, it's still a dreadfully bad interface.

Having different colored regions, which act sometimes-the-same,
sometimes-differently, is maybe _slightly_ better than having
_identical-looking_ regions which act that way, but it's still very hard
to use, and confusingly non-obvious (especially for naive users).

-Miles

-- 
Laughter, n. An interior convulsion, producing a distortion of the features
and accompanied by inarticulate noises. It is infectious and, though
intermittent, incurable.

Re: delete-selection-mode

[Lennart Borgman]

On Sat, Mar 20, 2010 at 10:58 PM, Miles Bader <miles@gnu.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
>>     I think it is a very good suggestion to be able to have one color for
>>     regions that act in way compatible with almost every editing
>>     environment and one that acts in the way special to Emacs.
>>
>> I have nothing against this feature, but I point out that choosing
>> another color, and making it properly distinctive in two different
>> color environments (dark background and light background), is not
>> going to be easy.
>
> Even if you can find good colors, it's still a dreadfully bad interface.
>
> Having different colored regions, which act sometimes-the-same,
> sometimes-differently, is maybe _slightly_ better than having
> _identical-looking_ regions which act that way, but it's still very hard
> to use, and confusingly non-obvious (especially for naive users).


I think you are misunderstanding. The proposal was of course that the
colors should match how the region behaves.

Naive users will not be bothered by this since they will only see a
region that behaves like a region in other editing environments.

Re: delete-selection-mode

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> I think you are misunderstanding. The proposal was of course that the
> colors should match how the region behaves.

Right, and I'm saying the way the region behaves is bad.

> Naive users will not be bothered by this since they will only see a
> region that behaves like a region in other editing environments.

That's extremely limited thinking.  It assumes that users who use those
commands will _never_ use the Emacs repertoire of marking commands; if
they do, they'll be confronted by inconsistent behavior for no obvious
reason.  That may well discourage them from exploring further -- and
that's _bad_; the Emacs commands are superior, if unfamiliar at first.

-Miles

-- 
Omochiroi!

Re: delete-selection-mode

[Lennart Borgman]

On Sun, Mar 21, 2010 at 5:56 AM, Miles Bader <miles@gnu.org> wrote:
>
>> Naive users will not be bothered by this since they will only see a
>> region that behaves like a region in other editing environments.
>
> That's extremely limited thinking.

You are probably just misunderstanding again. I hope it is not intentionally.

> It assumes that users who use those
> commands will _never_ use the Emacs repertoire of marking commands;

Not at all.

> if
> they do, they'll be confronted by inconsistent behavior for no obvious
> reason.  That may well discourage them from exploring further -- and
> that's _bad_; the Emacs commands are superior, if unfamiliar at first.

I am quite sure you can see some contradictions in what you are saying here.

Re: delete-selection-mode

[Richard Stallman]

    Can we perhaps highlight the region in a different color, so the user is
    not so surprised that it acts differently than a region set using the
    mouse.

The theoretical part of this argument is valid, but is the implied
factual premise true?  Is there evidence that users are in fact being
surprised by this?

Re: delete-selection-mode

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

>     Can we perhaps highlight the region in a different color, so the
>     user is not so surprised that it acts differently than a region
>     set using the mouse.
> 
> The theoretical part of this argument is valid, but is the implied
> factual premise true?  Is there evidence that users are in fact being
> surprised by this?

I have a meta-question in this context: How many users need to be
surprised by any feature, and how much do they need to be bothered by
it, before news of this comes back to the developers? I realize that
this question is probably nearly impossible to answer, but I wonder
if it is necessary to actively go out and gather such evidence, or if
it is enough to just sit back and wait for complaints to come rolling
in. (I expect old-time emacs users are good at voicing their
complaints. My question is about new users.)

- Harald

Re: delete-selection-mode

[Richard Stallman]

    I have a meta-question in this context: How many users need to be
    surprised by any feature, and how much do they need to be bothered by
    it, before news of this comes back to the developers? I realize that
    this question is probably nearly impossible to answer, but I wonder
    if it is necessary to actively go out and gather such evidence, or if
    it is enough to just sit back and wait for complaints to come rolling
    in.

It is useful to actively see what new users think, by teaching people
to use Emacs and seeing where they have problems.  That's how we found
out that some do want self-insertion to replace the region, and that's
how we found out that some want the opposite.

Re: delete-selection-mode

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     It does have many more effects.  The most significant one is that any
>     self-inserting key typed when the region is active will cause the region
>     to be deleted before the char is inserted.
>
> Is this true even when the region has been activated by keyboard commands?
> If so, perhaps it is a bug.  Perhaps the feature should only apply when
> you make the region using the mouse.

I think having invisible differences between "types" of activated region
is simply confusing; this is especially problematic given that the
feature being discussed is aimed at beginning users.

Whether or not we turn on "type to delete region" by default or not, I
don't think we should be adding confusing hair to the user interface.
When it is enabled, it should act consistently for all types of active
region.

-Miles

-- 
Consult, v.i. To seek another's disapproval of a course already decided on.

RE: delete-selection-mode

[Drew Adams]

> I think having invisible differences between "types" of 
> activated region is simply confusing; this is especially
> problematic given that the feature being discussed is
> aimed at beginning users.
> 
> Whether or not we turn on "type to delete region" by default or not, I
> don't think we should be adding confusing hair to the user interface.
> When it is enabled, it should act consistently for all types of active
> region.

I agree.

RE: delete-selection-mode

[Drew Adams]

> From: Stefan Monnier
> If the fact that the region is active at that point "is right"
> (i.e. you indeed intended to highlight that region), then 
> deleting it is probably the right thing to do.
> 
> But if the region is active by accident (e.g. the fact that it's
> highlighted is something you grudgingly live with since t-m-m was made
> the default), then you may get annoyed that merely inserting a char at
> point ends up deleting all the text that happened to be highlighted.
> 
> I think delete-selection-mode makes sense, FWIW, but I can 
> also see that it might annoy some users, although these should
> pretty much only be the users who don't like t-m-m but don't hate
> it enough to go through the trouble of turning it off.

Good summary, IMO.

> From: Juri Linkov
> There is a simple principle wrt t-t-m: when the region is active then
> keys change their usual meaning.  With delete-selection-mode this
> includes <delete> and other self-inserting keys in addition to
> existing keys that already have a special meaning in t-m-m.

Another good summary.


If a user doesn't want the advantages and disadvantages of an active region, and
just wants to use the mark and the region as they were before the concept of an
active region, then s?he might as well turn off t-m-mode.

If a user wants an active region (with of course a way to deactivate it), then
d-s-mode makes the most sense. There is not a lot of use for an active region
without the behavior of auto-replace provided by d-s-mode. IMO.

Re: delete-selection-mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Someone (Alan) wrote:
>
>     > You have misconstrued Richard's post.  He went on to say that what is
>     > useful for newcomers isn't necessarily what they expect or "want".
>     > There's thus no indication there that he would support the rest of your
>     > argument.
>
> He is right about what I said, as a general point.
> Whether it is relevant to this issue, I am not sure.
>
> If delete-selection-mode affects only what DEL does after a
> mouse-selection,

It doesn't.  mouse-region-delete-keys is already set in a manner that
DEL deletes a mouse-selected region.  delete-selection-mode extends this
behavior also to regions selected in other ways, and deletes the
contents of the active region also when you type self-inserting
characters.

What you think people are asking for here is already the default.
delete-selection-mode does quite more.

-- 
David Kastrup

Re: delete-selection-mode

[Juri Linkov]

> You have misconstrued Richard's post.  He went on to say that what is
> useful for newcomers isn't necessarily what they expect or "want".
> There's thus no indication there that he would support the rest of your
> argument.

This is exactly how I understood Richard, and I think delete-selection-mode
is useful for newcomers regardless of whether this is what they expect.

> The answer is to ask them why they want this.  C-w is easy to type, as is
> <delete>.

<delete> is not the same as C-w.  <delete> doesn't clobber the kill ring
with unnecessary text.  This is an important distinction.  How come
a powerful editor has no key to delete the selected region without
saving it in the clipboard.

> Emacs isn't about taking things for granted.  It's about efficiency,
> about minimising keystrokes, about not getting in the users' way.  How
> about improving the documentation/menu-settings/whatever so that these
> beginners find what they're looking for?

I agree that it's about efficiency, and delete-selection-mode minimizes
keystrokes thus it makes faster editing.

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

Re: delete-selection-mode

[Kevin Rodgers]

Juri Linkov wrote:
>> You have misconstrued Richard's post.  He went on to say that what is
>> useful for newcomers isn't necessarily what they expect or "want".
>> There's thus no indication there that he would support the rest of your
>> argument.
> 
> This is exactly how I understood Richard, and I think delete-selection-mode
> is useful for newcomers regardless of whether this is what they expect.
> 
>> The answer is to ask them why they want this.  C-w is easy to type, as is
>> <delete>.
> 
> <delete> is not the same as C-w.  <delete> doesn't clobber the kill ring
> with unnecessary text.  This is an important distinction.  How come
> a powerful editor has no key to delete the selected region without
> saving it in the clipboard.

Isn't that exactly what `M-x delete-region' does?

BTW I've had `C-c w' bound to delete-region for years (by analogy with
the default binding of `C-w'  to `kill-region'), so I agree a convenient
way to do that is needed.

Disclaimer: I use neither transient-mark-mode nor delete-selection-mode.

>> Emacs isn't about taking things for granted.  It's about efficiency,
>> about minimising keystrokes, about not getting in the users' way.  How
>> about improving the documentation/menu-settings/whatever so that these
>> beginners find what they're looking for?
> 
> I agree that it's about efficiency, and delete-selection-mode minimizes
> keystrokes thus it makes faster editing.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Chad Brown]

On Mar 17, 2010, at 7:35 AM, Alan Mackenzie wrote:
> The answer is to ask them why they want this.  C-w is easy to type, as is
> <delete>.  delete-select-mode is such an irritating distraction that it
> should only be enabled for those who really, truly want it. 

Currently, when you highlight something with the mouse and then type normal characters, in Emacs:  new characters are added at point and the highlight is removed, while in basically every other editing situation a user faces, the highlighted text is replaced with the typed characters.   For the vast majority of users, the ``irritating distraction'' is that emacs ignores their mouse-selection action as if it had no purpose.  

Honestly, aside from ``you're used to the other way'', what is the upside of intentionally ignoring the user's efforts?   Making the mark stack slightly easier to operate?  You really think that's the way to optimize for new users?

> 
> We've had this discussion often enough in the past.  Do we really have to
> go through these motions yet again?

We're planning for a major release.  Conversations about things that might change have included bidi support, lexical binding, threading, replacing Emacs Lisp with Guile, and replacing the display engine.  Not all of these discussions are going to result in changes to emacs (such as Alin Soare's suggestion to change the display engine), but when Richard is suggesting replacing Emacs Lisp with another language, I think we're in *Exactly* the right time to talk about changing aspects of the default UI for new users.

Thanks,
*Chad

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > The answer is to ask them why they want this.  C-w is easy to type, as is
 > <delete>.

I can't speak for "them," but I want DEL to *delete* the region
because *kill-region* is very often *not* what I want.  Ie, I do not
want the deleted text on the kill ring.  It's also often useful to me
to have the text being replaced on screen as I begin to type the
replacement text, rather than delete and insert separately.  These
small differences really matter, a microsecond here, a half-second
there, it starts to add up to a noticably smoother experience.

 > delete-select-mode is such an irritating distraction

In Emacsen without zmacs-regions/transient-mark-mode on, I agree
strongly.  In Emacs with t-m-m, I disagree strongly.

Yes, veteran users will find the change in defaults (both t-m-m and
delsel, whether simultaneously or sequentially) an irritating
distraction.  There should be a way for veterans to tell Emacs "Read
my lips: No New UI Features", but sadly enough, there isn't.  But vets
know how to turn off such annoyances quickly and permanently.

 > that it should only be enabled for those who really, truly want it.

Which is almost everybody with either no experience or the leisure to
spend a very frustrating 3 days (what it took me to adapt to
zmacs-regions, 15 years ago) to 1 week retraining muscle memory.
t-m-m + delsel is a simple, global improvement as a default *for the
new user*.

 > Emacs isn't about taking things for granted.  It's about
 > efficiency, about minimising keystrokes, about not getting in the
 > users' way.  How about improving the documentation/menu-settings/
 > whatever so that these beginners find what they're looking for?

That's awfully selfish of you.  You know how to find all this stuff,
several different ways.  The beginners aren't even aware that help can
actually be helpful!  (Have you ever been sentenced to trying to work
on a Windows box's configuration or even the Un*x side of a Mac, with
only the platform help as documentation?  Please try it some time
before you ask n00bs to rely on Emacs help -- there's nothing in their
experience to even hint that something so useful is possible!)

Emacs newbies are busy just getting used to fundamental differences
that really matter (the ability to navigate by mark, useful and
consistently accessible histories for almost all commands that take
arguments, motion by semantic text units bigger than words, extreme
customizability via minor modes as well as various options, ability to
use the same editor and commands for tasks as disparate as reading
netnews and cleaning up a directory full of junk files, ... and oh,
yes, "online help" that's really help-full).

Why not give them these very efficient patterns that have proven
themselves not only in software for the braindead, but in daily usage
by thousands of Emacs users as well?

 > No.  We do not want to send Emacs down the slippery slope towards
 > lowest common denominator editors.  We want to encourage Emacs
 > users to use Emacs efficiently, taking advantage of its many
 > features.

Of which t-m-m plus delsel is one.  I'm only sad that you aren't able
to take advantage of it. :^)

Re: delete-selection-mode

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Emacs newbies are busy just getting used to fundamental differences
> that really matter (the ability to navigate by mark,

Which is seriously impacted by delete-selection-mode.

-- 
David Kastrup

Re: delete-selection-mode

[Stephen J. Turnbull]

David Kastrup writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > Emacs newbies are busy just getting used to fundamental differences
 > > that really matter (the ability to navigate by mark,
 > 
 > Which is seriously impacted by delete-selection-mode.

For you, using Emacs.  Not for me, using XEmacs (where zemacs-regions
is not quite t-m-m, and pending-delete mode is not quite delsel).

I did have to learn to use C-u C-SPC instead of C-x C-x, which took a
while, and cost time.  I may have lost some data, but probably not;
"C-x C-x a" usually has pretty spectacular results in pending-delete
mode, and AFAICR I was always able to recover with undo, while the
embarrassment and frustration had a salutary effect on my learning
curve.  Not to mention more time spent using OOo and Mozilla than I'd
really like helped with the educational process.

Dunno if this would work for you, of course.  (The most important
question would likely be whether C-u C-SPC can substitute for C-x C-x
in your usage patterns.)  But that was/is my experience.

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Alan Mackenzie]

Hi, Stephen!

On Thu, Mar 18, 2010 at 01:40:14PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > The answer is to ask them why they want this.  C-w is easy to type,
>  > as is <delete>.

> I can't speak for "them," but I want DEL to *delete* the region
> because *kill-region* is very often *not* what I want.  Ie, I do not
> want the deleted text on the kill ring.

OK, that's an interesting point, but I'm not sure how connected it is to
d-s-m.  Ideally, one wants a keybinding for `delete-region' (which is
already a command), but there aren't any short enough ones free, really;
maybe C-M-x, or something like that.  I also think that the distinction
between kill-region and delete-region would be more confusing than
helpful to a beginner.

> It's also often useful to me to have the text being replaced on screen
> as I begin to type the replacement text, rather than delete and insert
> separately.  These small differences really matter, a microsecond here,
> a half-second there, it starts to add up to a noticably smoother
> experience.

OK.  The penalty for that convenience is having your region explode and
disappear when you accidentally type a self-insert character (or arrow
key).  This might happen if you hit the x before the M in M-x, or
something like that.  Or, you might regionify a defun with C-M-h for some
reason and accidentally lose it.

Clearly the convenience benefit dominates for you; the accidental
explosion hazard dominates for me (in non-Emacs environments, where I
can't disable the (mis)feature).  I've no reason to suspect I'm unusual
here.

It's "obviously" useful to be able to type extra text into an already
"existing" region.  The region is used for many things other than just
being deleted.

>  > delete-select-mode is such an irritating distraction

> In Emacsen without zmacs-regions/transient-mark-mode on, I agree
> strongly.  In Emacs with t-m-m, I disagree strongly.

> Yes, veteran users will find the change in defaults (both t-m-m and
> delsel, whether simultaneously or sequentially) an irritating
> distraction.  There should be a way for veterans to tell Emacs "Read
> my lips: No New UI Features", but sadly enough, there isn't.  But vets
> know how to turn off such annoyances quickly and permanently.

Do they?  How do we know there aren't lots of "veteran" users who don't
really know how to configure the thing?

I think we should also distinguish between pure new UI features, and
those that actively interfere with established usage.  My view is that we
should never make something default in Emacs if it's likely to provoke
the angry reaction "How do I disable this *!£$ing thing?".
delete-select-mode falls into this latter category.  So does
transient-mark-mode.

>  > that it should only be enabled for those who really, truly want it.

> Which is almost everybody with either no experience or the leisure to
> spend a very frustrating 3 days (what it took me to adapt to
> zmacs-regions, 15 years ago) to 1 week retraining muscle memory.
> t-m-m + delsel is a simple, global improvement as a default *for the
> new user*.

I think you might be exaggerating a bit for this particular feature.
It's of the same order of magnitude as swapping the 'z' and 'y' keys (as
one does in moving between English and German keyboard layouts) - it's a
slight irritation, not really a big thing.

Is there any evidence that delete-select-mode is instrinsically a good
thing, disregarding the fact that it has become common?

>  > Emacs isn't about taking things for granted.  It's about efficiency,
>  > about minimising keystrokes, about not getting in the users' way.
>  > How about improving the documentation/menu-settings/ whatever so
>  > that these beginners find what they're looking for?

[ .... ]

> Why not give them [Emacs newbies] these very efficient patterns that
> have proven themselves not only in software for the braindead, but in
> daily usage by thousands of Emacs users as well?

Where is the proof that d-s-m has proven itself efficient, rather than
being mainly an irritation?  That's a genuine question, not a rhetorical
one.

One reason people might have come to Emacs is to escape the (to them)
deity-awful key sequences they've been forced to use up to now.  It is
surely good to offer them an alternative.

>  > No.  We do not want to send Emacs down the slippery slope towards
>  > lowest common denominator editors.  We want to encourage Emacs
>  > users to use Emacs efficiently, taking advantage of its many
>  > features.

> Of which t-m-m plus delsel is one.  I'm only sad that you aren't able
> to take advantage of it. :^)

Me too!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Stephen!
>
> On Thu, Mar 18, 2010 at 01:40:14PM +0900, Stephen J. Turnbull wrote:
>> Alan Mackenzie writes:
>
>>  > The answer is to ask them why they want this.  C-w is easy to type,
>>  > as is <delete>.
>
>> I can't speak for "them," but I want DEL to *delete* the region
>> because *kill-region* is very often *not* what I want.  Ie, I do not
>> want the deleted text on the kill ring.
>
> OK, that's an interesting point, but I'm not sure how connected it is
> to d-s-m.

I also don't think it is a good idea to tie the distinction delete/kill
into a side effect of different workflows.

> OK.  The penalty for that convenience is having your region explode
> and disappear when you accidentally type a self-insert character (or
> arrow key).  This might happen if you hit the x before the M in M-x,
> or something like that.  Or, you might regionify a defun with C-M-h
> for some reason and accidentally lose it.

For the record: I just noticed that a few minutes ago I yanked some
stuff from one buffer into a different buffer, then used C-x C-x to move
to the top of the inserted material in order to add a newline and some
other stuff there.

delete-insertion-mode would have just deleted my inserted material
again.

The sequence C-y C-x C-x is rather common in my usage patterns.  And I
don't know an equally convenient substitute.

-- 
David Kastrup

Re: delete-selection-mode

[Stefan Monnier]

> For the record: I just noticed that a few minutes ago I yanked some
> stuff from one buffer into a different buffer, then used C-x C-x to move
> to the top of the inserted material in order to add a newline and some
> other stuff there.

Were you mildly annoyed by the highlighting that was displayed between
C-x C-x and when you inserted the "newline and other stuff"?

> The sequence C-y C-x C-x is rather common in my usage patterns.  And I
> don't know an equally convenient substitute.

C-y C-u C-x C-x would do the trick (at the cost of an extra key stroke,
obviously, tho in this case it might not be too inconvenient since C-u
is right next to C-y on the keyboard).


        Stefan

Re: delete-selection-mode

[David Kastrup]

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

>> For the record: I just noticed that a few minutes ago I yanked some
>> stuff from one buffer into a different buffer, then used C-x C-x to move
>> to the top of the inserted material in order to add a newline and some
>> other stuff there.
>
> Were you mildly annoyed by the highlighting that was displayed between
> C-x C-x and when you inserted the "newline and other stuff"?

I type fast enough for it not to make a difference, and it is expected
by now.  It also sort of acts like a really strong indication of where
the cursor jumped.

>> The sequence C-y C-x C-x is rather common in my usage patterns.  And I
>> don't know an equally convenient substitute.
>
> C-y C-u C-x C-x would do the trick (at the cost of an extra key stroke,
> obviously, tho in this case it might not be too inconvenient since C-u
> is right next to C-y on the keyboard).

"equally convenient".  C-u C-x C-x is a complex concept, not an idiom in
itself.

-- 
David Kastrup

RE: delete-selection-mode

[Drew Adams]

> For the record: I just noticed that a few minutes ago I yanked some
> stuff from one buffer into a different buffer, then used C-x 
> C-x to move to the top of the inserted material in order to add a
> newline and some other stuff there.
> 
> delete-insertion-mode would have just deleted my inserted material
> again.
> 
> The sequence C-y C-x C-x is rather common in my usage patterns.  And I
> don't know an equally convenient substitute.

C-y C-x C-x C-g     or    C-y C-u C-x C-x
            ^^^               ^^^

Honestly, each example you give of being disturbed by the active region, wanting
it to be inactive, is in effect the *same example*.

When you don't want the region to be active, either do not activate it or
deactivate it. If you never want an active region, then turn off t-m-mode.

Re: delete-selection-mode

[David Kastrup]

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

>> For the record: I just noticed that a few minutes ago I yanked some
>> stuff from one buffer into a different buffer, then used C-x 
>> C-x to move to the top of the inserted material in order to add a
>> newline and some other stuff there.
>> 
>> delete-insertion-mode would have just deleted my inserted material
>> again.
>> 
>> The sequence C-y C-x C-x is rather common in my usage patterns.  And I
>> don't know an equally convenient substitute.
>
> C-y C-x C-x C-g     or    C-y C-u C-x C-x
>             ^^^               ^^^
>
> Honestly, each example you give of being disturbed by the active
> region, wanting it to be inactive, is in effect the *same example*.

Sure: working with the mark without wanting bad side-effects from an
incidentally activated region.

> When you don't want the region to be active, either do not activate it

You can't set the mark without activating it.

> or deactivate it. If you never want an active region, then turn off
> t-m-mode.

I already said that I'd consider transient-mark-mode _off_ again a good
solution and have an active region for shift-selection, mouse-selected,
and explicit temporary transient-mark-mode.  In which case I don't mind
delete-selection-mode much since it is in effect only for explicitly
selected _regions_ instead of being a side-effect of using the _mark_.

I have heard no arguments against that.  I don't consider it part of
adult discussions to repeat the same point over and over again, so I
won't repeat this.  But I find it exasperating that people wear their
blinders to a degree where they blend everything out that differs from
their preconceptions about _how_ to best achieve their goals.

-- 
David Kastrup

Re: delete-selection-mode

[Lennart Borgman]

On Thu, Mar 18, 2010 at 7:27 PM, David Kastrup <dak@gnu.org> wrote:
>
> I already said that I'd consider transient-mark-mode _off_ again a good
> solution and have an active region for shift-selection, mouse-selected,
> and explicit temporary transient-mark-mode.  In which case I don't mind
> delete-selection-mode much since it is in effect only for explicitly
> selected _regions_ instead of being a side-effect of using the _mark_.
>
> I have heard no arguments against that.


That might be because no one really thought you wanted that. Was not
transient-mark-mode turned on by default to make Emacs default
behaviour a bit more like other editing environments? (I do not
remember since I prefer cua-mode and would expect most new users to do
the same. However this seems like an impossible solution currently,
unfortunately.)

Re: delete-selection-mode

[David Kastrup]

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

> On Thu, Mar 18, 2010 at 7:27 PM, David Kastrup <dak@gnu.org> wrote:
>>
>> I already said that I'd consider transient-mark-mode _off_ again a good
>> solution and have an active region for shift-selection, mouse-selected,
>> and explicit temporary transient-mark-mode.  In which case I don't mind
>> delete-selection-mode much since it is in effect only for explicitly
>> selected _regions_ instead of being a side-effect of using the _mark_.
>>
>> I have heard no arguments against that.
>
>
> That might be because no one really thought you wanted that. Was not
> transient-mark-mode turned on by default to make Emacs default
> behaviour a bit more like other editing environments?

Yes.  But since then we got shift-selection-mode, and also sort of
parallel the behavior of mouse-selections was mostly folded with
temporary transient-mark-mode.

So by now basically every non-historic way of setting a region makes it
active (or should?) even if transient-mark-mode is disabled.

That gives us a reasonable chance to obliterate all differences between
region-activating commands (like mouse-region-delete-keys) without
causing anybody pain.

-- 
David Kastrup

Re: delete-selection-mode

[Stefan Monnier]

> So by now basically every non-historic way of setting a region makes it
> active (or should?) even if transient-mark-mode is disabled.

Actually all the mark-* functions don't activate the mark if t-m-m
is disabled.

IIUC what you're suggesting is to enable delsel but in return to make
C-SPC and C-x C-x not activate the region any more.


        Stefan

Re: delete-selection-mode

[David Kastrup]

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

>> So by now basically every non-historic way of setting a region makes it
>> active (or should?) even if transient-mark-mode is disabled.
>
> Actually all the mark-* functions don't activate the mark if t-m-m
> is disabled.

Yes.  That might be worth revisiting.

> IIUC what you're suggesting is to enable delsel but in return to make
> C-SPC and C-x C-x not activate the region any more.

I guess that would be about it.

-- 
David Kastrup

RE: delete-selection-mode

[Drew Adams]

> >> So by now basically every non-historic way of setting a 
> >> region makes it active (or should?) even if
> >> transient-mark-mode is disabled.
> >
> > Actually all the mark-* functions don't activate the mark if t-m-m
> > is disabled.
> 
> Yes.  That might be worth revisiting.

Why? Revisit how? Do you want them to activate the mark if t-m-mode is disabled?

That's a contradiction in terms, anyway. There is no notion of "active" region
when t-m-mode is disabled. It is a concept that applies only to t-m-mode (and
modes that enable t-m-mode).

Any function whose behavior depends on whether the region is active only does so
when t-m-mode is enabled.

It cannot do otherwise, since the region is never activated with t-m-mode
disabled. It's neither active nor inactive then - the notion of activeness just
doesn't apply in that context.

> > IIUC what you're suggesting is to enable delsel but in 
> > return to make C-SPC and C-x C-x not activate the region any more.
> 
> I guess that would be about it.

And what will you call that? Yet another selection mechanism for users to wrap
their heads around? It's not `delete-selection-mode', and it's not anything we
have now. Why go there?

And I hope you're not suggesting to change d-s-mode _itself_ to act like that.
Please leave d-s-mode alone, whatever changes you make. Don't bother to use
d-s-mode as the default, if you don't want it, but please don't mess it up.

RE: delete-selection-mode

[Drew Adams]

> You can't set the mark without activating it.

C-u C-SPC

Or just turn off t-m-mode.

> > or deactivate it. If you never want an active region, then
> > turn off t-m-mode.
> 
> I already said that I'd consider transient-mark-mode _off_ 
> again a good solution and have an active region for shift-selection, 
> mouse-selected, and explicit temporary transient-mark-mode.
> In which case I don't mind delete-selection-mode much since it
> is in effect only for explicitly selected _regions_ instead of
> being a side-effect of using the _mark_.

You don't mind d-s-mode if it is no longer d-s-mode. Nice.

> I have heard no arguments against that.

Sure you have, and from more than one person.

1. Other things being equal, inconsistency between mouse and keyboard wrt the
region is bad (yes, it's already bad that we have some such inconsistency, IMO).

2. t-m-mode as the default has already been decided. You want to rehash that
whole debate, diverting the current discussion to repeat the last one. I don't.
So for that, I will not repeat the arguments in favor of t-m-mode given the last
time this was debated. Suffice it to say the t-m-mode was enabled for good
reasons. If you don't remember them, then please go read the archives.

3. Just as it is useful for you to set mark and move somewhere to create the
region for your purposes, so it is useful to do that to create an active region.
There is no reason to give you that possibility for an active region (e.g. C-M-h
to select a defun) but not have the same thing available for selecting an active
region. 

It is not right to try to relegate active selection to shift-arrows and the
mouse. FWIW, I almost never use shift selection to select text. (I do sometimes
use the mouse.) What's useful for the goose is useful for the gander. Region
definition should be as flexible and multifarious for an active region as for an
inactive one.

Re: delete-selection-mode

[Stefan Monnier]

>> You can't set the mark without activating it.
> C-u C-SPC

Actually, it's C-SPC C-SPC (which is better/shorter).


        Stefan

RE: delete-selection-mode

[Drew Adams]

> >> You can't set the mark without activating it.
> >
> > C-u C-SPC
> 
> Actually, it's C-SPC C-SPC (which is better/shorter).

Yes, sorry. (And I think I wrote that in two replies.)

Re: delete-selection-mode

[David Kastrup]

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

>> You can't set the mark without activating it.
>
> C-u C-SPC
>
> Or just turn off t-m-mode.
>
>> > or deactivate it. If you never want an active region, then
>> > turn off t-m-mode.
>> 
>> I already said that I'd consider transient-mark-mode _off_ 
>> again a good solution and have an active region for shift-selection, 
>> mouse-selected, and explicit temporary transient-mark-mode.
>> In which case I don't mind delete-selection-mode much since it
>> is in effect only for explicitly selected _regions_ instead of
>> being a side-effect of using the _mark_.
>
> You don't mind d-s-mode if it is no longer d-s-mode. Nice.
>
>> I have heard no arguments against that.
>
> Sure you have, and from more than one person.
>
> 1. Other things being equal, inconsistency between mouse and keyboard
> wrt the region is bad (yes, it's already bad that we have some such
> inconsistency, IMO).

There is no inconsistency.  Commands that set a _region_ set an active
region.  Commands that are supposed to set the mark without activating
it, set the mark without activating it.  All newcomer mouse and key
sequences belong to "set the region" and activate it.

> 2. t-m-mode as the default has already been decided.

Before we had shift-selection mode, and mouse-selections autoactivated
the region.

-- 
David Kastrup

RE: delete-selection-mode

[Drew Adams]

> > 1. Other things being equal, inconsistency between mouse 
> > and keyboard wrt the region is bad (yes, it's already bad that
> > we have some such inconsistency, IMO).
> 
> There is no inconsistency.  Commands that set a _region_ set an active
> region.  Commands that are supposed to set the mark without activating
> it, set the mark without activating it.  All newcomer mouse and key
> sequences belong to "set the region" and activate it.

All commands that set the mark "set" the region (whatever setting the region
might mean). The mark's position defines one end of the region.

It's not just about newcomer vs oldcomer. d-s-mode (complete, not partial or
modified) is useful for all kinds of users.

> > 2. t-m-mode as the default has already been decided.
> 
> Before we had shift-selection mode, and mouse-selections autoactivated
> the region.

And I was against adding those, because they introduce exceptional behavior
(inconsistencies, IMO), as does DEL for a mouse selection.

I was never in favor of the halfway measure of trying to make mouse selection
act somewhat like what outside users are used to, without going all the way to
`delete-selection-mode'.

Re: delete-selection-mode

[Johan Bockgård]

David Kastrup <dak@gnu.org> writes:

> The sequence C-y C-x C-x is rather common in my usage patterns.  And I
> don't know an equally convenient substitute.

C-u C-y

Re: delete-selection-mode

[Jason Rumney]

Alan Mackenzie <acm@muc.de> writes:


> My view is that we should never make something default in Emacs if
> it's likely to provoke the angry reaction "How do I disable this
> *!£$ing thing?".  delete-select-mode falls into this latter category.
> So does transient-mark-mode.

So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
highlighting and almost every other change we've made to Emacs over the
years.

Re: delete-selection-mode

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>
>> My view is that we should never make something default in Emacs if
>> it's likely to provoke the angry reaction "How do I disable this
>> *!£$ing thing?".  delete-select-mode falls into this latter category.
>> So does transient-mark-mode.
>
> So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
> highlighting and almost every other change we've made to Emacs over
> the years.

None of them destroy your text given the same keystrokes.

-- 
David Kastrup

RE: delete-selection-mode

[Berndl, Klaus]

>David Katrup writes:

>>Jason Rumney <jasonr@gnu.org> writes:

>>> Alan Mackenzie <acm@muc.de> writes:
>>> My view is that we should never make something default in Emacs if
>>> it's likely to provoke the angry reaction "How do I disable this
>>> *!£$ing thing?".  delete-select-mode falls into this latter category.
>>> So does transient-mark-mode.
>>
>> So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
>> highlighting and almost every other change we've made to Emacs over
>> the years.

>None of them destroy your text given the same keystrokes.

I'm pretty sure you will not find the jack of all trades device which will satisfy the
needs of Emacs newcommers as well as the needs of the old-timers... But this isn't
necessary. Why to fight against?

The only question is: Do we prefer a default which supports best the Emacs gurus using it
for 1000 years or a default which drops down the entry barriers for people who come from
the other planets? There is no need for trying to convince the "other side" that "this-is-the
one-and-only-and-best-of-all-way for dealing with selections. There is NO one-and-only-way.

Yes, you are right when you say, delete-selection-mode off has some advantages, no doubt.

But the Emacs team must take a decision: Is it a main goal for Emacs to "acquire" many
newcomers or is this not a main goal?! If not, then there is no need to make
something like delete-selection-mode on by default, then you can save the time for this
discussion. But if this is a main goal: Then you will have to break down the "wall around
Emacs". Of course there is no wall in fact but i hope you understand what i try to say.

1000 years ago emacs could cook it own soup no problem...but today quite all people use
web browsers, text-processors (regardless if open source or Microsoft) etc. And all these
programs - regardless if running on Linux, Unix, Mac OS or Windows - perform the same way:
If there is a selection and you hit DEL then the selection is deleted and if you hit any
"self-inserting" key then this key replaces the selection. At least i do not know any
program with substantial propagation which interferes with this approach.

People are used to this behavior. No, not only used to it but this behavior is became
ingrained. It is a de-facto standard and thereforew it is not the question if this is 
the best behavior or not. We have simply to accept that this is THE behavior.

Most people coming from the not-Emacs-world will not give Emacs a try if these fundamental
behaviors differ from their expectations. Cars having the gearstick not in front of the
central console between the front-seats but having instead a steering idler arm will not 
have great success in the market (BMW has tried this in their recent 7-series but they came
back to the de-facto standard between the seats because people want to see fundamental
standards fullfilled).

To come back to my introducion question about the main goals of Emacs development: If you
want new peoples then you should break down the entry barrier into this great tool Emacs.
In consequence this means to set appropriate defaults. Experienced users can switch between
one second to their loved emacs-behavior. Do not try to evangelize new peoples. First let
them in, then give them some hints and pointers what alternatives Emacs offers and why they
could be even better than the known standards... If people have become more familiar with
Emacs maybe they are open for the emacs-world... ;-). BUT FIRST LET THEM IN!

Klaus

Re: delete-selection-mode

[David Kastrup]

"Berndl, Klaus" <klaus.berndl@capgemini-sdm.com> writes:

> The only question is: Do we prefer a default which supports best the
> Emacs gurus using it for 1000 years or a default which drops down the
> entry barriers for people who come from the other planets?

What entry barrier would that be?

> There is no need for trying to convince the "other side" that
> "this-is-the one-and-only-and-best-of-all-way for dealing with
> selections. There is NO one-and-only-way.
>
> Yes, you are right when you say, delete-selection-mode off has some
> advantages, no doubt.

delete-selection-mode interferes with the _Emacs_ way of dealing with
marks.

Personally, I'd be fine to have the equivalent of delete-selection-mode
for mouse-selected areas (where DEL already works) and for
shift-selected areas.

I'm not fine with having delete-selection-mode for by-products of
transient marks occuring during the normal operation of Emacs.

If we want to go there, my vote is for turning off transient-mark-mode
again while keeping the rest (apart from scrapping
mouse-region-delete-keys which is not necessary once
delete-selection-mode is on).  We have temporary transient-mark-mode,
shift-selected transient-mark-mode, mouse-selected transient-mark-mode.
There is a number of ways to express "I really want to set an active
region" as opposed to "I want to set the mark".  Our traditional
mark-xxx keybindings have accompanying kill-xxx keybindings: they don't
need transient-mark-mode/delete-selection-mode.  If you really want to
delete without affecting the kill buffer, presumably C-u C-x C-x DEL
after marking or C-SPC C-SPC before marking would work then _IF_ we keep
the "delete rather than kill the active region" behavior.

Newcomers working with their accustomed keybindings will never notice
that transient-mark-mode is off.  They will get an active region for all
those ways of creating an active region that they are accustomed to.

> But the Emacs team must take a decision: Is it a main goal for Emacs
> to "acquire" many newcomers or is this not a main goal?!

It is a goal, but not a main goal.  And you won't acquire newcomers by
swatting them with inconsistent and incomprehensible overall behavior
for which no rationale can be given.

-- 
David Kastrup

AW: delete-selection-mode

[Berndl, Klaus]

>> But the Emacs team must take a decision: Is it a main goal for Emacs
>> to "acquire" many newcomers or is this not a main goal?!

>It is a goal, but not a main goal.  And you won't acquire newcomers by
>swatting them with inconsistent and incomprehensible overall behavior
>for which no rationale can be given.

Here i fully agree. My vote is not especially for delete-selection-mode is on
as default but for a default behavior newcomer-people would expect when dealing with
selections. And you are fully right with your request for a consistent behavior.
I admit i can not follow all your explanation and recommendations but i can say,
that i would find it best if the behavior would always be the same regardless if the
selection was made by mouse or by keyboard: Always if there is a highlighted
selection then the behavior should be the same: DEL and self-inserting keys
delete the selection and do not affect the kill-ring. Or more generally: Emacs should
handle highlighted selections by default exactly as any other program too, this means
the way to create such selections and how to deal with them (For example i always use
cua-mode and this mode works perfectly for what i want and - IMHO - what new people
mostly expect from a program which supports inserting text)

There should be exactly one screw to switch this on and this screw should be switched on
by default.

Klaus

-- 
David Kastrup

RE: delete-selection-mode

[Drew Adams]

> delete-selection-mode interferes with the _Emacs_ way
> of dealing with marks.

Your own way of using Emacs is not THE EMACS WAY.
Emacs is bigger and better than that.

With d-s-mode turned on you can still use the mark purely navigationally,
whenever you want. Just deactivate the region (or don't activate it).

Emacs gives users the best of both worlds: an active region (with
type-to-replace) and an inactive region. And by default the region is (should
be) active, which is what most people expect. Que demande le peuple ? 

> I'm not fine with having delete-selection-mode for by-products of
> transient marks occuring during the normal operation of Emacs.

So turn off d-s-mode in your .emacs. Or turn off t-m-mode, since it doesn't
sound like you use the active region for anything anyway.

> my vote is for turning off transient-mark-mode again

So I wasn't wrong in my guess. Out of the closet at last.
That's what this is all about, isn't it?

Re: delete-selection-mode

[Juri Linkov]

>> So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
>> highlighting and almost every other change we've made to Emacs over
>> the years.
>
> None of them destroy your text given the same keystrokes.

You can accidentally type C-w and destroy your text.

Actually, pre-22 default behavior was very dangerous.

I remember inadvertently destroying the text (with C-w etc.) many times
when t-m-m was off, because when I thought the mark was in one place,
it actually was in another.  Now thanks to t-m-m I can see the region
boundaries, and with the combination of t-m-m + d-s-m I never had a case
of destroying the text.

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

Re: delete-selection-mode

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>>> So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
>>> highlighting and almost every other change we've made to Emacs over
>>> the years.
>>
>> None of them destroy your text given the same keystrokes.
>
> You can accidentally type C-w and destroy your text.

They are very different cases:

Hitting C-w when you didn't intend to is a relatively uncommon
occurrence.  When you _do_ intend to hit C-w, because the command is
inherently associated with the region, you're _much_ more likely to be
aware of the state of the region.

Accidentally deleting text because of an inadvertently selected (often
very small) region, on the other hand, is quite easy to do.  The problem
here is that the very very common case of inserting text does _not_
(normally) depend on the region, so it's very easy for a user to start
typing without being aware of the region's state.

[The reason I know about this annoying issue with "type to delete",
BTW, is because it regularly happens to me (not in Emacs, obviously!]

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
>>> highlighting and almost every other change we've made to Emacs over
>>> the years.
>>
>> None of them destroy your text given the same keystrokes.
>
> You can accidentally type C-w and destroy your text.

C-y undoes the damage even in buffers without undo history.

-- 
David Kastrup

Re: delete-selection-mode

[Juri Linkov]

>>>> So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
>>>> highlighting and almost every other change we've made to Emacs over
>>>> the years.
>>>
>>> None of them destroy your text given the same keystrokes.
>>
>> You can accidentally type C-w and destroy your text.
>
> C-y undoes the damage even in buffers without undo history.

I meant the cases when deletion went unnoticed.  With the active region
this is less likely, because you have a clear visual indication when
the region is active.

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

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>>>> So do fringes, toolbars, menus, scrollbars, the splash screen, syntax
>>>>> highlighting and almost every other change we've made to Emacs over
>>>>> the years.
>>>>
>>>> None of them destroy your text given the same keystrokes.
>>>
>>> You can accidentally type C-w and destroy your text.
>>
>> C-y undoes the damage even in buffers without undo history.
>
> I meant the cases when deletion went unnoticed.  With the active region
> this is less likely, because you have a clear visual indication when
> the region is active.

You type C-w to pass the time?  Pretty much _all_ commands change the
buffer without warning.

-- 
David Kastrup

Re: delete-selection-mode

[Stefan Monnier]

> I also think that the distinction between kill-region and
> delete-region would be more confusing than helpful to a beginner.

Indeed.

> OK.  The penalty for that convenience is having your region explode and
> disappear when you accidentally type a self-insert character (or arrow
> key).  This might happen if you hit the x before the M in M-x, or
> something like that.  Or, you might regionify a defun with C-M-h for some
> reason and accidentally lose it.

These are very valid concerns, and even if we don't enable delsel by
default, I think we should try and come up with ways to reduce the pain.
E.g. making sure that you can revert the damage with `undo' (e.g. the
delsel behavior should only affect buffer where undo is enabled; and
maybe undoing a self-insert which also deleted the region might undo the
self-insert, undo the delete-region *and* re-activate the region).

> It's "obviously" useful to be able to type extra text into an already
> "existing" region.  The region is used for many things other than just
> being deleted.

Maybe there should be more ways than C-g to deactivate the region:
Currently, self-insert is one such way, but with delsel that extra way
is removed.

>> > delete-select-mode is such an irritating distraction
>> In Emacsen without zmacs-regions/transient-mark-mode on, I agree
>> strongly.  In Emacs with t-m-m, I disagree strongly.

delsel only applies to active regions, so it shouldn't affect users when
t-m-m is disabled.  That would seem to imply that overall you disagree
strongly with "delete-select-mode is such an irritating distraction".
Yet, your message seems to indicate otherwise.  What am I missing?

> I think we should also distinguish between pure new UI features, and
> those that actively interfere with established usage.  My view is that we
> should never make something default in Emacs if it's likely to provoke
> the angry reaction "How do I disable this *!£$ing thing?".
> delete-select-mode falls into this latter category.  So does
> transient-mark-mode.

Many things have fallen into this category in the past:
- X11 (need to use -nw).
- menu-bar
- tool-bar
- scroll-bar
- fringes
- blinking-cursor
- t-m-m
- font-lock
- mouse-1-click-follows-link
- "prettification" of info buffers
Luckily, we don't have to care too much about those conservative
veterans, because honestly their only alternative is Emacs-NN (where NN
is smaller than some threshold): pretty much all other applications
impose changes to their UI at a faster pace than Emacs ;-)

> Is there any evidence that delete-select-mode is instrinsically a good
> thing, disregarding the fact that it has become common?

For DEL, I think it is very natural, yes.  For self-insert, I'm not
really sure: I haven't been annoyed by it, but I haven't used it
much either.


        Stefan

Re: delete-selection-mode

[David Kastrup]

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

>> I also think that the distinction between kill-region and
>> delete-region would be more confusing than helpful to a beginner.
>
> Indeed.
>
>> OK.  The penalty for that convenience is having your region explode and
>> disappear when you accidentally type a self-insert character (or arrow
>> key).  This might happen if you hit the x before the M in M-x, or
>> something like that.  Or, you might regionify a defun with C-M-h for some
>> reason and accidentally lose it.
>
> These are very valid concerns, and even if we don't enable delsel by
> default, I think we should try and come up with ways to reduce the
> pain.  E.g. making sure that you can revert the damage with `undo'
> (e.g. the delsel behavior should only affect buffer where undo is
> enabled; and maybe undoing a self-insert which also deleted the region
> might undo the self-insert, undo the delete-region *and* re-activate
> the region).

I already mentioned the pattern C-y C-x C-x for inserting/modifying at
the top of a yanked insertion.

> delsel only applies to active regions, so it shouldn't affect users
> when t-m-m is disabled.

We have temporary transient mark mode, which is also turned on with
mouse selections.

> Many things have fallen into this category in the past:
> - X11 (need to use -nw).
> - menu-bar
> - tool-bar
> - scroll-bar
> - fringes
> - blinking-cursor
> - t-m-m
> - font-lock
> - mouse-1-click-follows-link
> - "prettification" of info buffers

None of those destroy your text.

>> Is there any evidence that delete-select-mode is instrinsically a
>> good thing, disregarding the fact that it has become common?
>
> For DEL, I think it is very natural, yes.  For self-insert, I'm not
> really sure: I haven't been annoyed by it, but I haven't used it much
> either.

I think it is somewhat natural after mouse selections: after all, there
would be little point in mouse-selecting a region only to insert at one
end of the region.  There is the possible use of double/triple-clicking
in order to _move_ fast to beginning of word/line, but I don't think
that people make use of that much.

So something which extends mouse-region-delete-keys' functionality to
self-insert would not bother me.

-- 
David Kastrup

RE: delete-selection-mode (was: Put scroll-bar on right by defaulton UNIX.)

[Drew Adams]

> > It's also often useful to me to have the text being 
> > replaced on screen as I begin to type the replacement text,
> > rather than delete and insert separately.

Him and me and zillions of others.

> OK.  The penalty for that convenience is having your region 
> explode and disappear when you accidentally type a self-insert
> character (or arrow key).  This might happen if you hit the x
> before the M in M-x, or something like that.  Or, you might
> regionify a defun with C-M-h for some
> reason and accidentally lose it. 

The risk you describe exists in theory, and I suppose it occurs occasionally in
practice. But honestly, my impression is that you simply have not used d-s-mode
much or this would not be a problem in practice.

99.999% (no, no proof; just a guess) of computer users out there use this
"risky" behavior everyday, all day long, without exploding (and without Emac's
powerful undo as a remedy).

I submit that you see it as a problem simply because you are not used to it. If
you don't treat the active region as, well, active, then yes, you'll probably
step on your own toes a few times.

> the accidental explosion hazard dominates for me (in non-Emacs
> environments, where I can't disable the (mis)feature).

Well now. That's JUST EXACTLY the problem we're trying to solve by making the
Emacs default behavior resemble the behavior outside Emacs.

Your solution is perhaps to avoid using anything outside Emacs (since you can't
make that fit the behavior you're used to). That's not a general solution,
especially in terms of making Emacs accessible to people who are already "out
there".

> It's "obviously" useful to be able to type extra text into an already
> "existing" region.  The region is used for many things other than just
> being deleted.

Not a problem. It is only when the region is *active* that typing replaces it.
Emacs gives you the best of both worlds: the region can be active or inactive.

> we should never make something default in Emacs if it's likely to
> provoke the angry reaction "How do I disable this *!£$ing thing?".
> delete-select-mode falls into this latter category.  So does
> transient-mark-mode.

So we should remove t-m-mode as the default?

We all agree that whatever the default behavior is we should do our best to let
users know how to change the defaults.

> Is there any evidence that delete-select-mode is instrinsically a good
> thing, disregarding the fact that it has become common?

Which do you do more often: (a) replace the text in the region or (b) set mark,
move somewhere else, and insert text?

With d-s-mode, the former is simple and the latter requires that you hit C-g (to
deactivate the region). Without d-s-mode, the latter is simple and the former
requires that you hit C-w (or DEL/delete-region).

You could say "six of one; half a dozen of the other - a toss-up". If you think
that, then we're back to the argument about fit (by default) with the outside
world. And that argument is not negligible.

> One reason people might have come to Emacs is to escape the (to them)
> deity-awful key sequences they've been forced to use up to now.

That's an amazing statement, Alan. I've never heard anyone claim that people
come to Emacs because the key sequences they use elsewhere are too difficult.
It's usually the opposite we hear about Emacs: "What's with all the crazy C-M-S-
contortions?"

You've been inside Emacs so long that it's second nature to you. Take a look
outside the window, and imagine that you're out there looking in at Emacs. This
is about setting the default value. In particular, it's about picking a default
that is helpful to new users but is also useful in general.

Re: delete-selection-mode

[David Kastrup]

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

> The risk you describe exists in theory, and I suppose it occurs
> occasionally in practice. But honestly, my impression is that you
> simply have not used d-s-mode much or this would not be a problem in
> practice.
>
> 99.999% (no, no proof; just a guess) of computer users out there use
> this "risky" behavior everyday, all day long, without exploding (and
> without Emac's powerful undo as a remedy).

It is an occasional occuring nuisance in one-line entry lines (where it
causes extra work), and it would be a perfect menace on multi-line
entry, but I don't know of any multi-line entry fields in applications
that don't have undo, most particular not with text editors.

So please match your descriptions of "the rest of the world" to existing
realities.

>> the accidental explosion hazard dominates for me (in non-Emacs
>> environments, where I can't disable the (mis)feature).
>
> Well now. That's JUST EXACTLY the problem we're trying to solve by
> making the Emacs default behavior resemble the behavior outside Emacs.

Applications outside of Emacs don't have a mark concept independent of
active regions.  Emacs does.  Realities don't go away by ignoring them.

> Not a problem. It is only when the region is *active* that typing
> replaces it.  Emacs gives you the best of both worlds: the region can
> be active or inactive.

With transient-mark-mode, it will be active by default, even when you
just wanted to manipulate the mark.

> So we should remove t-m-mode as the default?

If all region marking operations beginners are accustomed to can create
an active region without reverting to transient-mark-mode (and Emacs got
there with mouse-selection and shift-selection), why not?

It makes things more consistent and avoids accidentally active regions
and the connected behavior.

>> Is there any evidence that delete-select-mode is instrinsically a good
>> thing, disregarding the fact that it has become common?
>
> Which do you do more often: (a) replace the text in the region or (b)
> set mark, move somewhere else, and insert text?

Depends on whether I have set the mark for the purpose of creating an
active region or not.

-- 
David Kastrup

Re: delete-selection-mode

[Chad Brown]

On Mar 18, 2010, at 11:35 AM, David Kastrup wrote:

> "Drew Adams" <drew.adams@oracle.com> writes:
> 
>> The risk you describe exists in theory, and I suppose it occurs
>> occasionally in practice. But honestly, my impression is that you
>> simply have not used d-s-mode much or this would not be a problem in
>> practice.
>> 
>> 99.999% (no, no proof; just a guess) of computer users out there use
>> this "risky" behavior everyday, all day long, without exploding (and
>> without Emac's powerful undo as a remedy).
> 
> It is an occasional occuring nuisance in one-line entry lines (where it
> causes extra work), and it would be a perfect menace on multi-line
> entry, but I don't know of any multi-line entry fields in applications
> that don't have undo, most particular not with text editors.
> 
> So please match your descriptions of "the rest of the world" to existing
> realities.

Every web browser any new user is likely to use, anywhere, every time.  This will be at least 50% of the experience of new users -- probably more, and growing every day.

RE: delete-selection-mode

[Drew Adams]

> With transient-mark-mode, it will be active by default, even when you
> just wanted to manipulate the mark.

1. C-u C-SPC instead of C-SPC. Or just turn off t-m-mode.

2. t-m-mode by default has already been decided. Why do you keep trying to
divert the question?

Re: delete-selection-mode

[David Kastrup]

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

>> With transient-mark-mode, it will be active by default, even when you
>> just wanted to manipulate the mark.
>
> 1. C-u C-SPC instead of C-SPC. Or just turn off t-m-mode.

If you can't remember, a newbie would?

-- 
David Kastrup

RE: delete-selection-mode

[Drew Adams]

> >> With transient-mark-mode, it will be active by default, 
> >> even when you just wanted to manipulate the mark.
> >
> > C-u C-SPC instead of C-SPC. Or just turn off t-m-mode.
> 
> If you can't remember, a newbie would?

a. Your citation is off. Presumably, you meant to quote Stefan correcting my
mention of C-u C-SPC instead of C-SPC C-SPC. Ever type one thing and think
another? Mea culpa - I did.

b. I don't actually use C-SPC C-SPC. I don't use the "temporary
transient-mark-mode" (or its opposite). Ever. But you might want to.

I use `delete-selection-mode' - that's it. If I ever need to deactivate the
region, I use C-g. I've used d-s-mode for decades - long before any temporary
t-m-mode existed. And I've never missed such a feature. To me, it's a solution
looking for a problem.

c. I don't particularly expect a newbie (or anyone else) to remember C-SPC C-SPC
- and I don't really care whether s?he does.

I would like to give newbies the selection behavior they expect by default:
d-s-mode. That's all.

And no, that doesn't involve temporary t-m-mode. They don't use such a thing
outside Emacs, and they won't use it - at least at the beginning - inside Emacs.
And maybe, like me, they will never feel a need to use it.

Re: delete-selection-mode

[David Kastrup]

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

>> >> With transient-mark-mode, it will be active by default, 
>> >> even when you just wanted to manipulate the mark.
>> >
>> > C-u C-SPC instead of C-SPC. Or just turn off t-m-mode.
>> 
>> If you can't remember, a newbie would?
>
> a. Your citation is off. Presumably, you meant to quote Stefan correcting my
> mention of C-u C-SPC instead of C-SPC C-SPC. Ever type one thing and think
> another? Mea culpa - I did.
>
> b. I don't actually use C-SPC C-SPC. I don't use the "temporary
> transient-mark-mode" (or its opposite). Ever. But you might want to.
>
> I use `delete-selection-mode' - that's it. If I ever need to deactivate the
> region, I use C-g. I've used d-s-mode for decades - long before any temporary
> t-m-mode existed.

Then perhaps you should leave the discussion until those that remember
life without delete-selection-mode have sorted out the problems with
making it the default.

The Emacs way of getting a feature activated by default is not throwing
a tantrum until everybody gives in, but making the feature work smoothly
with other use cases and workflows.

That is the way to overcome resistance.  Throwing tantrums, in contrast,
distracts from the work, thoughts, and discussions that are needed to
properly make a feature fit in as a part with the rest of Emacs.

Your point is abundantly clear: "I want delete-selection-mode enabled
and nothing else changed".  Everybody got it by now.  Repeating it
without reacting to anything other people bring up is not going to help
resolve those points.

So you might want to stay off this discussion for a week or so and see
whether people make progress with plans about moving Emacs towards a
state where delete-selection-mode as a default is less of a bad idea as
it is now.  It is obvious that you are not wanting to participate in any
such discussion in a constructive way.

-- 
David Kastrup

RE: delete-selection-mode

[Drew Adams]

> Then perhaps you should leave the discussion until those that remember
> life without delete-selection-mode have sorted out the problems with
> making it the default.

No, please, don't make it the default. Don't go near it. Just leave it alone. Go
back to your Real Emacs Way. You'll be happy and so will everyone else. The last
thing d-s-mode needs is you sorting it out and fixing its "problems". Don't even
think about it.

D-s-mode doesn't need to be the default for Emacs. It just needs to exist.
Enough users will discover it. It ain't broke, so please don't try to fix it.
Let those who do use it and like it worry about whether it needs improvement.
Fixer friends like you it doesn't need.

If you want to start a new mode that does something like d-s-mode but solves all
of your problems, fine; go for it. But please leave d-s-mode itself alone. Then
people can vote on your new mode as the default. You might even get my vote. ;-)

> The Emacs way of getting a feature activated by default is 
> not throwing a tantrum until everybody gives in, but making
> the feature work smoothly with other use cases and workflows.
> 
> That is the way to overcome resistance.  Throwing tantrums, 
> in contrast, distracts from the work, thoughts, and discussions
> that are needed to properly make a feature fit in as a part
> with the rest of Emacs.

No one is throwing a tantrum, except possibly you, David.

I did not offer the proposal to make d-s-mode the default. Juri did. I simply
voted yes. Only later did I reply to some arguments I found faulty and support
the proposal with some positive reasons.

From the outset, I warned that the discussion might go round and round like
this, precisely because I saw it happen before. I predicted we'd hear the same
old stuff about keyboard vs mouse and Real Emacs and Real Emacs Users vs the
Inferior Others.

And sure enough, your very first post to the thread confirmed that. (1) You
claimed that "it inteferes with Emacs-typical editing" (meaning how you use
Emacs). And (2) you painted Juri's question (which was simply whether new-user
problems discovering d-s-mode might be reason enough to enable d-s-mode by
default) as being really "How can we make beginners shut up" and not "How can we
make beginners more productive with Emacs".

I can't speak for Juri, but from my view: (1) D-s-mode _is_ Emacs-typical
editing. There are many kinds of Emacs-typical editing. And (2) the idea behind
making d-s-mode the default was not to make beginners shut up but precisely to
help beginners (and others) be more productive with Emacs.

You said the same kinds of things about the proposal to make t-m-mode the
default, BTW: it wasn't Emacs-typical editing; it just dumbed things down to
make beginners shut up. You were wrong then and you're wrong about that now.
That kind of attitude expresses arrogance toward people who use Emacs
differently from you.

> Your point is abundantly clear: "I want delete-selection-mode enabled
> and nothing else changed".

No, actually, my point is that I agree with those who think that d-s-mode would
be a better default behavior. That's all. Just a vote.

To try to convince those inclined to vote no, I countered some of their
arguments and provided some arguments supporting the proposal. But I can live
without the default change. The change is not for _me_: I already use d-s-mode.

If d-s-mode is not to be the default, then yes, I'm in favor of leaving things
the way they are: t-m-mode enabled by default.

I'm not in favor of your proposal to disable t-m-mode (again). And I'm not in
favor of coming up with a compromise d-s-mode hybrid or other new mix (as was
done for mouse selection) intended to mollify those who hate d-s-mode. And I'm
not in favor of modifying d-s-mode itself.

And yes, I will present arguments against any such proposals, if I have any.

> you might want to stay off this discussion for a week or so and see
> whether people make progress with plans about moving Emacs towards a
> state where delete-selection-mode as a default is less of a 
> bad idea as it is now.  It is obvious that you are not wanting to 
> participate in any such discussion in a constructive way.

I will participate in any discussion I like. 

Juri's proposal was to enable d-s-mode by default. I voted yes. If the decision
is no, that's fine.

If there is another proposal, for some hybrid as the default, I'll likely vote
no, but I'll judge the specifics on their merits. And I'll give my arguments in
support or against, whether you want to hear them or not.

You say you want new users to find out about the real Emacs Way. Well so do I. I
would like them to learn about the real d-s-mode (whether or not it becomes the
default), and not some half-baked compromise intended to make things palatable
to people who aren't really interested in what d-s-mode has to offer anyway.

No one is forcing d-s-mode as the default. If you can't accept that proposal,
then please just leave it alone.

Re: delete-selection-mode

[David Kastrup]

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

>> Then perhaps you should leave the discussion until those that remember
>> life without delete-selection-mode have sorted out the problems with
>> making it the default.
>
> No, please, don't make it the default. Don't go near it. Just leave it
> alone. Go back to your Real Emacs Way. You'll be happy and so will
> everyone else. The last thing d-s-mode needs is you sorting it out and
> fixing its "problems". Don't even think about it.

[...]

> And yes, I will present arguments against any such proposals, if I
> have any.

If you restrict your output to those cases, it would significantly
improve the signal to noise ratio of the solution finding process.

-- 
David Kastrup

Re: delete-selection-mode

[Juri Linkov]

> I can't speak for Juri, but from my view: (1) D-s-mode _is_
> Emacs-typical editing. There are many kinds of Emacs-typical
> editing. And (2) the idea behind making d-s-mode the default was not
> to make beginners shut up but precisely to help beginners (and others)
> be more productive with Emacs.

Yes, that's what I meant - to enable d-s-m by default not only because
this is what beginners expect but also because it helps them be more
productive with Emacs.  The evidence is the fact that many experienced
Emacs users already prefer d-s-m and have no problems with it.

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

Re: delete-selection-mode (was: Put scroll-bar on right by defaulton UNIX.)

[Alan Mackenzie]

'Evening, Drew,

On Thu, Mar 18, 2010 at 10:15:11AM -0700, Drew Adams wrote:

> > OK.  The penalty for that convenience is having your region explode
> > and disappear when you accidentally type a self-insert character (or
> > arrow key).  This might happen if you hit the x before the M in M-x,
> > or something like that.  Or, you might regionify a defun with C-M-h
> > for some reason and accidentally lose it. 

> The risk you describe exists in theory, and I suppose it occurs
> occasionally in practice. But honestly, my impression is that you
> simply have not used d-s-mode much or this would not be a problem in
> practice.

You are wrong.  I have used lots of proprietary products with d-s-m.
What is worst about it, for me, is not the "explosion" itself when it
happens, but the continual anxiety that it will.  It's like walking
through a minefield - even if you don't explode a mine, you simply cannot
relax and feel easy.

You're being very dismissive of my experience simply because you're
different and don't share it.  I am by no means unique - there will
certainly be lots of other people who suffer this feature likewise;
there're another one or two on this mailing list.  The degree of
suffering d-s-m inflicts on us far outweighs the slight increase in
convenience for you.

> 99.999% (no, no proof; just a guess) of computer users out there use
> this "risky" behavior everyday, all day long, without exploding (and
> without Emac's powerful undo as a remedy).

We do not know, since these users are forced into it without having a
choice.

> I submit that you see it as a problem simply because you are not used
> to it. If you don't treat the active region as, well, active, then yes,
> you'll probably step on your own toes a few times.

I use Emacs because it is (or rather, was) a stateless editor, as
contrasted to vi.  d-s-m adds in yet one more frivolous state-dependent
behaviour.  Even with transient-mark-mode, you can still (currently)
depend on `self-insert-command' to just work.  With d-s-m you can't.

However, with simple transient-mark-mode, the problem doesn't exist.
Even a naive newbie would very quickly learn to hit the <delete> key if
d-s-m weren't enabled.  Heavens, they do it already.  Do they complain
about it?

> > It's "obviously" useful to be able to type extra text into an already
> > "existing" region.  The region is used for many things other than
> > just being deleted.

> Not a problem. It is only when the region is *active* that typing
> replaces it.  Emacs gives you the best of both worlds: the region can
> be active or inactive.

Stop playing with my words, please.

> > we should never make something default in Emacs if it's likely to
> > provoke the angry reaction "How do I disable this *!£$ing thing?".
> > delete-select-mode falls into this latter category.  So does
> > transient-mark-mode.

> So we should remove t-m-mode as the default?

I would say yes, but that argument was settled some while ago.  It
wouldn't be a good idea to reopen it.

> We all agree that whatever the default behavior is we should do our
> best to let users know how to change the defaults.

Yes.

> > Is there any evidence that delete-select-mode is instrinsically a good
> > thing, disregarding the fact that it has become common?

> Which do you do more often: (a) replace the text in the region or (b) set mark,
> move somewhere else, and insert text?

How about addressing the question as put?  Is there any evidence
whatsoever for the intrinsic goodness of d-s-m?

My personal answer to your question is (c) something else.  I NEVER
"replace the text in the region".  I frequently do (b), though I don't
think of it in those terms.

> With d-s-mode, the former is simple and the latter requires that you
> hit C-g (to deactivate the region). Without d-s-mode, the latter is
> simple and the former requires that you hit C-w (or DEL/delete-region).

Yes.  Hitting C-g repeatedly is a horrible experience - it makes a noise.
Hitting C-w is simple, hitting <del> is obvious even to newbies, and
doesn't make any noise.

> You could say "six of one; half a dozen of the other - a toss-up". If
> you think that, then we're back to the argument about fit (by default)
> with the outside world. And that argument is not negligible.

> > One reason people might have come to Emacs is to escape the (to them)
> > deity-awful key sequences they've been forced to use up to now.

> That's an amazing statement, Alan. I've never heard anyone claim that
> people come to Emacs because the key sequences they use elsewhere are
> too difficult.

Not "too difficult" but "deity-awful".  You do understand that
distinction, I hope?

> It's usually the opposite we hear about Emacs: "What's with all the
> crazy C-M-S- contortions?"

All the "crazy" key sequences are part of Emacs's essence.  Without them,
it wouldn't be Emacs.  They're what make Emacs easy and efficient to use
(not to be confused with easy to learn).

> You've been inside Emacs so long that it's second nature to you. Take a
> look outside the window, and imagine that you're out there looking in
> at Emacs. This is about setting the default value. In particular, it's
> about picking a default that is helpful to new users but is also useful
> in general.

I remember learning Emacs well.  It was difficult and frustrating.
Slight variations on Emacs's default would not have changed that one
iota.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: delete-selection-mode (was: Put scroll-bar on right by defaultonUNIX.)

[Drew Adams]

> I am by no means unique - there will
> certainly be lots of other people who suffer this feature likewise;
> there're another one or two on this mailing list.  The degree of
> suffering d-s-m inflicts on us far outweighs the slight increase in
> convenience for you.

Just say no. Just turn it off.

The discussion is about the _default_ behavior. Are you suggesting (a) that
*most* new users already suffer from this problem outside Emacs and (b) they
therefore need the Emacs default to be different from the outside behavior?

> > 99.999% (no, no proof; just a guess) of computer users out there use
> > this "risky" behavior everyday, all day long, without exploding (and
> > without Emac's powerful undo as a remedy).
> 
> We do not know, since these users are forced into it without having a
> choice.

Should we assume that they are exploding all over the place? Don't you think
this would be common knowledge by now?

> > I submit that you see it as a problem simply because you 
> > are not used to it. If you don't treat the active region as,
> > well, active, then yes, you'll probably step on your own toes
> > a few times.
> 
> I use Emacs because it is (or rather, was) a stateless editor,

Huh? I don't think so.

> as contrasted to vi.

Yes, OK, it is less modal than vi. More precisely, it has modes all over the
place, instead of just 2 (or is it 3) modes. But Emacs is far from stateless.

> d-s-m adds in yet one more frivolous state-dependent behaviour.

Why frivolous?

From the moment that you have t-m-mode, you have active regions, hence
state-dependent behavior. In fact, from the moment that you have a mark (!) you
have state-dependent behavior. And long before that even...

> Even with transient-mark-mode, you can still (currently) depend
> on `self-insert-command' to just work. With d-s-m you can't.

Sure you can. `self-insert-command' works fine with d-s-mode. You can depend on
things acting the way they are documented, in a consistent way. That way is
*different* from when d-s-mode is not enabled, but it is no less dependable.

> However, with simple transient-mark-mode, the problem doesn't exist.
> Even a naive newbie would very quickly learn to hit the <delete> key if
> d-s-m weren't enabled.

But a newbie wouldn't easily find out how to get the type-to-replace behavior
that s?he knows and loves - or even find out that it is possible. ;-)

That's part of the problem we're trying to solve. No one has said that newbies
can't figure out how to delete selected text with just t-m-mode. The point is
that they don't know that they do not *have* to delete it first, to replace it.
They don't know that they can easily get the behavior they expect and are used
to.

> > > It's "obviously" useful to be able to type extra text 
> > > into an already "existing" region.  The region is used
> > > for many things other than just being deleted.
> 
> > Not a problem. It is only when the region is *active* that typing
> > replaces it.  Emacs gives you the best of both worlds: the 
> > region can be active or inactive.
> 
> Stop playing with my words, please.

I don't think I am. Your point was that in Emacs we use the region for lots of
things besides replacing its text, and in particular we sometimes want to add
additional text to the region text. Right?

I agree. My reply points out that those uses of the region are still available
with d-s-mode - you need only deactivate the region. You're not losing those
other region features by using d-s-mode. That was my point.

d-s-mode gives you a replace feature when the region is active, but it doesn't
prevent you from having an inactive region and using it in other ways.

> > > we should never make something default in Emacs if it's likely to
> > > provoke the angry reaction "How do I disable this *!£$ing thing?".
> > > delete-select-mode falls into this latter category.  So does
> > > transient-mark-mode.
> 
> > So we should remove t-m-mode as the default?
> 
> I would say yes, but that argument was settled some while ago.  It
> wouldn't be a good idea to reopen it.

Agreed; we should not reopen it. (And it was a good change.)

> > > Is there any evidence that delete-select-mode is 
> > > instrinsically a good thing, disregarding the fact that
> > > it has become common?
> 
> > Which do you do more often: (a) replace the text in the 
> > region or (b) set mark, move somewhere else, and insert text?
> 
> How about addressing the question as put?  Is there any evidence
> whatsoever for the intrinsic goodness of d-s-m?

I did answer it more directly in other posts (including text you cited in your
reply). But I'll repeat some of it:

Using d-s-mode and not using it are about the same in terms of
advantage/disadvantage, other things being equal: you need to hit an extra key
in each to be able to get the behavior that the other gives you directly. With
d-s-mode, the extra key is C-g (or C-u to prevent); without d-s-mode, the extra
key is C-w (or `delete-region'/DEL). From this point of view, it's a toss-up.

But other things are not equal, so it's not a toss-up:

1. The answer to my question above is #a, I think. People, including Emacs
users, more often replace the region text than they set mark, move, and insert
text.

2. Outside Emacs (Yes, Virginia, there is a world outside Emacs),
type-to-replace is the rule for selections. Using the same rule as the default
in Emacs helps both old users (only one behavior) and, especially, new users.

> My personal answer to your question is (c) something else.  I NEVER
> "replace the text in the region".  I frequently do (b), though I don't
> think of it in those terms.

I see. In that case, you would definitely want to disable d-s-mode, I expect.

But do you think that is typical of most Emacs users? Do you think it is typical
of non-Emacs users?

FWIW, I frequently do #a (as should be obvious by now). One particular use case
is yanking the secondary selection to replace the region. (Yes, I bind a
secondary-sel yank to a keyboard key. Dunno why vanilla Emacs relegates it to
the mouse.)

> > With d-s-mode, the former is simple and the latter requires that you
> > hit C-g (to deactivate the region). Without d-s-mode, the latter is
> > simple and the former requires that you hit C-w (or DEL/delete-region).
> 
> Yes.  Hitting C-g repeatedly is a horrible experience - it 
> makes a noise.

I don't hear a thing. But I've silenced `ding'.

> Hitting C-w is simple, hitting <del> is obvious even to newbies, and
> doesn't make any noise.

If the bell is the problem, we could perhaps silence it for this use.

And there's nothing magical about having chosen C-g as the key to deactivate. I
suppose another key could have been chosen.

C-g was presumably picked by someone who either doesn't use it (!) or doesn't
care about the bell (or doesn't hear it). I didn't choose it.

> > > One reason people might have come to Emacs is to escape 
> > > the (to them) deity-awful key sequences they've been forced
> > > to use up to now.
> 
> > That's an amazing statement, Alan. I've never heard anyone 
> > claim that people come to Emacs because the key sequences
> > they use elsewhere are too difficult.
> 
> Not "too difficult" but "deity-awful".  You do understand that
> distinction, I hope?

No. What did you mean exactly? What is the salient characteristic of the keys
outside Emacs that you think people complain about? "God-awful" might mean
something concrete to you here, but it doesn't to me. Just which keys do you
think they complain about? What God-awful keys outside Emacs make them come
running inside?

> > You've been inside Emacs so long that it's second nature to 
> > you. Take a look outside the window, and imagine that you're
> > out there looking in at Emacs. This is about setting the
> > default value. In particular, it's about picking a default
> > that is helpful to new users but is also useful in general.
> 
> I remember learning Emacs well.  It was difficult and frustrating.
> Slight variations on Emacs's default would not have changed that one
> iota.

Did you happen to learn Emacs after using computers all day long for years,
selecting and typing text to replace the selection? That's the case for folks
nowadays. This is not 1985 or even 1995.

IIRC, you don't use a mouse (much, if at all), correct? And I'd guess you didn't
use a mouse before you came to Emacs either. That is so different from
99.999999% of the world nowadays that it makes you miss the point, I fear, about
_their_ learning Emacs.

It's not about you, Alan. And it's not about me. I turned on d-s-mode decades
ago. I don't want the default change for myself. I want it for newbies, in
particular.

I also think that some other oldbies will find it useful if they give it a
chance. I'm struck by the number of oldbies, including RMS, who've made it clear
in this very thread that they are not really familiar with d-s-mode. To any who
are open, I say, "Try it; you might like it."

Re: delete-selection-mode (was: Put scroll-bar on right by defaultonUNIX.)

[Alan Mackenzie]

Hi, Drew

On Thu, Mar 18, 2010 at 02:54:29PM -0700, Drew Adams wrote:
> > I am by no means unique - there will
> > certainly be lots of other people who suffer this feature likewise;
> > there're another one or two on this mailing list.  The degree of
> > suffering d-s-m inflicts on us far outweighs the slight increase in
> > convenience for you.

> Just say no. Just turn it off.

We're talking about the DEFAULT version here.  Would you now please
address the point.  That the change you want will impose a lot of pain
on lots of people, albeit that they may be in a minority.

> The discussion is about the _default_ behavior. Are you suggesting (a)
> that *most* new users already suffer from this problem outside Emacs
> and (b) they therefore need the Emacs default to be different from the
> outside behavior?

I'm suggesting that (a) a LOT of people suffer from this; and (b) they
would welcome Emacs being different.  (Emacs IS different in many ways.)

> > > 99.999% (no, no proof; just a guess) of computer users out there use
> > > this "risky" behavior everyday, all day long, without exploding (and
> > > without Emac's powerful undo as a remedy).

I've just spoken to my sister, an "ordinary" computer user.  She says
she normally uses the <delete> key after marking text before typing
further.  She also gets annoyed "every now and then" when marked text
gets accidentally deleted by typing, though "it's not too bad" if
there's an undo key sequence.

Unwanted deletion of text happens for me, it happens for David, it
happens for Miles.  Why do you not see this as a serious problem?

> > I use Emacs because it is (or rather, was) a stateless editor,

> Yes, OK, it is less modal than vi. More precisely, it has modes all
> over the place, instead of just 2 (or is it 3) modes. But Emacs is far
> from stateless.

STATES, not Modes.  Emacs WAS a stateless editor.  If you're in Foo
Mode, any key sequence did the same action always (Modulo deliberate
commands like C-s).  With t-m-m that no longer holds.  Should d-s-m be
made default it will be even less so.  I hold that this diminution of
statelessness is a Bad Thing.

> > d-s-m adds in yet one more frivolous state-dependent behaviour.

> Why frivolous?

Because inessential.  You and a few others, so as to save a single key
easy press (<del> or C-w) want to heap massive inconvenience on others.
In your personal way of working, you don't suffer from unwanted
deletion.  Others do.  What's so difficult about explicitly deleting
text in the region as opposed to it happening as a side effect?

> > Even with transient-mark-mode, you can still (currently) depend
> > on `self-insert-command' to just work. With d-s-m you can't.

> Sure you can. `self-insert-command' works fine with d-s-mode. You can
> depend on things acting the way they are documented, in a consistent
> way. That way is *different* from when d-s-mode is not enabled, but it
> is no less dependable.
 
`self-insert-command' will have state dependent behaviour.  It won't
JUST work anymore - it will have side effects.


> d-s-mode gives you a replace feature when the region is active, but it
> doesn't prevent you from having an inactive region and using it in
> other ways.

d-s-m makes an active region a fragile region.  It is this fragility
which causes all the pain.  Please address this issue.


> > How about addressing the question as put?  Is there any evidence
> > whatsoever for the intrinsic goodness of d-s-m?

> Using d-s-mode and not using it are about the same in terms of
> advantage/disadvantage, other things being equal: you need to hit an
> extra key in each to be able to get the behavior that the other gives
> you directly. With d-s-mode, the extra key is C-g (or C-u to prevent);
> without d-s-mode, the extra key is C-w (or `delete-region'/DEL). From
> this point of view, it's a toss-up.

That is mere hand waving, not evidence.  By evidence, I meant some sort
of study or research.  I take it you know of none.  I certainly don't.

> 2. Outside Emacs (Yes, Virginia, there is a world outside Emacs),
> type-to-replace is the rule for selections. Using the same rule as the
> default in Emacs helps both old users (only one behavior) and,
> especially, new users.

Who says that people outside Emacs use this rule much?  My sister
doesn't.


> > Hitting C-w is simple, hitting <del> is obvious even to newbies, and
> > doesn't make any noise.

> If the bell is the problem, we could perhaps silence it for this use.

What, more state?  No thanks!  Either silence it or not.  I'd say
silence it altogether.


> > > > One reason people might have come to Emacs is to escape 
> > > > the (to them) deity-awful key sequences they've been forced
> > > > to use up to now.

> > > That's an amazing statement, Alan. I've never heard anyone 
> > > claim that people come to Emacs because the key sequences
> > > they use elsewhere are too difficult.

> > Not "too difficult" but "deity-awful".  You do understand that
> > distinction, I hope?

> No. What did you mean exactly?

One which is "too difficult" is one which is difficult to use.
Ctrl-Alt-Delete would be difficult for a one-handed person.  Holding
down <PageUp> to go to BOB would be ghod-awful, as would C-x M-q C-w.
For kill-word, I'd call C-S-<right> <delete> ghod-awful, certainly when
compared with M-d.

> What is the salient characteristic of the keys outside Emacs that you
> think people complain about? "God-awful" might mean something concrete
> to you here, but it doesn't to me. Just which keys do you think they
> complain about? What God-awful keys outside Emacs make them come
> running inside?

C-f (for find) which drops a dialogue box over half of your text, for
example.  C-S-<right> <delete> for kill word.

> Did you happen to learn Emacs after using computers all day long for
> years, selecting and typing text to replace the selection? That's the
> case for folks nowadays. This is not 1985 or even 1995.

I've been using computers all day long for ~30 years; Emacs for ~12
years.  I've been assaulted by "typing replaces selection" for perhaps
the last 10 years or so.

> IIRC, you don't use a mouse (much, if at all), correct? And I'd guess
> you didn't use a mouse before you came to Emacs either. That is so
> different from 99.999999% of the world nowadays that it makes you miss
> the point, I fear, about _their_ learning Emacs.

Not at all - Emacs can wean them off their dependence on the mouse.

> It's not about you, Alan. And it's not about me. I turned on d-s-mode
> decades ago. I don't want the default change for myself. I want it for
> newbies, in particular.

It is about you, Drew.  I don't think you're looking outside your own
work habits enough to see that one size doesn't fit all.  d-s-m causes
distress; to David, to Miles, to me, to my sister, and undoubtedly to
countless others out there.

> I also think that some other oldbies will find it useful if they give
> it a chance. I'm struck by the number of oldbies, including RMS,
> who've made it clear in this very thread that they are not really
> familiar with d-s-mode. To any who are open, I say, "Try it; you might
> like it."

There's not too many familiar with BDSM either (and I'm not talking
about the licence here ;-).  Is that a good reason to try it?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> There's not too many familiar with BDSM either (and I'm not talking
> about the licence here ;-).  Is that a good reason to try it?

I've heard that Berkeley is most reputed for its two products LSD and
BSD, and that this does not seem like mere coincidence.

-- 
David Kastrup

RE: delete-selection-mode (was: Put scroll-bar on right bydefaultonUNIX.)

[Drew Adams]

Hi Alan,

> > Just say no. Just turn it off.
> 
> We're talking about the DEFAULT version here.  Would you now please
> address the point.  That the change you want will impose a lot of pain
> on lots of people, albeit that they may be in a minority.

If you honestly believe that enabling d-s-mode by default would inflict pain on
lots of people, then don't vote to enable it. I would think you're wrong about
that, but maybe I'm wrong.

That's the point of a discussion and, hopefully, a user poll.

BTW, didn't you say much the same thing about the proposal to enable t-m-mode a
while back? If so, do you think that lots of people have in fact suffered lots
of pain as a result of that decision?

I'm not _aiming_ to inflict pain on anyone (unlike what you claim further down).
I'm content to leave the default the way it is and use d-s-mode myself. I agree
with Juri's proposal because I honestly think it would help users in general
(old and new).

But hey, what do I know? I'm just one data point. I don't see the flood of pain
you foresee. I can imagine some temporary discomfort for people who are not used
to it, but to them I would say just turn it off.

Which is what I meant above. I understand you to be one of those people - I'm
guessing you'd be better off not bothering with d-s-mode. I still think that
most people would benefit from the change. What can I say? That's my opinion.

You say that you are a sizable minority. OK, I don't doubt that you're not
alone. I'd still say that in that case either (a) we shouldn't change the
default to d-s-mode or (b) such a sizable minority would probably be better
disabling d-s-mode - just saying no.

> > The discussion is about the _default_ behavior. Are you 
> > suggesting (a) that *most* new users already suffer from
> > this problem outside Emacs and (b) they therefore need
> > the Emacs default to be different from the outside behavior?
> 
> I'm suggesting that (a) a LOT of people suffer from this;

OK, I've got it. A LOT of people, but a minority. Fair enough.

> and (b) they would welcome Emacs being different.
> (Emacs IS different in many ways.)

Right. So lots of people who don't use Emacs are suffering, and they could stop
suffering by using Emacs without d-s-mode. Sounds good to me.

But you said they were a minority, so maybe the default shouldn't cater to them?
As long as Emacs offers a way to disable d-s-mode and thus relieve their
suffering? Which it does.

> > > > 99.999% (no, no proof; just a guess) of computer users 
> > > > out there use this "risky" behavior everyday, all day
> > > > long, without exploding (and without Emac's powerful
> > > > undo as a remedy).
> 
> I've just spoken to my sister, an "ordinary" computer user.  She says
> she normally uses the <delete> key after marking text before typing
> further.  She also gets annoyed "every now and then" when marked text
> gets accidentally deleted by typing, though "it's not too bad" if
> there's an undo key sequence.
> 
> Unwanted deletion of text happens for me, it happens for David, it
> happens for Miles.  Why do you not see this as a serious problem?

I don't see it as a serious problem because (a) I don't think it's that frequent
(no, no proof) and (b) we have undo.

But I don't doubt that it could be serious on an individual basis. And I think
that if others agree that it is serious enough, then d-s-mode should not be the
default. If people think it is not all that serious, and it would be enough to
just advertise how to disable d-s-mode, then it could be made the default.

My point about the outside world is that most people do manage to use this
feature all day long, everyday. You say that a sizable minority is suffering. In
that case, let's not make d-s-mode the default, and let's advertise Emacs better
to that minority, letting people know that Emacs has the remedy for their
suffering. No, I'm not kidding.

> > > I use Emacs because it is (or rather, was) a stateless editor,
> 
> > Yes, OK, it is less modal than vi. More precisely, it has modes all
> > over the place, instead of just 2 (or is it 3) modes. But 
> > Emacs is far from stateless.
> 
> STATES, not Modes.  Emacs WAS a stateless editor.  If you're in Foo
> Mode, any key sequence did the same action always (Modulo deliberate
> commands like C-s). 

But key sequences are mode-specific. They are modal. When you change the mode
the behavior of the key can change. As long as you are in the mode, its behavior
stays the same (typically).

Emacs doesn't seem as modal as a dialog box that won't let you do anything but
reply to a question. But that just means that Emacs lets you change modes more
easily (e.g. switch buffers).

Anyway, this is all pretty much off-topic, I think.

> With t-m-m that no longer holds.  Should d-s-m be
> made default it will be even less so.  I hold that this diminution of
> statelessness is a Bad Thing.

Sorry, I'm not convinced. But maybe (maybe?) it's not such an important point.
If you think it is, then feel free to insist.

> > > d-s-m adds in yet one more frivolous state-dependent behaviour.
> 
> > Why frivolous?
> 
> Because inessential.  You and a few others, so as to save a single key
> easy press (<del> or C-w) want to heap massive inconvenience 
> on others.

No, Alan. You are heaping massive unfairness on me. ;-) Believe me, I do not
want to heap massive inconvenience on others. Please don't doubt my motives.

And that is not the reason for the proposal. I've already made it clear that the
single-key saving there is compensated for by the single-key cost to deactivate
the region when necessary. I was clear that from that standpoint it is
essentially a toss-up.

> In your personal way of working, you don't suffer from unwanted
> deletion.  Others do.  What's so difficult about explicitly deleting
> text in the region as opposed to it happening as a side effect?

Hey, no problem. I'm fine with keeping the default the way it is. Especially if
it's a giant problem for lots of people, inflicting massive inconvenience and
pain. No question about it, in that case.

There was a proposal. I voted yes. I gave reasons why I think it's a good
proposal. But hey, if people will be dropping like flies under the strain and
pain, then I certainly don't want to heard promoting such a thing.

> `self-insert-command' will have state dependent behaviour.  It won't
> JUST work anymore - it will have side effects.

I don't follow you. But again, maybe it's not so important that I see this
point.
 
> > d-s-mode gives you a replace feature when the region is 
> > active, but it doesn't prevent you from having an inactive
> > region and using it in other ways.
> 
> d-s-m makes an active region a fragile region.  It is this fragility
> which causes all the pain.  Please address this issue.

How do you want me to address it? I guess I don't have an answer for you. I
certainly don't have a remedy for the amount of pain that you foresee. My only
remedy would be to advise people who experience such pain to not use d-s-mode.
It's clear that I wouldn't use it if it made me suffer so.

> > > How about addressing the question as put?  Is there any evidence
> > > whatsoever for the intrinsic goodness of d-s-m?
> 
> > Using d-s-mode and not using it are about the same in terms of
> > advantage/disadvantage, other things being equal: you need to hit
> > an extra key in each to be able to get the behavior that the 
> > other gives you directly. With d-s-mode, the extra key is C-g
> > (or C-u to prevent); without d-s-mode, the extra key is C-w (or 
> > `delete-region'/DEL). From this point of view, it's a toss-up.
> 
> That is mere hand waving, not evidence.

Uh, that wasn't supposed to be "evidence for the intrinsice goodness of d-s-m".
So far, that was supposed to be saying that it's a toss up.

> By evidence, I meant some sort of study or research. I take it
> you know of none.  I certainly don't.

You're right. I know of none. I'm really not all that interested in this, to be
truthful. Based only on (a) my own experience and (b) what I see of the
experience of people around me (non-Emacs users, most), I thought it was a good
idea.

I still think it's a good idea for my own use. And I still think it would help
most non-Emacs users start to use Emacs. And I still think it would help most
veteran Emcs users as well.

But it sounds like it's a horrible idea for that sizable minority that you
identified. Pestilence we certainly don't need.

So even if it would be a good default behavior for most people, given that the
pain for that sizable minority is so severe, I agree that d-s-mode should not be
the default.

We should not be in the business of "heaping massive inconvenience" and pain on
lots of people, no matter how small a minority they are.

> > 2. Outside Emacs (Yes, Virginia, there is a world outside Emacs),
> > type-to-replace is the rule for selections. Using the same 
> > rule as the default in Emacs helps both old users (only one
> > behavior) and, especially, new users.
> 
> Who says that people outside Emacs use this rule much?  My sister
> doesn't.

OK, she doesn't. I see people do it all the time. But hey, my anecdotal sample
is as insignificant as your sister-sample. So you're right: who knows? Someone
could look for some research, but not I - I'm just not that interested.

I honestly thought that my observation would find a general echo, that most of
us see lots of people doing that. But if that's in doubt, then don't worry about
it. I'm certainly not going to insist I'm right about that.
 
> > > Hitting C-w is simple, hitting <del> is obvious even to 
> > > newbies, and doesn't make any noise.
> 
> > If the bell is the problem, we could perhaps silence it for 
> > this use.
> 
> What, more state?  No thanks!  Either silence it or not.  I'd say
> silence it altogether.

Hey, maybe we can agree about something. I turned it off long ago.

But no, I'm not going to stand up and propose that we turn off the bell. You can
do that.

And then we'll get the same sort of round-and-round about that fascinating
topic. Zippy in front of the dryer. Round and round.

> > > > > One reason people might have come to Emacs is to escape 
> > > > > the (to them) deity-awful key sequences they've been forced
> > > > > to use up to now.
> 
> > > > That's an amazing statement, Alan. I've never heard anyone 
> > > > claim that people come to Emacs because the key sequences
> > > > they use elsewhere are too difficult.
> 
> > > Not "too difficult" but "deity-awful".  You do understand that
> > > distinction, I hope?
> 
> > No. What did you mean exactly?
> 
> One which is "too difficult" is one which is difficult to use.
> Ctrl-Alt-Delete would be difficult for a one-handed person.  Holding
> down <PageUp> to go to BOB would be ghod-awful, as would C-x M-q C-w.
> For kill-word, I'd call C-S-<right> <delete> ghod-awful, 
> certainly when compared with M-d.

OK. I guess.

> > What is the salient characteristic of the keys outside 
> > Emacs that you think people complain about? "God-awful"
> > might mean something concrete to you here, but it doesn't
> > to me. Just which keys do you think they
> > complain about? What God-awful keys outside Emacs make them come
> > running inside?
> 
> C-f (for find) which drops a dialogue box over half of your text, for
> example.

It's the box that's god-awful, not C-f, no? C-f for search is no more god-awful
than C-s. It's how the search dialog continues after the C-f/C-s that makes the
difference.

> C-S-<right> <delete> for kill word.

Can't disagree with you there. Never even knew such a sequence existed.

And I guess I see what you're saying now.

But I'm not convinced that users outside Emacs come to Emacs because of such
god-awful keys (which I agree are god-awful). Most users outside of Emacs (and
vi etc.) don't even use keys for things like deleting words. They just select
with the mouse and hit delete. Or they scroll all the way to BOB.

I think. No, no proof - someone else can look it up.

> > Did you happen to learn Emacs after using computers all day long for
> > years, selecting and typing text to replace the selection? 
> > That's the case for folks nowadays. This is not 1985 or even 1995.
> 
> I've been using computers all day long for ~30 years; Emacs for ~12
> years.  I've been assaulted by "typing replaces selection" for perhaps
> the last 10 years or so.

Right. So you didn't first get in the habit of select-and-type-to-replace and
then start to learn Emacs. Same here. But that is the case for most computer
users (who come to Emacs) nowadays. That was my point.

> > IIRC, you don't use a mouse (much, if at all), correct? And 
> > I'd guess you didn't use a mouse before you came to Emacs
> > either. That is so different from 99.999999% of the world
> > nowadays that it makes you miss the point, I fear, about
> > _their_ learning Emacs.
> 
> Not at all - Emacs can wean them off their dependence on the mouse.

Yes, but the point is that they come to Emacs with a set of habits that are
different from the habits you had when you learned Emacs. Don't underestimate
that difference. But yes, of course they can be helped to learn better ways.

> > It's not about you, Alan. And it's not about me. I turned 
> > on d-s-mode decades ago. I don't want the default change
> > for myself. I want it for newbies, in particular.
> 
> It is about you, Drew.  I don't think you're looking outside
> your own work habits enough to see that one size doesn't fit
> all.

No Alan. It is not about me. I'm looking outside my work habits at the habits of
the teeming masses of gray. It's not because I use d-s-mode that I think it's a
great idea for Emacs. I use all kinds of things in Emacs that I wouldn't vote
for as the default behavior, believe me.

It's about THEM and THEIR HABITS. What they're used to.

But as I said, I also wouldn't have voted for it if I didn't think d-s-mode is
useful for more than just newbies. It's not about catering to their way of doing
things just for the sake of it.

I wouldn't vote for CUA-mode as a default, for example. I believe it is inferior
to the regular Emacs copy, cut, paste, etc. bindings.

I don't believe that d-s-mode is inferior - on the contrary - and that's why I
voted for it. But I do hear you loud and clear about the pain for some people.
Based on that, I'd say it should not become the default.

> d-s-m causes distress; to David, to Miles, to me, to my
> sister, and undoubtedly to countless others out there.

I heard you.

Don't use it. And don't make it the default in that case. I mean it. And please
don't tell your sister that Drew "wants to heap massive inconvenience on
others."

> > I also think that some other oldbies will find it useful if 
> > they give it a chance. I'm struck by the number of oldbies,
> > including RMS, who've made it clear in this very thread
> > that they are not really familiar with d-s-mode. To any who
> > are open, I say, "Try it; you might like it."
> 
> There's not too many familiar with BDSM either (and I'm not talking
> about the licence here ;-).  Is that a good reason to try it?

I did not say that they should try it _because_ they are not familiar with it.
That's your logic, not mine.

And unlike the case of d-s-mode, I cannot say whether BDSM is a good thing or
that people should try it. You can make that proposal. I'll abstain from voting.

Re: delete-selection-mode (was: Put scroll-bar on right by defaultonUNIX.)

[Lennart Borgman]

Hi Alan,


On Fri, Mar 19, 2010 at 10:23 AM, Alan Mackenzie <acm@muc.de> wrote:
>
> We're talking about the DEFAULT version here.

Yes.

> I've just spoken to my sister, an "ordinary" computer user.  She says
> she normally uses the <delete> key after marking text before typing
> further.  She also gets annoyed "every now and then" when marked text
> gets accidentally deleted by typing, though "it's not too bad" if
> there's an undo key sequence.

Yes, that is normal today since that is how it works during most of
the editing people do today.

You have to be in a special editing environment for it not to work and
most people are never in such environments today. So for most people
there are no exceptions to this.

I believe you have to be a "low level" programmer to ever be in those
special environments. Most people are not programmers. And most
programmers are not low level programmers. And Emacs are used also by
people that are not programmers.

> You and a few others, so as to save a single key
> easy press (<del> or C-w) want to heap massive inconvenience on others.

Not a few. All non-Emacs users (and they are a majority) are used to
that typing a character when text is selected will replace a visible
region/selection.

Whatever the arguments are I believe we will/must move in a direction
that makes it easier for newcomers. They are used to beeing able to
immediately using a new application. They meet new applications on the
web all the time. If some application on the web does not work
immediately they frown upon it as stupid.

> `self-insert-command' will have state dependent behaviour.  It won't
> JUST work anymore - it will have side effects.

Yes. And that is probably what most experienced newcomers expect
because it works that way - today.

> d-s-m makes an active region a fragile region.  It is this fragility
> which causes all the pain.  Please address this issue.

Don't you think the way to go is to make suggestions that can both
move us towards the common defaults and do what you think is best for
old-timers?

> That is mere hand waving, not evidence.

Don't you think we need creativity, not evidence here?

> Who says that people outside Emacs use this rule much?  My sister
> doesn't.

Experienced user might do it more.

> What, more state?  No thanks!  Either silence it or not.  I'd say
> silence it altogether.

If we do not use defaults that newcomers are used to, will we not
impose a new stat on them instead?

Re: delete-selection-mode

[David Kastrup]

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

> On Fri, Mar 19, 2010 at 10:23 AM, Alan Mackenzie <acm@muc.de> wrote:
>
>> You and a few others, so as to save a single key easy press (<del> or
>> C-w) want to heap massive inconvenience on others.
>
> Not a few. All non-Emacs users (and they are a majority) are used to
> that typing a character when text is selected will replace a visible
> region/selection.

That people are used to getting annoyed does not mean that they desire
getting annoyed.

Emacs has enough annoyances of its own.  Adding all annoyances people
see elsewhere is not going to improve its value, particularly not
long-term.

So can we please return to the discussion how delete-selection-mode can
be made to better fit with Emacs' handling of the mark?  If any attempt
of proposing better compatible semantics is shouted down, my vote for
making it the default is no.

Emacs' default settings should reflect a coherent whole that can be used
without the user needing circumventive measures between one part of the
keybindings and another.

As long as any attempt to achieve that is sabotaged, I am not in support
of "giving in" to the demands for more "standard" behavior.

One important metric for me is that when handing Emacs to a person
previously not exposed to computers, every question about Emacs' default
behavior can be answered without "it's inconvenient, but people are used
to it from other applications".

> Don't you think the way to go is to make suggestions that can both
> move us towards the common defaults and do what you think is best for
> old-timers?

Currently, any such suggestion is shouted down and not being discussed.

-- 
David Kastrup

Re: delete-selection-mode

[Lennart Borgman]

On Fri, Mar 19, 2010 at 2:26 PM, David Kastrup <dak@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Fri, Mar 19, 2010 at 10:23 AM, Alan Mackenzie <acm@muc.de> wrote:
>>
>>> You and a few others, so as to save a single key easy press (<del> or
>>> C-w) want to heap massive inconvenience on others.
>>
>> Not a few. All non-Emacs users (and they are a majority) are used to
>> that typing a character when text is selected will replace a visible
>> region/selection.
>
> So can we please return to the discussion how delete-selection-mode can
> be made to better fit with Emacs' handling of the mark?

Yes. I can of course not propose any details there since I am using
cua-mode to be closer to other applications. My interest is in getting
Emacs close to other applications - without disturbing or destroying
those possibilities Emacs have.

However getting Emacs closer to other apps is in my opinion the most
important. So I am interested in those suggestions that moves a bit
further in that direction.

> Emacs' default settings should reflect a coherent whole that can be used
> without the user needing circumventive measures between one part of the
> keybindings and another.

Yes. And by not using standard from other editing environment this has
becoming more and more difficult.

> As long as any attempt to achieve that is sabotaged, I am not in support
> of "giving in" to the demands for more "standard" behavior.

We are all struggling with this. It is difficult. It is not sabotage.

> One important metric for me is that when handing Emacs to a person
> previously not exposed to computers, every question about Emacs' default
> behavior can be answered without "it's inconvenient, but people are used
> to it from other applications".

Hm. Excuse me but this is a bit amusing. (Mostly because it reminds me
of other areas where similar claims have been made and grossly
disturbs the scientific knowledge in that area.)

Where do you find those? Why is it important?

Please notice that I (probably) do understand what you are trying say.
What I am asking you about is a creative merge of what you said above
and the current situation.

>> Don't you think the way to go is to make suggestions that can both
>> move us towards the common defaults and do what you think is best for
>> old-timers?
>
> Currently, any such suggestion is shouted down and not being discussed.

That is not by intention, at least not by me.

RE: delete-selection-mode

[Drew Adams]

> So can we please return to the discussion how
> delete-selection-mode can be made to better fit with
> Emacs' handling of the mark?

That is not the question. That was not the question raised by Juri for this
thread.

Nor is the question for this thread whether we should disable t-m-mode as the
default (your proposal) or any of the other garden paths you've wanted to send
us down.

The question Juri raised is a simple one:

Given that many new users are in fact looking for d-s-mode (without knowing it),
should we simply enable d-s-mode by default?

Put affirmatively, it is a proposal.

In Juri's own words (yes, it's worth rereading them):

> I agree with Richard that the primary concern is doing what is useful
> for newcomers.  One of the most frequent questions they ask 
> is how to do what most other editors do - to replace selected
> text with a typed character or with yanked text, and to delete
> the region by typing <delete> without copying it to the kill-ring.
> 
> What they are asking for is delete-selection-mode,
> but they can't find it in the documentation because
> the feature name says nothing to beginners, and
> they expect to take this functionality for granted.
> Some recent examples of such problems:...
>
> Is that reason enough to enable delete-selection-mode by default?

Note: He makes the claim that this problem for newcomers is one of the most
frequent they have trouble with. That's the "Whereas" or "Given" part of the
proposal - you are free to disagree that this is a fact. And he jumps from the
purported problem of discovering d-s-mode to a proposal to make it the default.

You've made your vote clear against Juri's proposal. Now let's move on to
getting more votes for/against and hopefully taking a user poll. And if people
want more time to experiment with d-s-mode, as Richard suggests, that's a good
idea too.

But d-s-mode, as it is, deserves a decision about its becoming the default.
That's the proposal this thread is about.

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

But let's not divert this thread into either "Let's disable t-m-mode" or "How
can we modify d-s-mode 'to better fit with Emacs's handling of the mark'?".

Start another thread or two for such things, if you like. I'll gladly answer you
there that d-s-mode itself does not need to be so modified, but you are welcome
to come up with a new mode that provides any chimera or glorious solution you
like.

Please do not try to use the proposal of this thread, which is to enable
d-s-mode by default, as cover for trying to modify d-s-mode. It's OK for us not
to use d-s-mode by default. It's not OK to hijack the thread about that
proposal. And IMO it's not OK to mess up d-s-mode.

Re: delete-selection-mode (was: Put scroll-bar on right by defaulton UNIX.)

[Chad Brown]

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

Greetings!

On Mar 18, 2010, at 11:54 AM, Alan Mackenzie wrote:

> You're being very dismissive of my experience simply because you're
> different and don't share it.  I am by no means unique - there will
> certainly be lots of other people who suffer this feature likewise;
> there're another one or two on this mailing list.  The degree of
> suffering d-s-m inflicts on us far outweighs the slight increase in
> convenience for you.

The degree of suffering `inflicted' on some undetermined number of users probably does outweigh the convenience for one person, but if that's the calculus you want to consider, the lack of d-s-m inflicts pain on a far, far greater percentage of the potential user base than will ever feel anxiety about mouse-based interfaces in an editing environment.

> However, with simple transient-mark-mode, the problem doesn't exist.
> Even a naive newbie would very quickly learn to hit the <delete> key if
> d-s-m weren't enabled.  Heavens, they do it already.  Do they complain
> about it?

Yes, they do -- they complain, and they also just stop using emacs, because the anxiety that you complain about affects so vastly many more of them.  You've made it clear that you don't like delete-selection-mode, and you don't like transient-mark-mode -- and for you, it is great that emacs is an extensible, customizable editing environment.  The question is not, and has never been ``which mode is better''.  It is not, and has never been ``which mode will new users expect''.  The question is just this:  do you want to change emacs' default behavior out-of-the-box to try to match what new users expect, or do you want to make the default configuration more comfortable for advanced, experienced, long-term emacs devotees.  This isn't an easy question, but it's not going to be answered by arguing over which mode is preferable for which audience, or which audience is `more right'.

*Chad

[-- Attachment #2: Type: text/html, Size: 2430 bytes --]

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Clearly the convenience benefit dominates for you; the accidental
 > explosion hazard dominates for me (in non-Emacs environments, where I
 > can't disable the (mis)feature).  I've no reason to suspect I'm unusual
 > here.

I'm sure you're not.  After all, I had exactly that experience ... for
about three days.

Note that in many non-Emacs environments, you also don't have decent undo.

 > It's "obviously" useful to be able to type extra text into an already
 > "existing" region.  The region is used for many things other than just
 > being deleted.

Could be, but I almost never use the region that way myself, and when
I do, C-x C-x does what I need (I don't need a visible region for that
use case, personally).

 > Do they?  How do we know there aren't lots of "veteran" users who don't
 > really know how to configure the thing?

Come now; if you're going to insist on being different to teach
newbies to use Emacs effectively, shouldn't that apply all the more to
using help and changing defaults for veterans?

 > I think we should also distinguish between pure new UI features, and
 > those that actively interfere with established usage.  My view is that we
 > should never make something default in Emacs if it's likely to provoke
 > the angry reaction "How do I disable this *!£$ing thing?".
 > delete-select-mode falls into this latter category.  So does
 > transient-mark-mode.

Guess what?  XEmacs did that experiment with zmacs-regions (~ t-m-m)
almost 15 years ago.  Oh, there was whining, and there was screaming,
and there were predictions of The Imminent End of the World as We Know
It (with which I quietly agreed).  But the switch was flipped,
zmacs-regions was made true by default, and you know what?  *Nobody
noticed!*  Some experienced users switched (as I did).  Many turned it
off in their init file.  The key is that nobody complained that they
gave it a real chance and still it sucked.

Since then there has been no question in my mind that changing
defaults is definitely an implement we should have in our toolbox.

 > Is there any evidence that delete-select-mode is instrinsically a good
 > thing, disregarding the fact that it has become common?

My personal experience.  I really didn't like it in theory, I found it
irritating in practice, but having given it a serious try, I now like
it, and miss it when I'm borrowing somebody's Emacs or something.

 > Where is the proof that d-s-m has proven itself efficient, rather than
 > being mainly an irritation?  That's a genuine question, not a rhetorical
 > one.

The proof of this pudding is in the eating.  It worked very well for
XEmacs with zmacs-regions, and even Richard now uses t-m-m.  I don't
know if it will work as well for delsel.

 > One reason people might have come to Emacs is to escape the (to them)
 > deity-awful key sequences they've been forced to use up to now.  It is
 > surely good to offer them an alternative.

Of course it's good to offer alternatives.  Whether that alternative
should be default or alternative option is an empirical question.  The
only way to really find out is to try it, *as default*.  If you see
some significant fraction of experienced users switching to the
default and none saying "I tried it and it sucked", it's probably a
good idea.

Re: delete-selection-mode (was: Put scroll-bar on right by default on UNIX.)

[Lennart Borgman]

On Fri, Mar 19, 2010 at 5:37 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
> My personal experience.  I really didn't like it in theory, I found it
> irritating in practice, but having given it a serious try, I now like
> it, and miss it when I'm borrowing somebody's Emacs or something.

:-)

It is a bit funny that trying have been such a hard thing. Thanks to
both you and rms for pointing this out.

> Of course it's good to offer alternatives.

It is easy to see that it has both positive and negative sides to
offer alternatives. But evaluating them is not easy.

Re: delete-selection-mode

[Manoj Srivastava]

On Thu, Mar 18 2010, Alan Mackenzie wrote:


>> In Emacsen without zmacs-regions/transient-mark-mode on, I agree
>> strongly.  In Emacs with t-m-m, I disagree strongly.
>
>> Yes, veteran users will find the change in defaults (both t-m-m and
>> delsel, whether simultaneously or sequentially) an irritating
>> distraction.  There should be a way for veterans to tell Emacs "Read
>> my lips: No New UI Features", but sadly enough, there isn't.  But vets
>> know how to turn off such annoyances quickly and permanently.
>
> Do they?  How do we know there aren't lots of "veteran" users who don't
> really know how to configure the thing?

        I have been using Emacs since 1987, but I do not know if I
 qualify to be a veteran by that criteria. Until I read this thread, I
 had noticed that large chunks of my buffers disappeared on me, but had
 not yet narrowed down what was causing this. I had even resorted to
 using vim instead.

        Shouldn't changes in default behaviour come with obvious
 instructions on how to revert things, like in the NEWS file?

        manoj
-- 
Broken promises don't upset me.  I just think, why did they believe me?
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Re: delete-selection-mode

[Glenn Morris]

Juri Linkov wrote:

> What they are asking for is delete-selection-mode,
> but they can't find it in the documentation because
> the feature name says nothing to beginners,

Then regardless of what the default is, the documentation should be
improved (eg by index entries) so that people _can_ find it.

This question is in the FAQ, by the way.

Re: delete-selection-mode

[Juri Linkov]

>> What they are asking for is delete-selection-mode,
>> but they can't find it in the documentation because
>> the feature name says nothing to beginners,
>
> Then regardless of what the default is, the documentation should be
> improved (eg by index entries) so that people _can_ find it.
>
> This question is in the FAQ, by the way.

The problem is that people won't know what index entries to search.
It's the fundamental feature in other editors that it has no special name.

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

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> Beyond a certain point, conflicting with users' expectations does more
> harm than good.

How exactly does having the scrollbar on a different side actually
_hurt_, though, especially when there are actually benefits as well?

[Obviously there are pedants who freak out when confronted by the
tiniest inconsistencies, but they're impossible to satisfy anyway.]

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> James Cloos <cloos@jhcloos.com> writes:
>
>> C> Put scroll-bar on right by default on UNIX.
>>
>> Ewww.  Why, if may I ask?
>>
>> Way over on the right makes the scrollbar essentially useless (except,
>> of course, for putative buffers which are (will be) primarily r2l
>> and those times when the frame is split horizontally).
>>
>> It really needs to be near the action, and on landscape displays the
>> frames are typically wider than (most of) the text.
>
> I'm familiar with the advantages, but this battle was fought long ago.

Emacs is not occupied territory.  Where it makes no sense, following the
herd is not necessary.

> Every graphical user interface created in the last X years puts the
> scroll bar on the right.

Emacs is not a graphical display application, but an input text oriented
system.  JFTR, xterm has its scrollbar on the _left_.

> Try naming one other application on a modern GNU/Linux desktop that
> does the opposite by default---they don't exist.

xterm

> Beyond a certain point, conflicting with users' expectations does more
> harm than good.

Emacs has never had any qualms about conflicting with expectations where
this makes better sense.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

David Kastrup <dak@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> James Cloos <cloos@jhcloos.com> writes:
>>
>>> C> Put scroll-bar on right by default on UNIX.
>>>
>>> Ewww.  Why, if may I ask?
>>>
>>> Way over on the right makes the scrollbar essentially useless (except,
>>> of course, for putative buffers which are (will be) primarily r2l
>>> and those times when the frame is split horizontally).
>>>
>>> It really needs to be near the action, and on landscape displays the
>>> frames are typically wider than (most of) the text.
>>
>> I'm familiar with the advantages, but this battle was fought long ago.
>
> Emacs is not occupied territory.  Where it makes no sense, following the
> herd is not necessary.
>
>> Every graphical user interface created in the last X years puts the
>> scroll bar on the right.
>
> Emacs is not a graphical display application, but an input text oriented
> system.  JFTR, xterm has its scrollbar on the _left_.
>

How silly.

I, and most users I suspect, would want the scrollbar on the GUI version
in the same place as the HUGE majority for GUI "X" applications. On the
right.

xterm is not a "GUI application" in any but the most pedantic minds.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Richard Riley <rileyrgdev@gmail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Chong Yidong <cyd@stupidchicken.com> writes:
>>
>>> James Cloos <cloos@jhcloos.com> writes:
>>>
>>>> C> Put scroll-bar on right by default on UNIX.
>>>>
>>>> Ewww.  Why, if may I ask?
>>>>
>>>> Way over on the right makes the scrollbar essentially useless (except,
>>>> of course, for putative buffers which are (will be) primarily r2l
>>>> and those times when the frame is split horizontally).
>>>>
>>>> It really needs to be near the action, and on landscape displays the
>>>> frames are typically wider than (most of) the text.
>>>
>>> I'm familiar with the advantages, but this battle was fought long ago.
>>
>> Emacs is not occupied territory.  Where it makes no sense, following the
>> herd is not necessary.
>>
>>> Every graphical user interface created in the last X years puts the
>>> scroll bar on the right.
>>
>> Emacs is not a graphical display application, but an input text oriented
>> system.  JFTR, xterm has its scrollbar on the _left_.
>
> How silly.
>
> I, and most users I suspect, would want the scrollbar on the GUI
> version in the same place as the HUGE majority for GUI "X"
> applications. On the right.
>
> xterm is not a "GUI application" in any but the most pedantic minds.

Neither is Emacs.  Both are focused about plain text input.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

David Kastrup <dak@gnu.org> writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Chong Yidong <cyd@stupidchicken.com> writes:
>>>
>>>> James Cloos <cloos@jhcloos.com> writes:
>>>>
>>>>> C> Put scroll-bar on right by default on UNIX.
>>>>>
>>>>> Ewww.  Why, if may I ask?
>>>>>
>>>>> Way over on the right makes the scrollbar essentially useless (except,
>>>>> of course, for putative buffers which are (will be) primarily r2l
>>>>> and those times when the frame is split horizontally).
>>>>>
>>>>> It really needs to be near the action, and on landscape displays the
>>>>> frames are typically wider than (most of) the text.
>>>>
>>>> I'm familiar with the advantages, but this battle was fought long ago.
>>>
>>> Emacs is not occupied territory.  Where it makes no sense, following the
>>> herd is not necessary.
>>>
>>>> Every graphical user interface created in the last X years puts the
>>>> scroll bar on the right.
>>>
>>> Emacs is not a graphical display application, but an input text oriented
>>> system.  JFTR, xterm has its scrollbar on the _left_.
>>
>> How silly.
>>
>> I, and most users I suspect, would want the scrollbar on the GUI
>> version in the same place as the HUGE majority for GUI "X"
>> applications. On the right.
>>
>> xterm is not a "GUI application" in any but the most pedantic minds.
>
> Neither is Emacs.  Both are focused about plain text input.

Indeed. But its X interface is still on a desktop next to other X
apps. The huge majority of whose scroll bars are on the right. It seems
almost a strange argument to be having.

And emacs is a scrollable UI - its an editor after all. Yes, you can
scroll xterm and urvt etc I know, but its not the same thing at all.

The X interface to Emacs should comply with the huge majority of
neighbouring apps. And thats the scroll bar on the right.

All IMO of course ;) But clearly also in the minds of other X authors.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Richard Riley <rileyrgdev@gmail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Richard Riley <rileyrgdev@gmail.com> writes:
>>
>>> xterm is not a "GUI application" in any but the most pedantic minds.
>>
>> Neither is Emacs.  Both are focused about plain text input.
>
> Indeed. But its X interface is still on a desktop next to other X
> apps. The huge majority of whose scroll bars are on the right.

To be honest: there are not many X apps next to Emacs on my desktop
since it is my main interface to the computer.

> It seems almost a strange argument to be having.
>
> And emacs is a scrollable UI - its an editor after all. Yes, you can
> scroll xterm and urvt etc I know, but its not the same thing at all.

Hm?  Why not?

> The X interface to Emacs should comply with the huge majority of
> neighbouring apps. And thats the scroll bar on the right.

The X interface to Emacs should first of all be focused on usability.
Putting the scrollbars on the left has not been an arbitrary choice.

When other applications make inferior user interface choices, we need
not follow them.  Emacs will never be the same as other applications,
and that is not a goal in itself.  Emacs should be as good as it can be
for doing work with it.  If that means being different, that is fine.

> All IMO of course ;) But clearly also in the minds of other X authors.

The important people are not the authors but the serious users.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Stallman]

    I, and most users I suspect, would want the scrollbar on the GUI version
    in the same place as the HUGE majority for GUI "X" applications. On the
    right.

Why do you prefer it on the right?
In what way is that advantageous or convenient for you?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

Richard Stallman <rms@gnu.org> writes:

>     I, and most users I suspect, would want the scrollbar on the GUI version
>     in the same place as the HUGE majority for GUI "X" applications. On the
>     right.
>
> Why do you prefer it on the right?
> In what way is that advantageous or convenient for you?
>

Because its in the same position as all other apps on my
desktop. Arbitrary positioning of any UI element is silly and the
reasons are well documented. In addition it isn't in my face since we
tend to read and write left to write so spend more time in the left side
of a window.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

Richard Riley <rileyrgdev@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     I, and most users I suspect, would want the scrollbar on the GUI version
>>     in the same place as the HUGE majority for GUI "X" applications. On the
>>     right.
>>
>> Why do you prefer it on the right?
>> In what way is that advantageous or convenient for you?
>>
>
> Because its in the same position as all other apps on my
> desktop. Arbitrary positioning of any UI element is silly and the
> reasons are well documented. In addition it isn't in my face since we
> tend to read and write left to write so spend more time in the left side
> of a window.
>

"Left to write". Wow. Brain fart there!

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Sean Sieger]

    "Left to write". Wow. Brain fart there!

Nah.  Much more meaningful than mere flatulation:  as one
writes---types, one is going right ... the energy is focused on the
right.  Um, like welding (if you'll pardon the unlikely analogic
outburst), where the fusion is happening, heating the materials ahead.
Only periodically touching the left margin, it may be an origin, but it
shouldn't be confused with the focal point---not in reading or writing.

Um, close reading being the exceptional, not the usual, again the motion
is left to right, the left margin is hardly the focal point.  The usual,
scansion, I would suggest a lot more reading is done in scansion than in
close reading, is a mode that takes place in the midst of lines.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Richard Riley <rileyrgdev@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     I, and most users I suspect, would want the scrollbar on the GUI version
>>     in the same place as the HUGE majority for GUI "X" applications. On the
>>     right.
>>
>> Why do you prefer it on the right?
>> In what way is that advantageous or convenient for you?
>>
>
> Because its in the same position as all other apps on my
> desktop. Arbitrary positioning of any UI element is silly and the
> reasons are well documented.

The positioning is not arbitrary.  You might with more reason argue that
arbitrary bindings of keys are silly, and that Emacs should have the
same bindings as Wordpad.  Because there is some arbitrariness involved
with the choice of keybindings.

But the scrollbar is on the left for a reason: _if_ you use the mouse
for editing, you'll use it more often than not on the left (until Eli's
work gets merged).  And the larger the windows are made horizontally,
the more of a nuisance it is to move the mouse.  In addition, if you use
Athena-style "proportional" scrollbars where you click next to the line
you want to scroll to the top, you can't usefully aim when the scrollbar
is on the right when the text does not run on for a full line (like when
editing shellscripts).

We have proportional scrolling when compiling without toolkit, and with
Xaw.  And Xaw has the default scrollbar on the left for other
applications.  It is really a pity that toolbars are either functional
and well-designed or pretty, but never both.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David De La Harpe Golden]

David Kastrup wrote:


> But the scrollbar is on the left for a reason: _if_ you use the mouse
> for editing, you'll use it more often than not on the left (until Eli's
> work gets merged)


Of course if you use a mouse in the modern era, chances are you'll
have a scroll wheel on the mouse, and be more perturbed by emacs'
treatment of the region and point when you scroll than the scrollbar's 
position. But that's a whole other can of worms.

I have the scrollbar on my screen (on the right, visible but nicely out 
of the way) primarily as a visual indicator of position in file, not to 
manipulate it much as such. I also tend to use emacs on modern landscape 
displays with two windows open side-by-side, so it's not all that far 
away on the right.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Stallman]

    Because its in the same position as all other apps on my
    desktop. Arbitrary positioning of any UI element is silly and the
    reasons are well documented. In addition it isn't in my face since we
    tend to read and write left to write so spend more time in the left side
    of a window.

It seems clear that you want to ignore the scroll bar.

Are you an experienced Emacs user?

Do you ever use the scroll bar in Emacs?
Would you be unhappy if you turned it off?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Stallman]

    I'm familiar with the advantages, but this battle was fought long ago.
    Every graphical user interface created in the last X years puts the
    scroll bar on the right.  Try naming one other application on a modern
    GNU/Linux desktop that does the opposite by default---they don't exist.

How are they relevant to this decision?

There are some interface details for which incompatibility is a real
pain in the neck.  But this is not one of them; it isn't harder to use
a scroll bar on the left just because in other apps it's on the right.
It may be a bit of a surprise to see it on the left, but that doesn't
impede use.

    Beyond a certain point, conflicting with users' expectations does more
    harm than good.  But, you can do

      (set-scroll-bar-mode 'left)

    or Options -> Show/Hide -> Scroll Bar -> On the Left.

Why choose anything other than the most convenient setting
as the default?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 13 Mar 2010 21:02:51 -0500
> Cc: cloos@jhcloos.com, emacs-devel@gnu.org
> 
>     Beyond a certain point, conflicting with users' expectations does more
>     harm than good.  But, you can do
> 
>       (set-scroll-bar-mode 'left)
> 
>     or Options -> Show/Hide -> Scroll Bar -> On the Left.
> 
> Why choose anything other than the most convenient setting
> as the default?

The problem is with how ``convenient'' is decided.  I suspect most
users nowadays will say that having the scroll bar on the right is the
most ``convenient''.  (I don't share that view, but I use the scroll
bar so little that my opinion hardly matters either way.)

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> The problem is with how ``convenient'' is decided.  I suspect most
> users nowadays will say that having the scroll bar on the right is the
> most ``convenient''. 

They may, but I suspect they can't actually say why...

The Emacs' position, whether one agrees with it or not, is actually
based on some reasoning.

[Thank god at least some of the hoary old artifacts of the original
macintosh GUI have been revised in recent years, e.g. fixed-size scroll
thumbs!]

-Miles

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

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>> The problem is with how ``convenient'' is decided.  I suspect most
>> users nowadays will say that having the scroll bar on the right is the
>> most ``convenient''. 
>
> They may, but I suspect they can't actually say why...

http://www.comp.lancs.ac.uk/~dixa/papers/scrollbar/

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Miles Bader <miles@gnu.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>> The problem is with how ``convenient'' is decided.  I suspect most
>>> users nowadays will say that having the scroll bar on the right is the
>>> most ``convenient''. 
>>
>> They may, but I suspect they can't actually say why...
>
> http://www.comp.lancs.ac.uk/~dixa/papers/scrollbar/

Also

http://www.comp.lancs.ac.uk/~dixa/papers/scrollbar/scrollbar2.html

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>>> They may, but I suspect they can't actually say why...
>>
>> http://www.comp.lancs.ac.uk/~dixa/papers/scrollbar/
> http://www.comp.lancs.ac.uk/~dixa/papers/scrollbar/scrollbar2.html

That's pretty flimsy...

-Miles

-- 
Barometer, n. An ingenious instrument which indicates what kind of weather we
are having.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

Miles Bader <miles@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>>>> They may, but I suspect they can't actually say why...
>>>
>>> http://www.comp.lancs.ac.uk/~dixa/papers/scrollbar/
>> http://www.comp.lancs.ac.uk/~dixa/papers/scrollbar/scrollbar2.html
>
> That's pretty flimsy...
>
> -Miles

Not really in that it makes perfect sense. Most keyboard jockeys use a
scroll bar to indicate relative positioning with most apps, and it being
on the right IS out of the way and it being on the right is more
consistent with the HUGE majority of other desktop applications.

If you turn it around, I can think of no compelling reason to have it on
the left. If I were to use a scroll bar it would be with the mouse and
guess where my idle mouse pointer usually is ..... lurking around out of
harms way on the ... right of the screen ie closed to where most people
put their scroll bar.

Emacs doesn't always have to be counter intuitive to non hardcore
terminal users and Emacs nOObs ...

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Miles Bader]

Richard Riley <rileyrgdev@gmail.com> writes:
>> That's pretty flimsy...
>
> Not really in that it makes perfect sense. Most keyboard jockeys use a
> scroll bar to indicate relative positioning with most apps, and it being
> on the right IS out of the way and it being on the right is more
> consistent with the HUGE majority of other desktop applications.

... those are pretty flimsy too.

-Miles

-- 
Absurdity, n. A statement or belief manifestly inconsistent with one's own
opinion.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

Miles Bader <miles@gnu.org> writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>>> That's pretty flimsy...
>>
>> Not really in that it makes perfect sense. Most keyboard jockeys use a
>> scroll bar to indicate relative positioning with most apps, and it being
>> on the right IS out of the way and it being on the right is more
>> consistent with the HUGE majority of other desktop applications.
>
> ... those are pretty flimsy too.
>
> -Miles

You keep calling things that are pretty obvious and core to UI design
issues "flimsy" while offering little in objection. I guess your mind is
made up.

Frankly I am surprised you think its "flimsy" to make it consistent with
the vast majority of other desktop applications. I call it very
important.

regards,

r.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Miles Bader]

Richard Riley <rileyrgdev@gmail.com> writes:
> You keep calling things that are pretty obvious and core to UI design
> issues "flimsy" while offering little in objection. I guess your mind is
> made up.

And you keep throwing up random unsubstantiated hand-waving as if it's
somehow authoritative.

> Frankly I am surprised you think its "flimsy" to make it consistent
> with the vast majority of other desktop applications. I call it very
> important.

Consistency is sometimes important, but it's not some kind of magic
powder that always grants merit.  The question (as Richard pointed out)
is whether "consistency" is actually _important_ in _this_ case.  It may
indeed be, but so far nobody has provided any real support for that
position other than vague hand-waving, and I think there's been equally
good support for the opposition position (not saying a whole lot, I
admit).

Granted, vague hand-waving is rife in the HCI field, but it's no more
convincing for that.

-Miles

-- 
Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
Cassandra has a following and seven cities compete for the honor of endowing a
living Homer.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

Miles Bader <miles@gnu.org> writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>> You keep calling things that are pretty obvious and core to UI design
>> issues "flimsy" while offering little in objection. I guess your mind is
>> made up.
>
> And you keep throwing up random unsubstantiated hand-waving as if it's
> somehow authoritative.

What have I said that is any way random? You made that up to camouflage
your wishy washy defence for not supporting the rhs. There are plenty of
authoritative HCI studies which support UI controls being consistent
across desktop applications. I assumed you would have known that so I
didn't go into more detail.

>
>> Frankly I am surprised you think its "flimsy" to make it consistent
>> with the vast majority of other desktop applications. I call it very
>> important.
>
> Consistency is sometimes important, but it's not some kind of magic
> powder that always grants merit.  The question (as Richard pointed
> out)

Yes it is. Consistency is always of some merit. Its why it exists in
well designed apps and products.

> is whether "consistency" is actually _important_ in _this_ case.  It
> may

Consistency is always of some importance. And over thinking it for
Emacs is not healthy IMO.

> indeed be, but so far nobody has provided any real support for that
> position other than vague hand-waving, and I think there's been equally
> good support for the opposition position (not saying a whole lot, I
> admit).

I have seen nothing which comes even close to warranting a departure of
the standard right hand side positioning for desktop apps.

>
> Granted, vague hand-waving is rife in the HCI field, but it's no more
> convincing for that.
>
> -Miles

This vague hand waving of which you speak is non existent. The fact that
UI controls in the same place IS beneficial surely is not disputed. Next
you'll be telling me its "vague hand waving" to have the same Desktop
key sequences to cut/paste/close windows etc across different
apps. Admittedly that, though, doesnt come into an Emacs discussion ;)

And once more you have thrown vaguely veiled scorn at relatively strong
reasons for positioning it on the right while providing
little if any support for placing it anywhere else. Is it the end of the
world to place it left? Of course not. Is it better its where it is on
most other apps? I think it is. And there is nothing "flimsy" or "wishy
washy" about that.

regards

r.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Richard Riley <rileyrg@googlemail.com> writes:

> Miles Bader <miles@gnu.org> writes:
>
>> Richard Riley <rileyrgdev@gmail.com> writes:
>>> You keep calling things that are pretty obvious and core to UI design
>>> issues "flimsy" while offering little in objection. I guess your mind is
>>> made up.
>>
>> And you keep throwing up random unsubstantiated hand-waving as if it's
>> somehow authoritative.
>
> What have I said that is any way random? You made that up to camouflage
> your wishy washy defence for not supporting the rhs. There are plenty of
> authoritative HCI studies which support UI controls being consistent
> across desktop applications. I assumed you would have known that so I
> didn't go into more detail.

Emacs is not consistent "across desktop applications" in pretty much
every other aspect if we consider out-of-emacs experiences (which become
increasingly less frequent the more you learn to use Emacs for a
multitude of tasks).  We don't adopt other conventions blindly.

So if you want to make a point worth considering, repeatedly merely
stating "everybody else does it" without even bothering to address
actual usability considerations made by others will not serve to support
your point.

Mindless repetition is not adding information to intelligent discourse,
even though our culture sometimes makes that hard to forget.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Alan Mackenzie]

Hi, everybody.

On Sun, Mar 14, 2010 at 01:16:08PM +0900, Miles Bader wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> > The problem is with how ``convenient'' is decided.  I suspect most
> > users nowadays will say that having the scroll bar on the right is
> > the most ``convenient''. 

> They may, but I suspect they can't actually say why...

I can.  On the right, the scroll bar doesn't get in the way, at least not
very much.  On the left, it is very close to where you're mostly
inserting/deleting/reading text, and acts like a dripping tap, a sounding
foghorn, a nagging wife, some illocatable rotting fish.  It takes over
your mind, reducing your concentration on what you're doing.

> The Emacs' position, whether one agrees with it or not, is actually
> based on some reasoning.

I think it's based on the assumption that a scroll bar is an essential
part of editing that nobody can bear to be without; that it'll be getting
used so often that nobody could possibly object to it.  I think these
assumptions warrant examination, particularly under Emacs.

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany)
, who uses (scroll-bar-mode -1) when inside a GUI.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

[Lots]

If you disable the scrollbar altogether anyway, it is sort of
metaphysical to argue that it would be nicer to disable it on the right
side.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, everybody.
>
> On Sun, Mar 14, 2010 at 01:16:08PM +0900, Miles Bader wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > The problem is with how ``convenient'' is decided.  I suspect most
>> > users nowadays will say that having the scroll bar on the right is
>> > the most ``convenient''. 
>
>> They may, but I suspect they can't actually say why...
>
> I can.  On the right, the scroll bar doesn't get in the way, at least not
> very much.  On the left, it is very close to where you're mostly
> inserting/deleting/reading text, and acts like a dripping tap, a sounding
> foghorn, a nagging wife, some illocatable rotting fish.  It takes over
> your mind, reducing your concentration on what you're doing.

It might help to reduce its size.  I use --without-toolkit-scrollbars
myself and additionally

(setq-default scroll-bar-width 15)


-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Stefan Monnier]

> It might help to reduce its size.  I use --without-toolkit-scrollbars
> myself and additionally
> (setq-default scroll-bar-width 15)

15 is reduced?  I've had it set to 6 for so long that I can't imagine
what "more than 15" could fee like,


        Stefan


PS: Oh, wait, no I can: all other apps (e.g. Firefox) have a thick
ugly scrollbar.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

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

>> It might help to reduce its size.  I use --without-toolkit-scrollbars
>> myself and additionally
>> (setq-default scroll-bar-width 15)
>
> 15 is reduced?  I've had it set to 6 for so long that I can't imagine
> what "more than 15" could fee like,

It has been smaller at one time for me, but screen resolutions have
increased.  Maybe it would make sense for such resources to be
specifiable as a float and have it measured as a multiple of the
standard font's character pitch rather than an absolute number of
pixels.

I want to be able to hit the scrollbar without squinting somewhat
reliably, and 0.8 characters are more or less what makes that convenient
for me.

-- 
David Kastrup

RE: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-baron right by default on UNIX.

[Drew Adams]

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

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> It might help to reduce its size.  I use 
> >> --without-toolkit-scrollbars myself and additionally
> >> (setq-default scroll-bar-width 15)
> >
> > 15 is reduced?  I've had it set to 6 for so long that I 
> > can't imagine what "more than 15" could fee like,
> 
> It has been smaller at one time for me, but screen resolutions have
> increased.  Maybe it would make sense for such resources to be
> specifiable as a float and have it measured as a multiple of the
> standard font's character pitch rather than an absolute number of
> pixels.
> 
> I want to be able to hit the scrollbar without squinting somewhat
> reliably, and 0.8 characters are more or less what makes that 
> convenient for me.

I never thought I'd reply to this thread, but you open a side topic that is
interesting. Yes, 0.8 chars. Or 1.3 chars, or 0.6 chars. Users can have
different preferences, but what's interesting is to have the scroll-bar width
follow the frame char size.

As a default scroll-bar size (possibly giving users some way to customize to
override/adjust, as in 0.8 vs 1.0), the default (frame) char size is a good
yardstick. If you can see and manipulate chars with the mouse, then the same
generally holds for the scroll bar.

In fact, I miss the Emacs 20 feature (yes, to me it is a feature), at least on
Windows, that the scroll bar size (width) follows the frame char size in just
this way. If you shrink a frame (its font), then the scroll bar width shrinks
accordingly. Whatever size text you (your eyes and your mouse fingers) are
comfortable with, the scroll bar will be the same size, so you are likely to be
comfortable with it also.

A side-benefit of the Emacs 20 behavior (on Windows, at least) is that I can
leave the scroll bars turned in my thumbnail frames (tiny frames that act kinda
like icons). You can scroll them using the mouse, in addition to using keys. See
attached images - the scroll bar in the Emacs 20 case is only a few pixels wide,
but it works fine.

Obviously, you would not want to do lots of work using the mouse on a thumbnail
frame. But you can - select text, click buttons/links, scroll, etc. The point is
that if you're comfortable manipulating text of a given size, then you are
likely to be just as comfortable using a scroll bar of about that size (width).

Yes, I know, we're not going to go back to the display system used for Emacs 20.
(Too bad, at least in some respects, like this one. IMO.)

[-- Attachment #2: throw-emacs-23-thumb-frame.png --]
[-- Type: image/png, Size: 27350 bytes --]

[-- Attachment #3: throw-emacs-20-thumb-frame.png --]
[-- Type: image/png, Size: 26637 bytes --]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-baron right by default on UNIX.

[James Cloos]

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

DA> As a default scroll-bar size (possibly giving users some way to
DA> customize to override/adjust, as in 0.8 vs 1.0), the default (frame)
DA> char size is a good yardstick. If you can see and manipulate chars
DA> with the mouse, then the same generally holds for the scroll bar.

I'm not sure where the scrollbar width on my toolkit=athena compile
(using Xaw3) comes from, but my scrollbars are indeed just as wide
as my cursor.  Perhaps coincidence, perhaps by design.  They are also
a nice, neutral gray, with just enough highlighting to have a 3d look.
(The colour of the thumb is the same as the current buffer's modeline,
the background a bit darker.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

RE: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-baron right by default on UNIX.

[Drew Adams]

> DA> As a default scroll-bar size (possibly giving users some way to
> DA> customize to override/adjust, as in 0.8 vs 1.0), the default (frame)
> DA> char size is a good yardstick. If you can see and manipulate chars
> DA> with the mouse, then the same generally holds for the scroll bar.
> 
> I'm not sure where the scrollbar width on my toolkit=athena compile
> (using Xaw3) comes from, but my scrollbars are indeed just as wide
> as my cursor.  Perhaps coincidence, perhaps by design.  They are also
> a nice, neutral gray, with just enough highlighting to have a 3d look.
> (The colour of the thumb is the same as the current buffer's modeline,
> the background a bit darker.)

But is it fortuitous or a general rule? If you change the frame text size, does
the scroll-bar width change accordingly?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-baron right by default on UNIX.

[James Cloos]

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

DA> But is it fortuitous or a general rule? If you change the frame text
DA> size, does the scroll-bar width change accordingly?

I tested it, and did some doc grepping.  It is indeed merely a coincidence.

And even appears to be the default width for Xaw3d.

But I suspect that default was chosen to blend in well with default
fonts in the 14 to 16 px range.  So although it isn't automated, it
probably is, none-the-less, by design.

As you can probably guess, I agree that sizing the bars based on some
one-to-one and onto function of the text font's size would be a good
idea.  I'm thinking the width should scale along the lines of, perhaps,
the square root of the primary font's height?


-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-baron right by default on UNIX.

[David Kastrup]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "DA" == Drew Adams <drew.adams@oracle.com> writes:
>
> DA> But is it fortuitous or a general rule? If you change the frame text
> DA> size, does the scroll-bar width change accordingly?
>
> I tested it, and did some doc grepping.  It is indeed merely a coincidence.
>
> And even appears to be the default width for Xaw3d.
>
> But I suspect that default was chosen to blend in well with default
> fonts in the 14 to 16 px range.  So although it isn't automated, it
> probably is, none-the-less, by design.

Emacs 19 had a rather rigid character-cell based layout.  It is possible
that the Xaw code (likely the first supported toolkit, or close) still
had its default chosen with that restriction in mind.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[James Cloos]

>>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

AM> On the right, the scroll bar doesn't get in the way, at least not
AM> very much.

In other words, it is essentially invisible and might as well not exist
at all.  A nice narrow, neutral gray or grayish bar has just the right
visibility to provide data w/o distraction.

AM> On the left, it is very close to where you're mostly
AM> inserting/deleting/reading text,

and hense is w/in view and therefore usable.

AM> I think it's based on the assumption that a scroll bar is an
AM> essential part of editing that nobody can bear to be without; that
AM> it'll be getting used so often that nobody could possibly object
AM> to it.  I think these assumptions warrant examination, particularly
AM> under Emacs.

The most important use of the scroll bar in a keyboard-controlable app
like Emacs is as a visual reference to the size of the buffer as compared
to the size of the visible window.

That only works when it is near the text.

Most apps should have their vertical bar on the left in l2r locales and
right in r2l locales.  And they should blend into the background except
when you actually want to look at them.  Emacs --with-toolkit=athena
does that exceptionally well.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Alan Mackenzie]

On Sun, Mar 14, 2010 at 02:02:40PM -0400, James Cloos wrote:
> >>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

> AM> On the right, the scroll bar doesn't get in the way, at least not
> AM> very much.

> In other words, it is essentially invisible and might as well not exist
> at all.  A nice narrow, neutral gray or grayish bar has just the right
> visibility to provide data w/o distraction.

No.  It's visible, but not intrusive there.  Anyhow, as I said, I run
Emacs without a scroll bar.

> AM> On the left, it is very close to where you're mostly
> AM> inserting/deleting/reading text,

> and hence is w/in view and therefore usable.

> AM> I think it's based on the assumption that a scroll bar is an
> AM> essential part of editing that nobody can bear to be without; that
> AM> it'll be getting used so often that nobody could possibly object
> AM> to it.  I think these assumptions warrant examination, particularly
> AM> under Emacs.

> The most important use of the scroll bar in a keyboard-controlable app
> like Emacs is as a visual reference to the size of the buffer as
> compared to the size of the visible window.

I would think it's more of a personal thing

> That only works when it is near the text.

I would think that's a personal thing, too.

> Most apps should have their vertical bar on the left in l2r locales and
> right in r2l locales.  And they should blend into the background except
> when you actually want to look at them.  Emacs --with-toolkit=athena
> does that exceptionally well.

Again, it's a competition between being easily visible and cluttering up
an important part of your frame.  It's a bit like the blinking cursor
debate.  I think we'd agree, it wouldn't be a bad idea for the scroll bar
position to be an option.

> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[James Cloos]

>>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

AM> I think we'd agree, it wouldn't be a bad idea for the scroll
AM> bar position to be an option.

Yes, we (all, I'm sure) fully agree on that point.

Incidently, according to info the scroll bar position is not
configurable via X Resources, only its width is.

That should be fixed as well.  Anytime frame parameters such
as that are changed after the frame is first mapped, users are
subjected to annoyances like flashing and sometimes even bugs.
Similar examples of features better disabled by resources than
by the init file -- and which already can be -- are the toolbar
and the menubar.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Andreas Schwab]

James Cloos <cloos@jhcloos.com> writes:

> Incidently, according to info the scroll bar position is not
> configurable via X Resources, only its width is.

emacs.verticalScrollBars

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[James Cloos]

>>>>> "AS" == Andreas Schwab <schwab@linux-m68k.org> writes:

>> Incidently, according to info the scroll bar position is not
>> configurable via X Resources, only its width is.

AS> emacs.verticalScrollBars

Cool.  Thanks.  It is even on the very page I didn't see it on. ☹

But that and the man page say that it only controls on or off, not
right or left.

The code (in lisp/term/x-win.el in trunk) checks for right, but
not for left, off or on.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Jan Djärv]

Andreas Schwab skrev 2010-03-14 21.38:
> James Cloos<cloos@jhcloos.com>  writes:
>
>> Incidently, according to info the scroll bar position is not
>> configurable via X Resources, only its width is.
>
> emacs.verticalScrollBars
>

The documentation isn't updated though, it only mentions on and off, not left 
and right.

	Jan D.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Jan D.]

James Cloos wrote:

> The code (in lisp/term/x-win.el in trunk) checks for right, but
> not for left, off or on.

Since left is the default, it doesn't need to, but something to remmeber 
if we should change the default.  Note that the code in x-win.el doesn't 
change the position of the scrollbar. That is done in frame.c and 
xterm.c (and corresponding tool-kit dependent files).

x-win.el just changes the customize default to be right instead of left.

	Jan D.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Alan Mackenzie]

Hi, James,

On Sun, Mar 14, 2010 at 03:21:05PM -0400, James Cloos wrote:
> >>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

> AM> I think we'd agree, it wouldn't be a bad idea for the scroll
> AM> bar position to be an option.

> Yes, we (all, I'm sure) fully agree on that point.

> Incidently, according to info the scroll bar position is not
> configurable via X Resources, only its width is.

> That should be fixed as well.  Anytime frame parameters such
> as that are changed after the frame is first mapped, users are
> subjected to annoyances like flashing and sometimes even bugs.
> Similar examples of features better disabled by resources than
> by the init file -- and which already can be -- are the toolbar
> and the menubar.

This is only partly true - these features can only by {en,dis}abled by
resources on platforms which have them.  This doesn't include, e.g., the
Linux tty.  Although this tty doesn't implement a scroll bar, it can
display a menu bar.  (I'd love to find out if it can be used by a GPM
mouse; so far I've not managed to get it working.)

> -JimC

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Date: Sun, 14 Mar 2010 14:02:40 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, cyd@stupidchicken.com,
> 	rms@gnu.org, Miles Bader <miles@gnu.org>
> 
> The most important use of the scroll bar in a keyboard-controlable app
> like Emacs is as a visual reference to the size of the buffer as compared
> to the size of the visible window.
> 
> That only works when it is near the text.

Do you really need this indication so often as to make this a serious
argument?

> Most apps should have their vertical bar on the left in l2r locales and
> right in r2l locales.

Guess what? most apps I've seen don't change their scroll bar location
no matter which directionality is the prevailing one in the current
locale.

And what is ``r2l locale'', anyway?  Let's say I have on the same
frame one buffer with prose in R2L script, and another buffer with a C
or Lisp source -- do you want Emacs to display the scroll bar for each
buffer on different sides? in the same frame?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[James Cloos]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> The most important use of the scroll bar in a keyboard-controlable app
>> like Emacs is as a visual reference to the size of the buffer as compared
>> to the size of the visible window.

EZ> Do you really need this indication so often as to make this a serious
EZ> argument?

Yes, I do.  Almost every day in Gnus *Aritcle* buffers; regularly when
editing outouting mail, source code, TeX, html and the like.  It is
fast, easy, does not require re-focusing my eyes.  It just works.

And it is a useful metric for how long-winded I missive might be, how
far point (assuming it is currently displayed) is from some other
section of code, and whether the file is getting long enough that it
ought to be split.

I also use the bar in 'zilla that way, although it isn't quite as good as
Emacs' and Xaw3d's implementations.  (In Seamonkey keyboard control works 
almost as well as in Emacs, so I don't need its bar for scrolling either.
Firfox, however, broke keyboard control; only there and in links' graphic
mode do I regularly need to use the bar to scroll.)

EZ> Guess what? most apps I've seen don't change their scroll bar location
EZ> no matter which directionality is the prevailing one in the current
EZ> locale.

I'm not surprised that they don't, but if that means they always have
the bar on the right, then that benefits the r2l users more than it
benefits l2r users like myself.

EZ> And what is ``r2l locale'', anyway?

Shorthand for users who do something like LANG=ar_XX.UTF-8, LANG=fa_XX.utf8
or LANG=he_XX.utf8, to pick some semi-random examples (with XX in place of
any majuscule, 2-letter country code) and thus get all of their UI elements
in r2l.  As an example, I've seen screenshots where the menus started on
the right instread of the left.

By mentioning that possibility, I was simply trying to be inclusionist
rather than exclusionist.

EZ> Let's say I have on the same frame one buffer with prose in R2L
EZ> script, and another buffer with a C or Lisp source -- do you want
EZ> Emacs to display the scroll bar for each buffer on different sides?
EZ> in the same frame?

I wouldn't.  But my point, given that I was arguing that the bar should
be closer to the text, was that if all of the text a user tends to edit
is tied to the right margin rather than to the left margin, then their
scrollbar location preferences may also be the opposite of mine, even
if their usage pattern and needs are otherwise the same.

(I hope that explains the point well enough.)

What I would want, in the case you decribe above, is to keep the bar on
the left, but have the right margin of the r2l text positioned close
enought to the left margin of the buffer, that the text would be in
about the same part of the screen as if it were l2r text.  (I got the
impression that fill-column might end up overloaded for that function
from one of the emacs-bidi threads; I am very much in favour of that
or something like that.)

I can see that this buffer is now more than twice as tall as the
frame; seems like a good point to stop writing. ;)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Mar 2010 16:25:57 -0400
> 
> EZ> Let's say I have on the same frame one buffer with prose in R2L
> EZ> script, and another buffer with a C or Lisp source -- do you want
> EZ> Emacs to display the scroll bar for each buffer on different sides?
> EZ> in the same frame?
> 
> What I would want, in the case you decribe above, is to keep the bar on
> the left, but have the right margin of the r2l text positioned close
> enought to the left margin of the buffer, that the text would be in
> about the same part of the screen as if it were l2r text.

No application behaves like that.  I don't think Emacs needs to
reinvent the wheel.  There are enough real problems waiting to be
solved with the bidirectional editing.  Compared to them, the
scroll-bar position is a non-issue.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Óscar Fuentes]

James Cloos <cloos@jhcloos.com> writes:

[snip]

> The most important use of the scroll bar in a keyboard-controlable app
> like Emacs is as a visual reference to the size of the buffer as compared
> to the size of the visible window.

Agreed. Some configurations doesn't work very well for this,
though. That's the reason I configure with --whitout-toolkit-scroll-bars

> That only works when it is near the text.

I disagree. I have (vertical-scroll-bars . right) and see no decrease on
its informative purpose, even on a wide 160 column display.

Scrollbars on the left looks funny to me. Maybe because I was a Windows
user and now a KDE one, and hence I expect to see the scrollbars on the
right.

IMHO, if what RMS says about the newcomers' convenience having
preference is the definitive criteria (and I think it is a good one)
scrollbars should be on the right, where most people expect to see them
nowadays and thus decrease the weird/intimidating first impression that
Emacs may convey on prospective users.

[snip]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Stallman]

    IMHO, if what RMS says about the newcomers' convenience having
    preference is the definitive criteria (and I think it is a good one)
    scrollbars should be on the right, where most people expect to see them
    nowadays and thus decrease the weird/intimidating first impression that
    Emacs may convey on prospective users.

Concern for newcomers does not necessarily mean doing what they
EXPECT.  It means doing what is useful for them.  Their previous
expectations are part of that question, but not necessarily the whole
of it.

It could be useful to ask some fairly new users to try both ways for a
few days and see what they prefer.  But even that is only part of it,
since the real question is what guides them to become better advanced
users subsequently.

Perhaps what we want to do is teach them not to use the scroll bar any
more.  If so, putting GTK scroll bars on the right might be good.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Lennart Borgman]

On Mon, Mar 15, 2010 at 10:46 PM, Richard Stallman <rms@gnu.org> wrote:
>    IMHO, if what RMS says about the newcomers' convenience having
>    preference is the definitive criteria (and I think it is a good one)
>    scrollbars should be on the right, where most people expect to see them
>    nowadays and thus decrease the weird/intimidating first impression that
>    Emacs may convey on prospective users.
>
> Concern for newcomers does not necessarily mean doing what they
> EXPECT.  It means doing what is useful for them.  Their previous
> expectations are part of that question, but not necessarily the whole
> of it.


If you want someone to learn something then it might be a good idea
not to patronize them. It is probably better to make it easy and
obvious to find what can be useful for them. If they want to learn
they will look for it.

And who starts using Emacs without wanting to learn? ;-)

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Stallman]

    I think it's based on the assumption that a scroll bar is an essential
    part of editing that nobody can bear to be without; that it'll be getting
    used so often that nobody could possibly object to it.  I think these
    assumptions warrant examination, particularly under Emacs.

It's based on the assumption that the user will use the scroll bar to
scroll.  That's not true for all users -- for instance, I would never
use the scroll bar to scroll in Emacs, because the keyboard is so much
more convenient.

The scroll bar can also be used to see where in the buffer you are.
It is not necessary to use the scroll bar for this, since the mode
line gives the same info.  But some people may have the habit of
getting it from the scroll bar.  Maybe people who use the scroll bar
that way would prefer it on the right.

If you don't use the scroll bar, you may as well turn it off.

I expect that beginners are more likely to use the scroll bar, while
experienced users would not.  But the experienced users can turn off
the scroll bar, or move it, so we need not cater to them.  The
beginners are the most important users to think about when making this
decision.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> It's based on the assumption that the user will use the scroll bar to
> scroll.  That's not true for all users -- for instance, I would never
> use the scroll bar to scroll in Emacs, because the keyboard is so much
> more convenient.
>
> The scroll bar can also be used to see where in the buffer you are.
> It is not necessary to use the scroll bar for this, since the mode
> line gives the same info.  But some people may have the habit of
> getting it from the scroll bar.  Maybe people who use the scroll bar
> that way would prefer it on the right.

I think the solution floated earlier can address this: those who want to
use the scroll bar as a visual aid should compile without GTK tool bars,
and we should place such tool bars on the left by default, where they
traditionally are in Motif and other old X apps.  GTK tool bars should
be placed on the right by default, like all other GTK apps.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Jan Djärv]

Chong Yidong skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>> It's based on the assumption that the user will use the scroll bar to
>> scroll.  That's not true for all users -- for instance, I would never
>> use the scroll bar to scroll in Emacs, because the keyboard is so much
>> more convenient.
>>
>> The scroll bar can also be used to see where in the buffer you are.
>> It is not necessary to use the scroll bar for this, since the mode
>> line gives the same info.  But some people may have the habit of
>> getting it from the scroll bar.  Maybe people who use the scroll bar
>> that way would prefer it on the right.
> 
> I think the solution floated earlier can address this: those who want to
> use the scroll bar as a visual aid should compile without GTK tool bars,
> and we should place such tool bars on the left by default, where they
> traditionally are in Motif and other old X apps.  GTK tool bars should
> be placed on the right by default, like all other GTK apps.
> 

I think you meant scroll bars.

	Jan D.

Put tool-bar on right (was: Put scroll-bar on right by default on UNIX.)

[Juri Linkov]

>> I think the solution floated earlier can address this: those who want to
>> use the scroll bar as a visual aid should compile without GTK tool bars,
>> and we should place such tool bars on the left by default, where they
>> traditionally are in Motif and other old X apps.  GTK tool bars should
>> be placed on the right by default, like all other GTK apps.
>
> I think you meant scroll bars.

Speaking of tool bars, do you know is it possible to place tool bars
and tab bars on the side (left or right)?  Currently I have to disable
the tool bar because vertical space is much more valuable for me than
horizontal space.  I'd like to enable tool bars if they were placed
on the left or on the right.

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

Re: Put tool-bar on right

[Jan D.]

Juri Linkov wrote:
>>> I think the solution floated earlier can address this: those who want to
>>> use the scroll bar as a visual aid should compile without GTK tool bars,
>>> and we should place such tool bars on the left by default, where they
>>> traditionally are in Motif and other old X apps.  GTK tool bars should
>>> be placed on the right by default, like all other GTK apps.
>> I think you meant scroll bars.
> 
> Speaking of tool bars, do you know is it possible to place tool bars
> and tab bars on the side (left or right)?  Currently I have to disable
> the tool bar because vertical space is much more valuable for me than
> horizontal space.  I'd like to enable tool bars if they were placed
> on the left or on the right.

It is not done in Emacs, but it is possible to add such a possibility.

	Jan D.

Re: Put tool-bar on right

[Stefan Monnier]

>> Speaking of tool bars, do you know is it possible to place tool bars
>> and tab bars on the side (left or right)?  Currently I have to disable
>> the tool bar because vertical space is much more valuable for me than
>> horizontal space.  I'd like to enable tool bars if they were placed
>> on the left or on the right.
> It is not done in Emacs, but it is possible to add such a possibility.

Seeing how it's getting every time more difficult to find screens that
don't have a ridiculous 123/4 length-to-height ratio, it would indeed be
desirable to let the toolbar be on the left (or right).
I.e. patches welcome,


        Stefan

Re: Put tool-bar on right

[Jan Djärv]

2010-03-17 14:32, Stefan Monnier skrev:
>>> Speaking of tool bars, do you know is it possible to place tool bars
>>> and tab bars on the side (left or right)?  Currently I have to disable
>>> the tool bar because vertical space is much more valuable for me than
>>> horizontal space.  I'd like to enable tool bars if they were placed
>>> on the left or on the right.
>> It is not done in Emacs, but it is possible to add such a possibility.
>
> Seeing how it's getting every time more difficult to find screens that
> don't have a ridiculous 123/4 length-to-height ratio, it would indeed be
> desirable to let the toolbar be on the left (or right).
> I.e. patches welcome,

I just got one of those 16:9 screens, so I added this for the Gtk+ tool bar.
It would be easier to add to the rest of X builds if we had a Lucid tool bar, 
i.e. not managed by the redisplay code.  I don't know if it is worth the 
effort though.

	Jan D.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Stallman]

    The problem is with how ``convenient'' is decided.  I suspect most
    users nowadays will say that having the scroll bar on the right is the
    most ``convenient''.

Rather than supposing, let's ask the users what they prefer, and
why.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Daniel Pittman]

Richard Stallman <rms@gnu.org> writes:

>     The problem is with how ``convenient'' is decided.  I suspect most
>     users nowadays will say that having the scroll bar on the right is the
>     most ``convenient''.
>
> Rather than supposing, let's ask the users what they prefer, and why.

For what it is worth, having used Emacs for over ten years now my preference
would be to place the scroll-bar on the right by default.[1]

Over the course of that period I have used the scroll-bar on the left, for
many years, and on the right, for roughly the same period of time[2].

For my use, where I don't use it to scroll because I strongly prefer the
keyboard, and only occasionally use it as an indication of document position,
this is a nicer position than on the left for me.

I find it less visually distracting positioned out of the way, and more
consistent with other applications that I use.  These are, primarily, esthetic
issues, not practical issues.


However, I strongly agree with your later comment, Richard, that I am not the
user that you should be caring about here: after ten years of using Emacs, and
as a software developer, it wouldn't bother me where the default was,
because I know that I can change it.


I think that for a new user, even if it was the worst option[3], being
consistent with other applications by default is a good choice.

Emacs is a hard tool to learn, and it cost me a lot of suffering and tears
when I first had to use it after using GoldEd and other non-programmable (and
non-free) editors for some years.

The more non-standard things the new user is confronted with, the harder they
are going to find it to learn Emacs, and for better or worse my experience
suggests that many users are quite visually- and mouse-focused when they start
using a new software package.

Regards,
        Daniel

Footnotes: 
[1]  I would strongly oppose any movement to force people to use this, by
     removing options to hide or alter the placement of the scroll-bar, of
     course, since personal taste is naturally personal.

[2]  I swapped them over about five years back now, thinking on it.

[3]  ...the articles discussing actual research into scroll-bar placement,
     posted earlier in this thread, suggest that "on the right" was the best
     option twenty years ago, and it is now even more embedded in the learned
     experience of computing.

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Miles Bader]

Daniel Pittman <daniel@rimspace.net> writes:
> [3]  ...the articles discussing actual research into scroll-bar placement,
>      posted earlier in this thread, suggest that "on the right" was the best
>      option twenty years ago, and it is now even more embedded in the learned
>      experience of computing.

Note that in the articles quoted by Chong, no actual research seems to
have been done, and their reasoning isn't particularly compelling: it
comes down to "well, because people use their right hand with the
mouse", and "it reduces visual clutter".

Not obviously _wrong_ of course (you apparently feel the same way about
clutter), but not exactly a slam-dunk either...

-Miles

-- 
Americans are broad-minded people.  They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
a man doesn't drive, there is something wrong with him.  -- Art Buchwald

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Yavor Doganov]

Chong Yidong wrote:
> Every graphical user interface created in the last X years puts the
> scroll bar on the right.

Not true -- on GNUstep it is by default on the left (although it can
be controlled via the NSScrollViewInterfaceStyle user default which
was implemented at least 3-4 years ago).

David Kastrup wrote:
> But the scrollbar is on the left for a reason: _if_ you use the mouse
> for editing, you'll use it more often than not on the left (until Eli's
> work gets merged).  And the larger the windows are made horizontally,
> the more of a nuisance it is to move the mouse.

This makes sense to me.  I suspect that's one of the reasons why NeXT
made such decision.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

Yavor Doganov <yavor@gnu.org> writes:

> Chong Yidong wrote:
>> Every graphical user interface created in the last X years puts the
>> scroll bar on the right.
>
> Not true -- on GNUstep it is by default on the left (although it can
> be controlled via the NSScrollViewInterfaceStyle user default which
> was implemented at least 3-4 years ago).

GnuStep is the benchmark? Sheesh ...

>
> David Kastrup wrote:
>> But the scrollbar is on the left for a reason: _if_ you use the mouse
>> for editing, you'll use it more often than not on the left (until Eli's
>> work gets merged).  And the larger the windows are made horizontally,
>> the more of a nuisance it is to move the mouse.
>
> This makes sense to me.  I suspect that's one of the reasons why NeXT
> made such decision.
>

It makes no sense to me. Most people I watch, and myself, position the
mouse on the right hand side of something in which we freetype. The only
time I would use a mouse in emacs would be to hilite a url maybe or to
move the scroll bar and it makes far more sense for that to be on the
right.

Still, if GnuStep has it on the left, well, ....

For me the real reason is this : I read and write left to write. I dont
want a chunk of the left hand side of my screen taken by a control I
rarely use. It seems so obvious that I kind of wonder if I am losing the
plot here and missing something so terribly obvious. But trawling back
through the thread all I see to counter this and obvious consistency
benefits is that GnuStep does it on the left (with dus respect almost
nothing uses GnuStep) and that it minimises mouse movement in an
application that is primarily keyboard driven and then ONLY if the mouse
is on the left to start with. I'm at a loss to see how those "for the
left" think it any way balances out.

Still, clearly there are a core element who feel the left is somehow the
place and I suspect the decision is made. There's probably not more to
add - and thanks for the discussion. Emacs is a wonderful product.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

Richard Riley <rileyrgdev@gmail.com> writes:

> Yavor Doganov <yavor@gnu.org> writes:
>
>> Chong Yidong wrote:
>>> Every graphical user interface created in the last X years puts the
>>> scroll bar on the right.
>>
>> Not true -- on GNUstep it is by default on the left (although it can
>> be controlled via the NSScrollViewInterfaceStyle user default which
>> was implemented at least 3-4 years ago).
>
> GnuStep is the benchmark? Sheesh ...

Anything is the benchmark if a statement about "Every graphical user
interface" is made.

>> David Kastrup wrote:
>>> But the scrollbar is on the left for a reason: _if_ you use the
>>> mouse for editing, you'll use it more often than not on the left
>>> (until Eli's work gets merged).  And the larger the windows are made
>>> horizontally, the more of a nuisance it is to move the mouse.
>>
>> This makes sense to me.  I suspect that's one of the reasons why NeXT
>> made such decision.
>
> It makes no sense to me.

Then you should reread it until it does.  You'll be better equipped to
weigh the relative advantages when you understand your opponents'
position.

> Most people I watch, and myself, position the mouse on the right hand
> side of something in which we freetype. The only time I would use a
> mouse in emacs would be to hilite a url maybe or to move the scroll
> bar and it makes far more sense for that to be on the right.

Are URLs more often than not on the right?  Does your text move only to
the right?

As I already explained: with the variable-height scrolling control of
Athena-style scrollbars (by the way: for Xaw applications like xterm,
xman, xmessage, the default is consistently on the left), it is
important to have the scrollbar close to the text in order to do aimed
scrolling.  It is very easy with this scrollbar type, of which the
toolkit-less is one, to move the beginning of a function to the top of
the screen with a single click without losing cursor position.

> For me the real reason is this : I read and write left to write. I dont
> want a chunk of the left hand side of my screen taken by a control I
> rarely use. It seems so obvious that I kind of wonder if I am losing the
> plot here and missing something so terribly obvious.

Have you disabled all window decorations as well?  And the gutter?

And anyway, the scrollbar takes the same amount of space whether left or
right.

> But trawling back through the thread all I see to counter this and
> obvious consistency benefits

There is none.  There is a familiarity benefit.  We don't give them
priority over usability, or we would not be using Emacs in the first
place.

> is that GnuStep does it on the left (with dus respect almost nothing
> uses GnuStep) and that it minimises mouse movement in an application
> that is primarily keyboard driven and then ONLY if the mouse is on the
> left to start with. I'm at a loss to see how those "for the left"
> think it any way balances out.

If there is nothing substantial on the other end of the scale...

> Still, clearly there are a core element who feel the left is somehow
> the place and I suspect the decision is made. There's probably not
> more to add - and thanks for the discussion. Emacs is a wonderful
> product.

I think you overlook that a maintainer already did that change without
even discussing it.  That's what prompted this thread.  So if there is
any "decision" being made, it would be according to your personal
preferences.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Richard Riley]

David Kastrup <dak@gnu.org> writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>
>> Yavor Doganov <yavor@gnu.org> writes:
>>
>>> Chong Yidong wrote:
>>>> Every graphical user interface created in the last X years puts the
>>>> scroll bar on the right.
>>>
>>> Not true -- on GNUstep it is by default on the left (although it can
>>> be controlled via the NSScrollViewInterfaceStyle user default which
>>> was implemented at least 3-4 years ago).
>>
>> GnuStep is the benchmark? Sheesh ...
>
> Anything is the benchmark if a statement about "Every graphical user
> interface" is made.

The benchmark for me is that the majority use. Its that simple. We can
play silly games and point at obscure data as much as we like to win
points.

>
>>> David Kastrup wrote:
>>>> But the scrollbar is on the left for a reason: _if_ you use the
>>>> mouse for editing, you'll use it more often than not on the left
>>>> (until Eli's work gets merged).  And the larger the windows are made
>>>> horizontally, the more of a nuisance it is to move the mouse.
>>>
>>> This makes sense to me.  I suspect that's one of the reasons why NeXT
>>> made such decision.
>>
>> It makes no sense to me.
>
> Then you should reread it until it does.  You'll be better equipped to
> weigh the relative advantages when you understand your opponents'
> position.

Re-reading does not make it make any sense in comparison to other
arguments.

>
>> Most people I watch, and myself, position the mouse on the right hand
>> side of something in which we freetype. The only time I would use a
>> mouse in emacs would be to hilite a url maybe or to move the scroll
>> bar and it makes far more sense for that to be on the right.
>
> Are URLs more often than not on the right?  Does your text move only to
> the right?

Huh? What are you talking about? The point is that its not a very common
thing to do regardless. Like using the mouse to scroll.
>
> As I already explained: with the variable-height scrolling control of
> Athena-style scrollbars (by the way: for Xaw applications like xterm,
> xman, xmessage, the default is consistently on the left), it is
> important to have the scrollbar close to the text in order to do aimed
> scrolling.  It is very easy with this scrollbar type, of which the
> toolkit-less is one, to move the beginning of a function to the top of
> the screen with a single click without losing cursor position.

Yes you did. Although why I'm not sure. That in no way cancels out the
reasons for the bar NOT being on the left.

>
>> For me the real reason is this : I read and write left to write. I dont
>> want a chunk of the left hand side of my screen taken by a control I
>> rarely use. It seems so obvious that I kind of wonder if I am losing the
>> plot here and missing something so terribly obvious.
>
> Have you disabled all window decorations as well?  And the gutter?

Most. I use xmonad.

>
> And anyway, the scrollbar takes the same amount of space whether left or
> right.

Are you purposely missing the point? As you put it -reread until you
understand ;)

The point is that its rarely used a text UI such as emacs. THUS it is
not of benefit to have it "in your face". This is pretty basic UI
design. You do not present rarely used controls with a higher
precedence.

>
>> But trawling back through the thread all I see to counter this and
>> obvious consistency benefits
>
> There is none.  There is a familiarity benefit.  We don't give them
> priority over usability, or we would not be using Emacs in the first
> place.

It doesnt mean you need to pick an obscure and non standard positioning
for a commonly used UI control. And left hand side is non standard and
obscure.


>
>> is that GnuStep does it on the left (with dus respect almost nothing
>> uses GnuStep) and that it minimises mouse movement in an application
>> that is primarily keyboard driven and then ONLY if the mouse is on the
>> left to start with. I'm at a loss to see how those "for the left"
>> think it any way balances out.
>
> If there is nothing substantial on the other end of the scale...
>
>> Still, clearly there are a core element who feel the left is somehow
>> the place and I suspect the decision is made. There's probably not
>> more to add - and thanks for the discussion. Emacs is a wonderful
>> product.
>
> I think you overlook that a maintainer already did that change without
> even discussing it.  That's what prompted this thread.  So if there is
> any "decision" being made, it would be according to your personal
> preferences.

Customising functionality is always good.

I dont want a cat fight and your "re-read tile you" suggestion prompts me to bail
from this thread as your rudeness does not do you justice.

regards,

r.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Stefan Monnier]

Hmmm... the unmistakable smell of the bikeshed.


        Stefan


PS: This discussion can only be religious, because there really is no
rational reason to prefer one over the other.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Lennart Borgman]

On Mon, Mar 15, 2010 at 2:34 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> PS: This discussion can only be religious, because there really is no
> rational reason to prefer one over the other.


There is a lot of rational reasons, but they are small. Not much to
discuss. IMO that means that following the normal conventions is
probably the best.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[David Kastrup]

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

> On Mon, Mar 15, 2010 at 2:34 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>
>> PS: This discussion can only be religious, because there really is no
>> rational reason to prefer one over the other.
>
>
> There is a lot of rational reasons, but they are small. Not much to
> discuss. IMO that means that following the normal conventions is
> probably the best.

So can we please have the default on the left for Athena style widgets
with proportional scrolling, as the left _is_ the _normal_ convention
for applications using them?

The current state, installed without previous discussion, places the
scrollbar _against_ normal conventions for those widgets.

-- 
David Kastrup

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> So can we please have the default on the left for Athena style widgets
> with proportional scrolling, as the left _is_ the _normal_ convention
> for applications using them?

Done.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99650: Put scroll-bar on right by default on UNIX.

[martin rudalics]

 > PS: This discussion can only be religious, because there really is no
 > rational reason to prefer one over the other.

There is: `mouse-avoidance-mode' sends the mouse cursor preferably to
the right upper corner of your window (or in that direction).  So with a
scrollbar on the left you would continuously have to move the mouse
cursor from the far right of your window back to the left where the
scrollbar is.

martin, who is agnostic