FW: commands to select things of different kinds

FW: commands to select things of different kinds

[Drew Adams]

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

Resending -

----
Sent: Sunday, March 09, 2008 9:45 AM
Resending, at Richard's request. 

> From: Richard Stallman Sent: Wednesday, July 18, 2007 1:54 PM
> To: Drew Adams
> 
>     Not really; haven't thought much about it. As I said, 
>     I've been using
>     `C-M-SPC' for `mark-thing' (stealing from `mark-sexp') 
>     and `M-@' for
>     `cycle-thing-region' (stealing from `mark-word').
> 
> Those might be a good replacement, because I would expect people don't
> use those two bindings very much.  But we have to ask people first.

> -----Original Message-----
> From: Drew Adams Sent: Tuesday, July 17, 2007 9:52 PM
> To: rms@gnu.org
> 
> >     > If the region is not yet active, then you are prompted (with
> >     > completion) for the type of thing to select. The default type
> >     > is `sexp'.
> > 
> >     For the first such thing, the region is not active, so you 
> >     are prompted. For subsequent (successive) things, there is
> >     no prompt - the same type is used as the last. When you are
> >     prompted, `sexp' is the default type.
> > 
> > I see.  Maybe it is a good idea.  If people like it, we can 
> install it
> > in Emacs.
> > 
> > Do you have suggested bindings for these two commands?
> 
> Not really; haven't thought much about it. As I said, I've 
> been using `C-M-SPC' for `mark-thing' (stealing from 
> `mark-sexp') and `M-@' for `cycle-thing-region' (stealing 
> from `mark-word'). But, as I also said, I'm not suggesting 
> changing those bindings for Emacs.
> 
> I think these commands are mainly useful for Transient Mark 
> mode, if that helps. Perhaps there are some bindings that 
> normally make less sense in t-m mode, which could therefore 
> be recuperated. I don't know.

> -----Original Message----- 
> From: Drew Adams Sent: Monday, July 16, 2007 12:17 AM
> To: Emacs-Devel
> 
> Any interest in these commands? They let you select (that is, 
> mark) various
> things at or near point. They are most useful in Transient 
> Mark mode - they
> act differently depending on whether the mark is active.
> 
> * `mark-thing' selects successive things, starting at point. 
> The mark is put
> at the same place that command 'forward-'thing would put it 
> (using the same
> prefix argument). If the region is not yet active, then you 
> are prompted
> (with completion) for the type of thing to select. The default type is
> `sexp'.
> 
> * `cycle-thing-region' selects one thing at or near point 
> (just the thing,
> not from point through the thing, even if the thing is not exactly at
> point). Repeat it to cycle among the thing types - one thing 
> of the current
> type is selected at each invocation. The default order of 
> types is `word',
> `sexp', `list', `line', `sentence', `paragraph', `page', 
> `defun', `number',
> `form'. That order is customizable, and a major mode could 
> also change it to
> put the most commonly used types first.
> 
> I bind `mark-thing' to `C-M-SPC' as a replacement for `mark-sexp'.
> 
> I bind `cycle-thing-region' to `M-@' as a replacement for 
> `mark-word'. (By
> default, it does what `mark-word' does without a prefix arg. Unlike,
> `mark-thing', however, `cycle-thing-region' does not accept a 
> prefix arg.)
> 
> I don't propose these bindings for Emacs generally, but if you use
> transient-mark mode you might want to give them a try.
> 
> To select successive things in transient-mark mode, you can use
> `cycle-thing-region' as an alternative to completion for 
> choosing the thing
> type for `mark-thing' - but you need to use `C-x C-x' between 
> the two. That
> is, you can use 'M-@ C-x C-x C-M-SPC' to select successive 
> words, 'M-@ M-@
> C-x C-x C-M-SPC' for successive symbols, and so on.
> 
> The code is attached.



[-- Attachment #2: thing-cmds.el --]
[-- Type: application/octet-stream, Size: 8042 bytes --]

;;; thing-cmds.el --- Commands that use things, as defined by `thingatpt.el'.
;; 
;; Filename: thing-cmds.el
;; Description: Commands that use things, as defined by `thingatpt.el'.
;; Author: Drew Adams
;; Maintainer: Drew Adams
;; Copyright (C) 2006-2007, Drew Adams, all rights reserved.
;; Created: Sun Jul 30 16:40:29 2006
;; Version: 20.1
;; Last-Updated: Sun Jul 15 23:58:11 2007 (-25200 Pacific Daylight Time)
;;           By: dradams
;;     Update #: 41
;; URL: http://www.emacswiki.org/cgi-bin/wiki/thing-cmds.el
;; Keywords: thingatpt, thing, region, selection
;; Compatibility: GNU Emacs 20.x, GNU Emacs 21.x, GNU Emacs 22.x
;; 
;; Features that might be required by this library:
;;
;;   `thingatpt', `thingatpt+'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;;; Commentary:
;;
;;  You can use the commands defined here to select different kinds of
;;  text entities ("things").  They are especially useful in
;;  combination with Transient Mark mode.
;; 
;;  Commands defined here:
;;
;;    `cycle-thing-region', `mark-thing', `select-thing-near-point',
;;    `thing-region'.
;;
;;  User options defined here:
;;
;;    `thing-types'.
;;
;;  Internal variables defined here:
;;
;;    `mark-thing-type', `thing-region-index'.
;;
;;  Put this in your init file (`~/.emacs'): (require 'thing-cmds)
;;
;;  Suggested key bindings (these will replace the standard bindings
;;  for `mark-sexp' and `mark-word'):
;;
;;  (global-set-key [(control meta ? )] 'mark-thing) ; vs `mark-sexp'
;;  (global-set-key [(meta ?@)] 'cycle-thing-region) ; vs `mark-word'
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;;; Change log:
;;
;; 2007/07/15 dadams
;;     Added cycle-thing-region-point.
;;     cycle-thing-region: Save point in cycle-thing-region-point and reuse it.
;; 2006/07/30 dadams
;;     Created.
;; 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 2, or
;; (at your option) any later version.
;; 
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;; 
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;; 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 
;;; Code:

(require 'thingatpt+ nil t) ;; (no error if not found): bounds-of-thing-at-point
(require 'thingatpt) ;; bounds-of-thing-at-point

(when (< emacs-major-version 20) (eval-when-compile (require 'cl))) ;; when, unless

;;;;;;;;;;;;;;;;;;;;;;;;

(defun thing-region (thing)
  "Set the region around a THING near the cursor.
You are prompted for the type of thing.  Completion is available for
some standard types of thing, but you can enter any type.
The cursor is placed at the end of the region.  You can return it to
the original location by using `C-u C-SPC' twice."
  (interactive (list (let ((icicle-sort-function nil))
                       (completing-read "Type of thing: " (mapcar #'list thing-types)
                                        nil nil nil nil "sexp"))))
  (let* ((bds (if (fboundp 'bounds-of-thing-nearest-point) ; In `thingatpt+.el'.
                  (bounds-of-thing-nearest-point (intern thing))
                (bounds-of-thing-at-point (intern thing))))
         (start (car bds))
         (end (cdr bds)))
    (cond ((and start end)
           (push-mark (point) t)        ; Mark position, so can use `C-u C-SPC'.
           (goto-char end)
           (push-mark start t 'activate)
           (setq deactivate-mark nil)
           thing)                       ; Return thing.
          (t
           (message "No `%s' near point" thing)
           (setq deactivate-mark nil)
           nil))))                      ; Return nil: no thing found.

(defalias 'select-thing-near-point 'cycle-thing-region)
(defun cycle-thing-region ()
  "Select a thing near point.  Successive uses select different things.
In Transient Mark mode, you can follow this with `\\[mark-thing]' to select
successive things of the same type, but to do that you must first use
`C-x C-x': `\\[cycle-thing-region] C-x C-x \\[mark-thing]'"
  (interactive)
  (if (eq last-command this-command)
      (goto-char cycle-thing-region-point)
    (setq thing-region-index 0)
    (setq cycle-thing-region-point (point)))
  (let* ((thing (elt thing-types thing-region-index))
         (success (thing-region thing)))
    (setq thing-region-index (1+ thing-region-index))
    (when success
      (setq mark-thing-type (intern thing)) ; Save it for `mark-thing'.
      (message "%s" (capitalize (elt thing-types (1- thing-region-index)))))
    (when (>= thing-region-index (length thing-types)) (setq thing-region-index 0))))

(defcustom thing-types '("word" "symbol" "sexp" "list" "line" "sentence"
                         "paragraph" "page" "defun" "number" "form")
  "List of thing types.  Used for completion and `cycle-thing-region'.
Each element is a string that names a type of text entity for which
there is a either a corresponding `forward-'thing operation, or
corresponding `beginning-of-'thing and `end-of-'thing operations.
Examples include \"word\", \"sentence\", and \"defun\"."
  :type '(repeat string))

(defvar thing-region-index 0 "Index of current thing in `thing-types'.")

(defvar mark-thing-type nil "Current thing type used by `mark-thing'.")

(defvar cycle-thing-region-point nil
  "Position of point before `cycle-thing-region'.")

(defun mark-thing (thing &optional arg allow-extend)
  "Set the mark ARG THINGs from point.
THING is a string that names a type of thing: \"word\", \"sexp\", and
so on.  See option `thing-types' for more examples.

The mark is put at the same place command `forward-'THING would put it
with the same prefix argument.

If the prefix argument (ARG) is negative, then point is put at the end
of the THING, amd mark is put at the beginning of the THING or a
previous THING.

Interactively:

You are prompted for THING.  Completion is available for the types of
thing in `thing-types', but you can enter any type.

If `mark-thing' is repeated or if the mark is active (in Transient
Mark mode), then it marks the next ARG THINGs, after the ones already
marked."
  (interactive "i\nP\np")               ; THING arg is nil (ignored) interactively.
  (cond ((and allow-extend (or (and (eq last-command this-command) (mark t))
                               (and transient-mark-mode mark-active)))
	 (setq arg (if arg
                       (prefix-numeric-value arg)
		     (if (< (mark) (point)) -1 1)))
	 (set-mark (save-excursion
                     (goto-char (mark))
                     (forward-thing mark-thing-type arg)
                     (point))))
	(t
         (setq mark-thing-type
               (or thing (intern (let ((icicle-sort-function nil))
                                   (completing-read "Type of thing: "
                                                    (mapcar #'list thing-types)
                                                    nil nil nil nil "sexp")))))
	 (push-mark (save-excursion
                      (forward-thing mark-thing-type (prefix-numeric-value arg))
                      (point))
                    nil t)))
  (setq deactivate-mark nil))

;;;;;;;;;;;;;;;;;;;;;;;;

(provide 'thing-cmds)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; thing-cmds.el ends here

Re: FW: commands to select things of different kinds

[Stefan Monnier]

>> Not really; haven't thought much about it. As I said, 
>> I've been using
>> `C-M-SPC' for `mark-thing' (stealing from `mark-sexp') 
>> and `M-@' for
>> `cycle-thing-region' (stealing from `mark-word').
>> 
>> Those might be a good replacement, because I would expect people don't
>> use those two bindings very much.  But we have to ask people first.

I use C-M-SPC *very* often, typically just before C-y (together with
a variant of delete-selection-mode).
That doesn't mean it can't be changed, but its current functionality
should still be at least somewhat preserved.


        Stefan

Re: FW: commands to select things of different kinds

[Juri Linkov]

> I use C-M-SPC *very* often, typically just before C-y (together with
> a variant of delete-selection-mode).

BTW, since now shift-selection is available by default, I think we should
enable delete-selection-mode, because otherwise it is very confusing
for users coming from other programs to discover the weird behavior
of transient-mark-mode when delete-selection-mode is disabled.

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

Re: FW: commands to select things of different kinds

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> I use C-M-SPC *very* often, typically just before C-y (together with
>> a variant of delete-selection-mode).
>
> BTW, since now shift-selection is available by default, I think we should
> enable delete-selection-mode, because otherwise it is very confusing
> for users coming from other programs to discover the weird behavior
> of transient-mark-mode when delete-selection-mode is disabled.

No.  I am already getting surprise region activations with the current
settings.  Getting it erased by surprise is not what I consider fun.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

delete-selection-mode (was: FW: commands to select things of different kinds)

[Juri Linkov]

>>> I use C-M-SPC *very* often, typically just before C-y (together with
>>> a variant of delete-selection-mode).
>>
>> BTW, since now shift-selection is available by default, I think we should
>> enable delete-selection-mode, because otherwise it is very confusing
>> for users coming from other programs to discover the weird behavior
>> of transient-mark-mode when delete-selection-mode is disabled.
>
> No.  I am already getting surprise region activations with the current
> settings.  Getting it erased by surprise is not what I consider fun.

I already know that you don't like transient-mark-mode.  So the only
option for you is to disable transient-mark-mode completely.

What I meant is that when the region is active in transient-mark-mode
typing a character that doesn't delete the region is not only useless
but also looks like a bug to users of any program other than Emacs.

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

RE: FW: commands to select things of different kinds

[Drew Adams]

> > I use C-M-SPC *very* often, typically just before C-y (together with
> > a variant of delete-selection-mode).
>
> BTW, since now shift-selection is available by default, I 
> think we should
> enable delete-selection-mode, because otherwise it is very confusing
> for users coming from other programs to discover the weird behavior
> of transient-mark-mode when delete-selection-mode is disabled.

Here we go again...

Can you please start a different thread for that?

This thread is _not at all_ about whether delete-selection-mode or t-m-mode
should be enabled by default.

This thread is about some proposed commands that let you mark various things at
or near point. 

And which keys might be bound to those commands is a secondary consideration,
relevant only if the commands are accepted. There is nothing in the proposal
about using C-M-SPC or any other keys, in particular. It's about the commands.
If the commands are accepted, then we can argue endlessly about which keys, if
any, to bind to them.

Re: FW: commands to select things of different kinds

[Juri Linkov]

> This thread is about some proposed commands that let you mark various
> things at or near point.
>
> And which keys might be bound to those commands is a secondary consideration,
> relevant only if the commands are accepted. There is nothing in the proposal
> about using C-M-SPC or any other keys, in particular. It's about the commands.
> If the commands are accepted, then we can argue endlessly about which keys, if
> any, to bind to them.

Generally I like your proposed commands to select things, but I think
C-M-SPC is an inappropriate key binding.  Sorry, I can't propose another key
to bind these commands now.

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

Re: FW: commands to select things of different kinds

[Richard Stallman]

I am very much against enabling delete-selection-mode by default.

RE: FW: commands to select things of different kinds

[Drew Adams]

> > This thread is about some proposed commands that let you 
> > mark various things at or near point.
> >
> > And which keys might be bound to those commands is a 
> > secondary consideration, relevant only if the commands
> > are accepted. There is nothing in the proposal about
> > using C-M-SPC or any other keys, in particular. It's 
> > about the commands. If the commands are accepted, then
> > we can argue endlessly about which keys, if any, to
> > bind to them.
> 
> Generally I like your proposed commands to select things, but I
> think C-M-SPC is an inappropriate key binding.  Sorry, I can't 
> propose another key to bind these commands now.

Let's not worry about the keys until people agree to adding the commands. If
they don't agree, then we can save the time and hassle of looking for
appropriate keys.

delete-selection-mode (was: FW: commands to select things of different kinds)

[Juri Linkov]

> I am very much against enabling delete-selection-mode by default.

I am very surprised.  What could be a reason not to delete the region
after typing a character when this region was intentionally activated
specially for doing this.

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

Re: delete-selection-mode (was: FW: commands to select things of different kinds)

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

>> I am very much against enabling delete-selection-mode by default.
>
> I am very surprised.  What could be a reason not to delete the region
> after typing a character when this region was intentionally activated
> specially for doing this.

This is why I was very much against enabling shift-select mode by default
without also enabling delete-selection-mode by default.

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

Re: delete-selection-mode

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>>> I use C-M-SPC *very* often, typically just before C-y (together with
>>>> a variant of delete-selection-mode).
>>>
>>> BTW, since now shift-selection is available by default, I think we should
>>> enable delete-selection-mode, because otherwise it is very confusing
>>> for users coming from other programs to discover the weird behavior
>>> of transient-mark-mode when delete-selection-mode is disabled.
>>
>> No.  I am already getting surprise region activations with the current
>> settings.  Getting it erased by surprise is not what I consider fun.
>
> I already know that you don't like transient-mark-mode.  So the only
> option for you is to disable transient-mark-mode completely.

Sorry, but that does not fly.  We are talking about the default settings
of Emacs here.  Enabling transient-mark-mode by default gives us an
active region for all mark-* commands as well as C-x C-x.  So an active
region has become a much more common occurence in the normal workflow
than previously.  Making this region inactive requires C-g (a command
that has no equivalent whatsoever in CUA that would also work in Emacs).
So after a region became active, it is, for the average user, almost
impossible to avoid deleting it if we have delete-selection-mode active.

This is not good enough.  If a normal workflow more or less necessitates
shooting yourself in the foot, even if this workflow is somewhat similar
to "CUA" or "everybody else", then the solution is not to punch people
in the mouth who don't use CUA or accustomed to it.

The solution is to create a useful and consistent workflow that does
minimal unintended damage.  And CUA/transient-mark-mode is not there yet
where delete-selection-mode would fit in.

> What I meant is that when the region is active in transient-mark-mode
> typing a character that doesn't delete the region is not only useless
> but also looks like a bug to users of any program other than Emacs.

Not having a useful way to type a character that doesn't delete the
region (when activating the region is something which happens
unintentionally for some workloads and can't be undone without, say,
beeping and/or flashing all over the workplace, the normal reaction to
C-g) is a bug in user interface design.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 20 Apr 2008 02:43:36 +0300
> Cc: monnier@iro.umontreal.ca, drew.adams@oracle.com, emacs-devel@gnu.org
> 
> > I am very much against enabling delete-selection-mode by default.
> 
> I am very surprised.  What could be a reason not to delete the region
> after typing a character when this region was intentionally activated
> specially for doing this.

If the region activates as a side effect of otherwise innocent
commands, such as M-> or C-s or C-x C-x, then I'd object deleting it
as well.  Even if I explicitly mark the region with C-SPC followed by
cursor motion commands, it does not yet mean I'm about to replace it
with another text.  I might just want to M-w it or something.  Imagine
typing some self-inserting key by mistake in this situation, for
example.

IOW, the problem is that in Emacs a region is used and created by many
commands that are not available in other GUI apps, or if they are
available, they don't paint the marked text.

I sincerely hope that I'm missing something very important (because I
didn't follow the discussions about this until now), because otherwise
I fear the UI of Emacs 23 will simply be unbearable for newcomers and
veterans alike.

Re: delete-selection-mode

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> I am very much against enabling delete-selection-mode by default.
>
> I am very surprised.  What could be a reason not to delete the region
> after typing a character when this region was intentionally activated
> specially for doing this.

It seems to me that delete-selection-mode doesn't mesh very well with
the Emacs paradigm of killing/yanking text.  When a region is active,
typing something replaces the text but doesn't save it on the kill-ring,
which can be disconcerting.  I know it's possible to change this so that
the replaced text goes onto the kill-ring, but that behavior doesn't
"feel" right either; for one thing, it's incompatible with the
delete-selection behavior of other programs.

All thinks considered, IMHO the present behavior, where delete-selection
is off, is a better default.

Re: delete-selection-mode

[Stefan Monnier]

> All thinks considered, IMHO the present behavior, where delete-selection
> is off, is a better default.

Agreed.  In my message I referred to using a form of
delete-selection-mode, but that's a very limited form of it: it only
applies to `yank'.  I like it because it allows me to do C-M-SPC C-y to
replace an argument.


        Stefan


PS: We have had another limited form of delete-selection-mode enabled by
default for a long time know, in the form of `mouse-region-delete-keys'.
The code used to implement this feature is quite problematic, tho, and
I'd be happy if someone could use a more robust solution (or we could
just remove that feature, which I always found to be unconvincing:
people who like it will probably prefer to enable delete-selection-mode
anyway).

Re: delete-selection-mode

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Sun, Apr 20, 2008 at 02:43:36AM +0300, Juri Linkov wrote:
>> > I am very much against enabling delete-selection-mode by default.
>
>> I am very surprised.  What could be a reason not to delete the region
>> after typing a character when this region was intentionally activated
>> specially for doing this.

[...]

> Anyways....  the main point of my email: this discussion comes into
> the category of "things decided long ago, whose discussion now
> consumes our time and energy".  RMS requested very recently that we
> cease such discussion.  I've got bugs to fix.

Huh?  transient-mark-mode was made the default only very recently, and
without that, there could not have been much talk about the
delete-selection-mode default?

So the topic would to me appear rather new.  And the right answer is
"no"...  It might be "not yet", but at the current point of time I have
no idea what could be done to make a change not quite painful for all
users (not just the old fogies).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Dan Nicolaescu]

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

  > > All thinks considered, IMHO the present behavior, where delete-selection
  > > is off, is a better default.
  > 
  > Agreed.  In my message I referred to using a form of
  > delete-selection-mode, but that's a very limited form of it: it only
  > applies to `yank'.  I like it because it allows me to do C-M-SPC C-y to
  > replace an argument.

How about we do a user poll about this?  
That seems to be a better way of deciding a default for such a very
visible feature.

Re: delete-selection-mode

[David Kastrup]

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

> PS: We have had another limited form of delete-selection-mode enabled
> by default for a long time know, in the form of
> `mouse-region-delete-keys'.  The code used to implement this feature
> is quite problematic, tho, and I'd be happy if someone could use a
> more robust solution (or we could just remove that feature, which I
> always found to be unconvincing: people who like it will probably
> prefer to enable delete-selection-mode anyway).

Not me: I use this from time to time, but delete-selection-mode is too
intrusive for me.

Given that just right clicking twice will achieve the same thing, my
normal use case is when the mouse already went somewhere else and/or I
have returned back to the keyboard before deciding I want to delete the
marked stuff after all.

So it is not a feature I'd miss a whole lot.  But I do use it
occasionally, and I abhor delete-selection-mode.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode (was: FW: commands to select things of different kinds)

[Alan Mackenzie]

'Evening, Juri!

On Sun, Apr 20, 2008 at 02:43:36AM +0300, Juri Linkov wrote:
> > I am very much against enabling delete-selection-mode by default.

> I am very surprised.  What could be a reason not to delete the region
> after typing a character when this region was intentionally activated
> specially for doing this.

None whatsoever.  However, by what mechanism can Emacs determine that
deletion was, in fact, the reason the region was "activated", rather
than a wish to save the region for future yanking, to capitalise all the
letters in it, to narrow to it, or to do any of the other infinite
things that regions are for?

That a letter be typed after activating a region in no way signifies the
user wanted to lose the region.  Often, she'll have just forgotten to
pacify it.

Anyways....  the main point of my email: this discussion comes into the
category of "things decided long ago, whose discussion now consumes our
time and energy".  RMS requested very recently that we cease such
discussion.  I've got bugs to fix.

Cheers!

> Juri Linkov

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode

[David Kastrup]

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

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>   > > All thinks considered, IMHO the present behavior, where delete-selection
>   > > is off, is a better default.
>   > 
>   > Agreed.  In my message I referred to using a form of
>   > delete-selection-mode, but that's a very limited form of it: it only
>   > applies to `yank'.  I like it because it allows me to do C-M-SPC C-y to
>   > replace an argument.
>
> How about we do a user poll about this?  
> That seems to be a better way of deciding a default for such a very
> visible feature.

It is sort of a popular democratic sickness that people think they are
achieving anything by choosing between two existing bad things instead
of improving either one.

With the current semantics of active regions and delete-selection-mode,
I consider the end result painful.  That does not change that it may
also be in some cases be useful.

Polling users and/or setting the default means one gives up on the idea
to have something that is useful while not being painful.

Does really nobody have an idea how to improve the situation?  Maybe
generalize mouse-deletion-mode (or what it is called) somewhat: I think
that I could tolerate an active region being deleted by typing DEL.

Now that transient-mark-mode is the default and that mouse-marking makes
an active region anyway, this might make for a more consistent user
interface without being too much of an annoyance.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Lennart Borgman (gmail)]

David Kastrup wrote:
> With the current semantics of active regions and delete-selection-mode,
> I consider the end result painful.  That does not change that it may
> also be in some cases be useful.
> 
> Does really nobody have an idea how to improve the situation?

Do I understand you right when I assume that the painful thing for old 
users would be that typing new text would delete the selection?

Many new users expects this. They also expect that you can undo that 
change with some undo command (which I think they expect to by C-z). Is 
that possible now?

If the default will be that typing new text replaces the visible region 
then maybe there should be a substate where it is possible to type in 
new text while the region is visible? One way this could be done is to 
let C-x C-x go into that substate (in addition to doing what it does now).

Would that be to inconvinient?

Re: delete-selection-mode

[David Kastrup]

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

> David Kastrup wrote:
>> With the current semantics of active regions and delete-selection-mode,
>> I consider the end result painful.  That does not change that it may
>> also be in some cases be useful.
>>
>> Does really nobody have an idea how to improve the situation?
>
> Do I understand you right when I assume that the painful thing for old
> users would be that typing new text would delete the selection?
>
> Many new users expects this.

Not when they are not expecting an active region in the first place.
There are more ways to make a region active than the explicit ways that
a "new user expects".

> If the default will be that typing new text replaces the visible
> region then maybe there should be a substate where it is possible to
> type in new text while the region is visible? One way this could be
> done is to let C-x C-x go into that substate (in addition to doing
> what it does now).
>
> Would that be to inconvinient?

It sounds messy.  We already have too many different region states.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> David Kastrup wrote:
>>> With the current semantics of active regions and delete-selection-mode,
>>> I consider the end result painful.  That does not change that it may
>>> also be in some cases be useful.
>>>
>>> Does really nobody have an idea how to improve the situation?
>> Do I understand you right when I assume that the painful thing for old
>> users would be that typing new text would delete the selection?
>>
>> Many new users expects this.
> 
> Not when they are not expecting an active region in the first place.
> There are more ways to make a region active than the explicit ways that
> a "new user expects".

Why does that matter? Are we not talking about a visibly marked region?


>> If the default will be that typing new text replaces the visible
>> region then maybe there should be a substate where it is possible to
>> type in new text while the region is visible? One way this could be
>> done is to let C-x C-x go into that substate (in addition to doing
>> what it does now).
>>
>> Would that be to inconvinient?
> 
> It sounds messy.  We already have too many different region states.

But the wish to make this work for both new and old users call for a new 
state, right?

RE: delete-selection-mode

[Drew Adams]

> Does really nobody have an idea how to improve the situation?  Maybe
> generalize mouse-deletion-mode (or what it is called) somewhat: I think
> that I could tolerate an active region being deleted by typing DEL.

I shudder to post on this topic, especially replying to you, David, but here
goes. ;-) This is not an argument for choosing delete-selection-mode as the
default behavior. It's a reply to your request for ideas for improvement.

How about starting with delete-selection-mode (regardless of whether it would
become the default behavior - let's assume not, here), and trying to improve it
so that it plays better with your use cases?

For example, you say that you don't want to delete the active region sometimes
when you type text. Never? Sometimes? When? Maybe you can characterize the use
cases better (to yourself at least).

The delsel.el code might already provide some of the infrastructure for the
improvements that would make it useful for you; I don't know. There is, for
example, the ability to classify commands wrt their delete-selection-mode
behavior (kill, yank, supersede, delete (t)) - the `delete-selection' property.

This is pretty rudimentary currently. It might be one thing that could be
tweaked - either by further classifying certain commands where you don't want
the region deleted/replaced, or perhaps by adding more behavior types (besides
kill, yank, etc.). Perhaps not just the current command but other parts of the
current context and history could also usefully be taken into account.

Dunno if it would help, but you might thus want to start with delsel, and
improve it so it's not so obnoxious in your use cases. The code is short and
simple. It could be a good place to improve things.

Of course, "improve" is in the eye of the beholder. But I suspect that by
characterizing your use cases and making the code respond better to them, we
might even end up reducing the thrashing about preferred behavior, instead of
increasing it. Call me an optimist. :-)

Unlike the case of CUA selection and CUA mode, where one explicit goal is to
stay very close to what non-Emacs users are used to, I think that improving
delete-selection mode might just provide us the opportunity to come up with
something great - something that is not only good for Emacs users of different
habits but also much better than anything else out there. Call me a dreamer.

On the default-behavior question, I'd say that we should consider the decision
still open for future discussion. Whatever the current behavior is, I don't
think we've come as close to a fix point as we can or need to. Which default
behavior to use while the discussion goes on, I don't really care.

I agree with David that we should try to see if we can't improve on the current
alternatives a bit. That means discussing different use cases and things that
bother us about each current alternative. That's frustrating as hell, granted,
but if we take David's tack of looking to improvement of our options instead of
just trying to sell each other on our current preference, we might just move the
schmilblick forward a bit.

Re: delete-selection-mode

[David Kastrup]

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

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> David Kastrup wrote:
>>>> With the current semantics of active regions and delete-selection-mode,
>>>> I consider the end result painful.  That does not change that it may
>>>> also be in some cases be useful.
>>>>
>>>> Does really nobody have an idea how to improve the situation?
>>> Do I understand you right when I assume that the painful thing for old
>>> users would be that typing new text would delete the selection?
>>>
>>> Many new users expects this.
>>
>> Not when they are not expecting an active region in the first place.
>> There are more ways to make a region active than the explicit ways that
>> a "new user expects".
>
> Why does that matter? Are we not talking about a visibly marked
> region?

Not everybody searches the screen for tell-tale signs of an active
region before typing any letter.

>>> If the default will be that typing new text replaces the visible
>>> region then maybe there should be a substate where it is possible to
>>> type in new text while the region is visible? One way this could be
>>> done is to let C-x C-x go into that substate (in addition to doing
>>> what it does now).
>>>
>>> Would that be to inconvinient?
>>
>> It sounds messy.  We already have too many different region states.
>
> But the wish to make this work for both new and old users call for a
> new state, right?

Wrong.  I already proposed folding mouse-activated-deletion mode into
transient regions which would make for one less state, and provide a
somewhat less contentious part of delete-selection-mode.

Is there a reason you are ignoring that particular proposal?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Jason Rumney]

David Kastrup wrote:
> So the topic would to me appear rather new.  And the right answer is
> "no"...  It might be "not yet", but at the current point of time I have
> no idea what could be done to make a change not quite painful for all
> users (not just the old fogies).
>   

I think delete-selection-mode (and maybe even transient-mark-mode) 
should be enabled only when the region was marked using shift movement keys.
Setting the mark with C-SPC, moving the cursor and typing a self-insert 
character should definitely not delete the region by default, even if 
the region is active and highlighted.

Re: delete-selection-mode

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 20 Apr 2008 14:06:05 -0700
> Cc: 'Juri Linkov' <juri@jurta.org>, 'Chong Yidong' <cyd@stupidchicken.com>,
> 	emacs-devel@gnu.org, 'Stefan Monnier' <monnier@iro.umontreal.ca>,
> 	rms@gnu.org
> 
> How about starting with delete-selection-mode (regardless of whether it would
> become the default behavior - let's assume not, here), and trying to improve it
> so that it plays better with your use cases?

I think the only way to have the feature and leave everyone mildly
happy is to separate the ``deletable'' selection from the normal Emacs
region.  That is, introduce a new notion, let's call it ``selection'',
that is a portion of text which is defined by dragging the mouse or
moving the cursor with the Shift key pressed.  Let then this
``selection'' be deleted as in other GUI apps.  This is what newcomers
expect, they don't know about the region, so won't expect it to behave
like ``selection''.

Keeping our hands off the region will avoid the risk of infuriating
long time Emacs users.  It will also avoid the need to produce some
kind of heuristics for figuring out issues like this one:

> For example, you say that you don't want to delete the active region sometimes
> when you type text. Never? Sometimes? When? Maybe you can characterize the use
> cases better (to yourself at least).

I feel that any such heuristics, even if we succeed in coming up with
it, will be a hopelessly fragile pile of twisted little passages all
alike, that will break on us all the time and cause infinite
maintenance headaches.

Re: delete-selection-mode

[Lennart Borgman (gmail)]

David Kastrup wrote:
>>>> Many new users expects this.
>>> Not when they are not expecting an active region in the first place.
>>> There are more ways to make a region active than the explicit ways that
>>> a "new user expects".
>> Why does that matter? Are we not talking about a visibly marked
>> region?
> 
> Not everybody searches the screen for tell-tale signs of an active
> region before typing any letter.

Yes, I know some long time Emacs users works this way (and that is 
understandable since the regions was not visibly marked before by 
default), but we are talking about the new users here.

>>>> If the default will be that typing new text replaces the visible
>>>> region then maybe there should be a substate where it is possible to
>>>> type in new text while the region is visible? One way this could be
>>>> done is to let C-x C-x go into that substate (in addition to doing
>>>> what it does now).
>>>>
>>>> Would that be to inconvinient?
>>> It sounds messy.  We already have too many different region states.
>> But the wish to make this work for both new and old users call for a
>> new state, right?
> 
> Wrong.  I already proposed folding mouse-activated-deletion mode into
> transient regions which would make for one less state, and provide a
> somewhat less contentious part of delete-selection-mode.
> 
> Is there a reason you are ignoring that particular proposal?

Yes, I am not using the mouse if I can avoid it ;-)

It was not my intention to ignore it of course. However rereading what 
you wrote I see that you said that there is no way for the average (new) 
user to deactivate the region. He/she can use the arrow keys without shift.

Anyway I think Jason's suggestion to use C-SPC is much better than my 
suggestion.

Re: delete-selection-mode

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> David Kastrup wrote:
>> So the topic would to me appear rather new.  And the right answer is
>> "no"...  It might be "not yet", but at the current point of time I have
>> no idea what could be done to make a change not quite painful for all
>> users (not just the old fogies).
>>   
> 
> I think delete-selection-mode (and maybe even transient-mark-mode) 
> should be enabled only when the region was marked using shift movement 
> keys.
> Setting the mark with C-SPC, moving the cursor and typing a self-insert 
> character should definitely not delete the region by default, even if 
> the region is active and highlighted.


I think this is a good suggestion.

RE: delete-selection-mode

[Drew Adams]

> > How about starting with delete-selection-mode (regardless 
> > of whether it would become the default behavior - let's
> > assume not, here), and trying to improve it
> > so that it plays better with your use cases?
> 
> I think the only way to have the feature and leave everyone mildly
> happy is to separate the ``deletable'' selection from the normal Emacs
> region.  That is, introduce a new notion, let's call it ``selection'',
> that is a portion of text which is defined by dragging the mouse or
> moving the cursor with the Shift key pressed.  Let then this
> ``selection'' be deleted as in other GUI apps.  This is what newcomers
> expect, they don't know about the region, so won't expect it to behave
> like ``selection''.
> 
> Keeping our hands off the region will avoid the risk of infuriating
> long time Emacs users.

I'm one such long-time Emacs user. And I'm not so concerned about newcomers and
what they might be used to - we have CUA for that. As I said, this is not about
the default behavior, so no one should feel threatened about imposition. That
question should remain open - we can return to what we had as default in Emacs
21 for all I care.

I'm interested here not in newbie-soothing but in making the alternatives
better, as David suggested. I think that delete-selection mode could become the
basis of something that most Emacs users (including most old-timers) would
prefer.

I think we can do better, but I don't have a concrete suggestion, partly because
I don't have a good feel for the use cases and perceived problems.

FWIW, I would never use a selection such as you describe. That's not what is
available with delete-selection mode. I want to be able, when I want, to use the
_region_ in delete-selection ways: delete or type to replace.

We can determine contexts when that is not desirable, and exclude them. We can
provide user options for customization. The problem, as I see it, is not that
delete-selection deletes or replaces the region. It is that it sometimes does so
when someone doesn't want it to.

To me, the starting point for a superior Emacs notion of active area that is
visible, deletable, killable, and replaceable should be the _region_, because of
all of the other wonderful region properties that Emacs offers. 

I _like_ the fact that delete-selection mode uses the region. I take advantage
of that all the time. That's why I suggest starting with it - it is a concept
and behavior made for Emacs, not for merely respecting some non-Emacs
conventions. I think I understand David's concerns, at least generally, and I
suspect we could address them.

I don't see a fundamental contradiction between the notion of Emacs region and a
behavior of sometimes having the region be deleted or replaced by text that you
type. The problem, as I hear it, is that there are other times when you don't
want that to happen. So let's characterize those patterns.

It's likely that after improving delete-selection mode to take such things into
account, different users will want to use it differently. I might want to have
type-to-replace in some of the contexts where David does not want that. Users
should be able to customize the behavior, obviously. 

But the basic infrastructure is what we should start with and improve first. If
properties on command symbols is too simplistic for the kind of control needed,
then let's discover what we really need and make the infrastructure satisfy it.

> It will also avoid the need to produce some
> kind of heuristics for figuring out issues like this one:
> 
> > For example, you say that you don't want to delete the active
> > region sometimes when you type text. Never? Sometimes? When?
> > Maybe you can characterize the use cases better (to yourself
> > at least).
> 
> I feel that any such heuristics, even if we succeed in coming up with
> it, will be a hopelessly fragile pile of twisted little passages all
> alike, that will break on us all the time and cause infinite
> maintenance headaches.

Such a foreboding prospect - you certainly know how to scare.

It sounds like you're giving up before the first shadow of a characterization
has been attempted, throwing up your hands at the first complaint that
delete-selection mode deleted the region when someone didn't want that.

We have lots of code in Emacs that deals with various contexts or conditions.
It's not as if the delete-selection code was already complex. It's rudimentary.
How do you know that a few healthy tweaks might not take care of the main
problems some people encounter?

I'm the first one to argue against complex DWIM attempts - you've heard me
before about that (quitting view mode, combined behaviors for TAB, etc.) - I am
not a great fan of DWIM. In this case, however, I suspect that there might not
be a lot needed, to take care of the perceived problems. I could be wrong. You,
on the other hand, foresee a nightmare. But how to know without at least trying,
taking a look at the existing code?

Re: FW: commands to select things of different kinds

[Juri Linkov]

>> > This thread is about some proposed commands that let you
>> > mark various things at or near point.
>> >
>> > And which keys might be bound to those commands is a
>> > secondary consideration, relevant only if the commands
>> > are accepted. There is nothing in the proposal about
>> > using C-M-SPC or any other keys, in particular. It's
>> > about the commands. If the commands are accepted, then
>> > we can argue endlessly about which keys, if any, to
>> > bind to them.
>>
>> Generally I like your proposed commands to select things, but I
>> think C-M-SPC is an inappropriate key binding.  Sorry, I can't
>> propose another key to bind these commands now.
>
> Let's not worry about the keys until people agree to adding the commands. If
> they don't agree, then we can save the time and hassle of looking for
> appropriate keys.

I think the proper place to add these new commands is thingatpt.el.

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

RE: delete-selection-mode

[Drew Adams]

> > I think delete-selection-mode (and maybe even transient-mark-mode) 
> > should be enabled only when the region was marked using 
> > shift movement keys.
> 
> I think this is a good suggestion.

I am very much against this suggestion. Screw with mouse-activated-deletion mode
or CUA selection in that way, if you like, or make up something altogether new,
but please don't mess that way with delete-selection mode or
transient-mark-mode. They have nothing to do with shift-selection. They have
everything to do with the Emacs region.

I wasn't in favor of the recent shift-selection "enhancement" to Emacs, and I'm
not in favor of making delete-selection mode depend on using shift and
cursor-movement keys. Quelle horreur !

If you can't or don't want to improve delete-selection mode to make it useful to
people who now find it problematic while still letting others who appreciate its
behavior be able to continue to use it the same way as before, then please just
leave it alone.

This is what comes, I suppose, of the suggestion that it become the default
behavior. We end up with proposals to shoot out its kneecaps. Delete selection
mode is not CUA selection or shift selection. It is not exactly what newbies are
used to, and it shouldn't be made so. Let it be.

RE: FW: commands to select things of different kinds

[Drew Adams]

> >> Generally I like your proposed commands to select things, but I
> >> think C-M-SPC is an inappropriate key binding.  Sorry, I can't
> >> propose another key to bind these commands now.
> >
> > Let's not worry about the keys until people agree to adding 
> > the commands. If they don't agree, then we can save the time
> > and hassle of looking for appropriate keys.
> 
> I think the proper place to add these new commands is thingatpt.el.

Would you please do that then, or do we need more consensus/approval?

Re: delete-selection-mode

[Lennart Borgman (gmail)]

Drew Adams wrote:
> It is not exactly what newbies are
> used to,

What is the difference against what new Emacs users (but experienced 
users) are used to?

Re: delete-selection-mode

[Jason Rumney]

Drew Adams wrote:
> This is what comes, I suppose, of the suggestion that it become the default
> behavior. We end up with proposals to shoot out its kneecaps.
Calm down! I've made no suggestion to change delete-selection-mode 
itself. I am merely offering a suggestion for the circumstances in which 
it might be acceptable, and even desirable to turn it on by default.

> Delete selection
> mode is not CUA selection or shift selection. It is not exactly what newbies are
> used to, and it shouldn't be made so. Let it be.
>   

I don't understand what this difference you are hinting at. What is it 
that you fear will be added to or subtracted from delete-selection-mode 
to make it exactly what is needed here?

Re: FW: commands to select things of different kinds

[Stefan Monnier]

>> Let's not worry about the keys until people agree to adding the commands. If
>> they don't agree, then we can save the time and hassle of looking for
>> appropriate keys.

> I think the proper place to add these new commands is thingatpt.el.

Sounds right.


        Stefan

RE: delete-selection-mode

[Drew Adams]

> Calm down! I've made no suggestion to change delete-selection-mode 
> itself. I am merely offering a suggestion for the 
> circumstances in which it might be acceptable, and even desirable
> to turn it on by default.

I see. I thought you were suggesting to change it. You said it "should be
enabled only when the region was marked using shift movement keys". That is what
I objected to.

I have no objection to adding an _option_ for such a restriction in how it is
enabled. And I don't care about the default value of the option. Just so long as
Emacs users can easily get today's behavior.

> > Delete selection mode is not CUA selection or shift selection.
> > It is not exactly what newbies are
> > used to, and it shouldn't be made so. Let it be.
> 
> I don't understand what this difference you are hinting at. 

The Emacs region. You can define the region in many ways. You can use the region
in many ways. Some commands change their behavior based on an active region.

> What is it that you fear will be added to or subtracted from 
> delete-selection-mode to make it exactly what is needed here?

The region, in its generality.

RE: delete-selection-mode

[Drew Adams]

> > It is not exactly what newbies are used to,
> 
> What is the difference against what new Emacs users (but experienced 
> users) are used to?

The region and the many different ways to define it and use it. Newbies expect
only shift-selection and type to replace/delete.

Re: delete-selection-mode (was: FW: commands to select things of different kinds)

[Richard Stallman]

    > I am very much against enabling delete-selection-mode by default.

    I am very surprised.  What could be a reason not to delete the region
    after typing a character when this region was intentionally activated
    specially for doing this.

If it were indeed limited to cases when the region was intentionally
activated just for that, it would be fine.  But that would mean
reading the user's mind.

Re: delete-selection-mode

[Richard Stallman]

    If the region activates as a side effect of otherwise innocent
    commands, such as M-> or C-s or C-x C-x, then I'd object deleting it
    as well.  Even if I explicitly mark the region with C-SPC followed by
    cursor motion commands, it does not yet mean I'm about to replace it
    with another text.  I might just want to M-w it or something.

Or you might see some characters before point (and outside the region)
and decide to delete them before operating on the region as you
planned to do.

Here's a possible idea: enable delete-selection-mode by default
but only after shift-selection and mouse-selection.

Re: delete-selection-mode

[Thomas Lord]

Richard Stallman wrote:
> Here's a possible idea: enable delete-selection-mode by default
> but only after shift-selection and mouse-selection.
>   

A useful "quasi-quantization" to consider is how many bits of state
a user must keep in mind to accurately predict the dynamically variable
behavior of self-insert-command.  (One is probably pushing it and I
gather that emacs is going well into N>1 territory.   Bummer.)

-t



>
>
>   

Re: delete-selection-mode

[David Kastrup]

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

> David Kastrup wrote:
>>>>> Many new users expects this.
>>>> Not when they are not expecting an active region in the first place.
>>>> There are more ways to make a region active than the explicit ways that
>>>> a "new user expects".
>>> Why does that matter? Are we not talking about a visibly marked
>>> region?
>>
>> Not everybody searches the screen for tell-tale signs of an active
>> region before typing any letter.
>
> Yes, I know some long time Emacs users works this way (and that is
> understandable since the regions was not visibly marked before by
> default), but we are talking about the new users here.

New users are not inefficient morons.  And if they are, there is no
reason for them to stay thus.

>>>>> If the default will be that typing new text replaces the visible
>>>>> region then maybe there should be a substate where it is possible to
>>>>> type in new text while the region is visible? One way this could be
>>>>> done is to let C-x C-x go into that substate (in addition to doing
>>>>> what it does now).
>>>>>
>>>>> Would that be to inconvinient?
>>>> It sounds messy.  We already have too many different region states.
>>> But the wish to make this work for both new and old users call for a
>>> new state, right?
>>
>> Wrong.  I already proposed folding mouse-activated-deletion mode into
>> transient regions which would make for one less state, and provide a
>> somewhat less contentious part of delete-selection-mode.
>>
>> Is there a reason you are ignoring that particular proposal?
>
> Yes, I am not using the mouse if I can avoid it ;-)

It had nothing to do whatsoever with using the mouse.

> It was not my intention to ignore it of course. However rereading what
> you wrote I see that you said that there is no way for the average
> (new) user to deactivate the region. He/she can use the arrow keys
> without shift.

That does not deactivate a region when transient-mark-mode is used.
Could you please focus on _Emacs_ instead of whatever else you might be
thinking of?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Lennart Borgman (gmail)]

David Kastrup wrote:
>> However rereading what
>> you wrote I see that you said that there is no way for the average
>> (new) user to deactivate the region. He/she can use the arrow keys
>> without shift.
> 
> That does not deactivate a region when transient-mark-mode is used.

Is that really the case? Then I think it is a mistake. New users will 
expect that arrow keys without shift will deactivate the region.

Re: delete-selection-mode

[David Kastrup]

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

> David Kastrup wrote:
>>> However rereading what
>>> you wrote I see that you said that there is no way for the average
>>> (new) user to deactivate the region. He/she can use the arrow keys
>>> without shift.
>>
>> That does not deactivate a region when transient-mark-mode is used.
>
> Is that really the case? Then I think it is a mistake. New users will
> expect that arrow keys without shift will deactivate the region.

How about trying an Emacs with default settings and workflow before
making further suggestions?

This is becoming surreal.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> David Kastrup wrote:
>>>> However rereading what
>>>> you wrote I see that you said that there is no way for the average
>>>> (new) user to deactivate the region. He/she can use the arrow keys
>>>> without shift.
>>> That does not deactivate a region when transient-mark-mode is used.
>> Is that really the case? Then I think it is a mistake. New users will
>> expect that arrow keys without shift will deactivate the region.
> 
> How about trying an Emacs with default settings and workflow before
> making further suggestions?

Maybe that is a good suggestion, but I can not see how it is relevant to 
the statement I make here. Don't you think that new users will expect 
arrow keys without shift to deactivate the region?

RE: delete-selection-mode

[Drew Adams]

> >> (new) user to deactivate the region. He/she can use the arrow keys
> >> without shift.
> > 
> > That does not deactivate a region when transient-mark-mode is used.
> 
> Is that really the case? Then I think it is a mistake. New users will 
> expect that arrow keys without shift will deactivate the region.

and

> Don't you think that new users will expect 
> arrow keys without shift to deactivate the region?


Please, people, let's stop proposing to remake t-m mode or delete-selection mode
so that they correspond to what non-Emacs users are used to. We have CUA for
that. Both t-m mode and delete-selection mode should continue to let you extend
the active region using unshifted arrow keys.

What I said for delete-selection mode applies also to t-m mode:

>> This is what comes, I suppose, of the suggestion that it
>> become the default behavior. We end up with proposals to 
>> shoot out its kneecaps. Delete selection mode is not CUA 
>> selection or shift selection. It is not exactly what newbies 
>> are used to, and it shouldn't be made so. Let it be.

Apparently, some people who don't use delete-selection mode or t-m mode are
freaked out about their being used by default, and are trying to change their
turned-on behavior to be more like either their turned-off behavior or the
CUA-style behavior that some newbies might expect.

So let's forget about using them by default and let them be, so that those who
do appreciate them can continue to use them.

Re: delete-selection-mode

[David Kastrup]

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

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> David Kastrup wrote:
>>>>> However rereading what
>>>>> you wrote I see that you said that there is no way for the average
>>>>> (new) user to deactivate the region. He/she can use the arrow keys
>>>>> without shift.
>>>> That does not deactivate a region when transient-mark-mode is used.
>>> Is that really the case? Then I think it is a mistake. New users will
>>> expect that arrow keys without shift will deactivate the region.
>>
>> How about trying an Emacs with default settings and workflow before
>> making further suggestions?
>
> Maybe that is a good suggestion, but I can not see how it is relevant
> to the statement I make here.

It keeps you from making actually useful suggestions.

> Don't you think that new users will expect arrow keys without shift to
> deactivate the region?

Please make a copy of Wordpad and call it Emacs.  Presumably that should
meet all of your new users' expectations without you needing to bother
the rest of the list readers.

And please be advised that not surprising new users is a very secondary
goal of Emacs.  The main goal of Emacs is to be a useful and powerful
editor for its users.  Any proposals for secondary goals that get into
the hairs of primary goals are stillborn.

If you don't get accustomed to Emacs before you make proposals for it,
you are wasting both your and our time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Stefan Monnier]

>>> However rereading what you wrote I see that you said that there is
>>> no way for the average (new) user to deactivate the region. He/she
>>> can use the arrow keys without shift.
>> 
>> That does not deactivate a region when transient-mark-mode is used.

> Is that really the case?

Better ask Emacs rather than this mailing-list.


        Stefan

Re: delete-selection-mode

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>>> However rereading what you wrote I see that you said that there is
>>>> no way for the average (new) user to deactivate the region. He/she
>>>> can use the arrow keys without shift.
>>> That does not deactivate a region when transient-mark-mode is used.
> 
>> Is that really the case?
> 
> Better ask Emacs rather than this mailing-list.


It would perhaps not get that emphasis if I just asked Emacs. The answer 
is of course that the arrow keys without shift does deactivate the region.

Re: delete-selection-mode

[Lennart Borgman (gmail)]

David Kastrup wrote:
>> Don't you think that new users will expect arrow keys without shift to
>> deactivate the region?
> 
> Please make a copy of Wordpad and call it Emacs.  Presumably that should
> meet all of your new users' expectations without you needing to bother
> the rest of the list readers.


Maybe I have better get used to Wordpad. Your sparkling intelligence 
will perhaps scare away all new users and finally kill Emacs.

Re: delete-selection-mode

[David Kastrup]

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

> Stefan Monnier wrote:
>>>>> However rereading what you wrote I see that you said that there is
>>>>> no way for the average (new) user to deactivate the region. He/she
>>>>> can use the arrow keys without shift.
>>>> That does not deactivate a region when transient-mark-mode is used.
>>
>>> Is that really the case?
>>
>> Better ask Emacs rather than this mailing-list.
>
>
> It would perhaps not get that emphasis if I just asked Emacs. The
> answer is of course that the arrow keys without shift does deactivate
> the region.

Type C-SPC Right Right Right.  You get an active region.  It does not
get inactivated by arrow keys without shift.

So could you please try adapting your proposals to the actual Emacs
behavior?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Stefan Monnier wrote:
>>>>>> However rereading what you wrote I see that you said that there is
>>>>>> no way for the average (new) user to deactivate the region. He/she
>>>>>> can use the arrow keys without shift.
>>>>> That does not deactivate a region when transient-mark-mode is used.
>>>> Is that really the case?
>>> Better ask Emacs rather than this mailing-list.
>>
>> It would perhaps not get that emphasis if I just asked Emacs. The
>> answer is of course that the arrow keys without shift does deactivate
>> the region.
> 
> Type C-SPC Right Right Right.  You get an active region.  It does not
> get inactivated by arrow keys without shift.
> 
> So could you please try adapting your proposals to the actual Emacs
> behavior?

Excuse me, David. I give up for the moment. It would be fun wrestling 
with you if we could merge instead of diverge. Maybe we can do that some 
day. I think it could be creative.

Here we were talking about new users. One assumption is that they 
activate the region by typing for example shift-right. In that case an 
arrow key deactivate the region.

Re: delete-selection-mode

[Stefan Monnier]

>>> Don't you think that new users will expect arrow keys without shift to
>>> deactivate the region?
>> 
>> Please make a copy of Wordpad and call it Emacs.  Presumably that should
>> meet all of your new users' expectations without you needing to bother
>> the rest of the list readers.

> Maybe I have better get used to Wordpad. Your sparkling intelligence will
> perhaps scare away all new users and finally kill Emacs.

The code, people, look at the code.


        Stefan

Re: delete-selection-mode

[Alfred M. Szmidt]

How about talking about users in general, not only new users use
emacs, emacs should have good defaults for both new and old users.

Re: delete-selection-mode

[David Kastrup]

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

>>>> Don't you think that new users will expect arrow keys without shift to
>>>> deactivate the region?
>>> 
>>> Please make a copy of Wordpad and call it Emacs.  Presumably that should
>>> meet all of your new users' expectations without you needing to bother
>>> the rest of the list readers.
>
>> Maybe I have better get used to Wordpad. Your sparkling intelligence will
>> perhaps scare away all new users and finally kill Emacs.
>
> The code, people, look at the code.

It apparently is in a state of complete messiness which indeed
introduces some sort of "shiftiness active".

Try S-Right S-Right C-x C-x Left.  The region is not extended.

I don't remember _any_ discussion about this somewhat volatile
_additional_ region active state (of which there are already too many).

Or try something like C-SPC Right Right C-x C-x S-Left and look and
behold, the existing active region gets removed and a new is started.

What is the design for that, if any?  Can somebody express the current
default semantics in a few simple sentences?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Paul R]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> How about talking about users in general, not only new users use
> emacs, emacs should have good defaults for both new and old users.

If they had the same expectations, yes. But they are often
incompatibles. In such a case, new users expectations should take
precedence, simply because :
 - new users might give up because they don't realize that what they
   don't like is only a default setting, not inherent to the emacs
   program itself
 - old user know how to change a simple setting in 30 seconds

-- 
      Paul

Re: delete-selection-mode

[David Kastrup]

Paul R <paul.r.ml@gmail.com> writes:

> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
>> How about talking about users in general, not only new users use
>> emacs, emacs should have good defaults for both new and old users.
>
> If they had the same expectations, yes. But they are often
> incompatibles. In such a case, new users expectations should take
> precedence, simply because :
>  - new users might give up because they don't realize that what they
>    don't like is only a default setting, not inherent to the emacs
>    program itself
>  - old user know how to change a simple setting in 30 seconds

Expectations should never take precedence when they are connected with
an inferior way to accomplish things.

As an example: I can explain Emacs' general mouse cut/copy/paste
interface in 4 lines of text:

Single/double/triple left mouse clicks mark character/word/line start
respectively of the region.  Dragging or single right mouse click marks
the other end, double right mouse click deletes the region.  In either
case, middle mouse pastes the previous region contents.

That's simple, efficient, and not what the new user expects.  It would
be stupid to hide this very ergonomic mouse behavior away in a
non-default setting: Emacs is such a large beast that people can be
expected to discover about 5% of its non-defaults in their life time.

We don't want to make Emacs an efficient editor only for those who knew
Emacs-19 and can reconfigure all insanities back to more efficient
defaults.

After all: new users might give up because they don't realize that what
fails to make them more efficient than when using other editors is only
a default setting, not inherent to the emacs program itself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Juanma Barranquero]

On Mon, Apr 21, 2008 at 8:51 PM, David Kastrup <dak@gnu.org> wrote:

>  After all: new users might give up because they don't realize that what
>  fails to make them more efficient than when using other editors is only
>  a default setting, not inherent to the emacs program itself.

New users might give up because they don't realize that what fails to
make them as efficient as when using other editors is only a default
setting, not inherent to the emacs program itself.

[It seems unfair to disregard theoretical new-user expectations unless
they suit your argument...]

 Juanma

Re: delete-selection-mode

[Robert J. Chassell]

    The answer 
    is of course that the arrow keys without shift does deactivate the region.

No, the arrow keys without shift do NOT deactivate the region with

Today's GNU Emacs CVS snapshot, Mon, 2008 Apr 21  09:59 UTC
GNU Emacs 23.0.60.18 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
started with

     emacs -Q -D

and configured with

       --disable-font-backend --with-x --with-type1 --with-x-toolkit=gtk

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: delete-selection-mode

[Lennart Borgman (gmail)]

Robert J. Chassell wrote:
>     The answer 
>     is of course that the arrow keys without shift does deactivate the region.
> 
> No, the arrow keys without shift do NOT deactivate the region with
> 
> Today's GNU Emacs CVS snapshot, Mon, 2008 Apr 21  09:59 UTC
> GNU Emacs 23.0.60.18 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
> started with
> 
>      emacs -Q -D
> 
> and configured with
> 
>        --disable-font-backend --with-x --with-type1 --with-x-toolkit=gtk


I think that depends on how you activate the region from the beginning 
(and I think it is good). This is how it works for me:

1) If the region is activated with C-SPC then unshifted arrow keys does 
not deactivate the region. Is not this in accordance with what Emacs 
long time users might expect today?

2) If the region was activated with a shifted arrow key then unshifted 
arrow keys deactivates the region. I think this is what users accustomed 
to other applications expects.

---
I think Jason's suggestion for delete-selection-mode fits very well with 
the above. I believe it is easy to remember:

"I think delete-selection-mode (and maybe even transient-mark-mode) 
should be enabled only when the region was marked using shift movement keys.
Setting the mark with C-SPC, moving the cursor and typing a self-insert 
character should definitely not delete the region by default, even if 
the region is active and highlighted."

Re: delete-selection-mode

[Richard Stallman]

    > Here's a possible idea: enable delete-selection-mode by default
    > but only after shift-selection and mouse-selection.
    >   

    A useful "quasi-quantization" to consider is how many bits of state
    a user must keep in mind to accurately predict the dynamically variable
    behavior of self-insert-command.

It's not a real factor for this issue, because the two cases
are quite distinct already.

Re: delete-selection-mode

[Richard Stallman]

    Is that really the case? Then I think it is a mistake. New users will 
    expect that arrow keys without shift will deactivate the region.

Absolutely not!  That would spoil the normal way of using the region.

Emacs cannot be made totally compatible with most editors except at
the cost of a painful incompatible change.  Please forget it.

Re: delete-selection-mode

[David Kastrup]

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

> On Mon, Apr 21, 2008 at 8:51 PM, David Kastrup <dak@gnu.org> wrote:
>
>>  After all: new users might give up because they don't realize that what
>>  fails to make them more efficient than when using other editors is only
>>  a default setting, not inherent to the emacs program itself.
>
> New users might give up because they don't realize that what fails to
> make them as efficient as when using other editors is only a default
> setting, not inherent to the emacs program itself.
>
> [It seems unfair to disregard theoretical new-user expectations unless
> they suit your argument...]

If you read more than a few isolated lines from a single mail before
replying, you can avoid the argument going in circles.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Alfred M. Szmidt]

   "Alfred M. Szmidt" <ams@gnu.org> writes:

   > How about talking about users in general, not only new users use
   > emacs, emacs should have good defaults for both new and old users.

   If they had the same expectations, yes. But they are often
   incompatibles. In such a case, new users expectations should take
   precedence, simply because :
    - new users might give up because they don't realize that what they
      don't like is only a default setting, not inherent to the emacs
      program itself
    - old user know how to change a simple setting in 30 seconds

That is very short sighted way of looking at things, new users will
become old users with time.  A default setting is default because it
common by those who use something alot; if one cannot use emacs out of
the box without having to modify things, then something is terribly
wrong.

Re: delete-selection-mode

[Jason Rumney]

David Kastrup wrote:

> Try S-Right S-Right C-x C-x Left.  The region is not extended.
>   

That is as I'd expect. Shift-selection should act like mouse selection, 
not like traditional C-SPC setting of mark then moving point.

> Or try something like C-SPC Right Right C-x C-x S-Left and look and
> behold, the existing active region gets removed and a new is started.
>
> What is the design for that, if any?  Can somebody express the current
> default semantics in a few simple sentences?
>   

Don't mix C-SPC setting of the mark and Shift-movement. Use one or the 
other.

Separating them like this is the only way to make Shift-selection act 
like users coming to Emacs from other programs expect it to.  Trying to 
kludge a solution where Shift-selection and C-SPC are interchangable 
breaks users' expectations, and if we do that, what is the point of 
enabling Shift selection at all?

Re: delete-selection-mode

[Lennart Borgman (gmail)]

> Expectations should never take precedence when they are connected with
> an inferior way to accomplish things.

I would suggest that you be more exact in your thinking here. You could 
either carefully generalize (which will take a lot of space and time) or 
try to frame a more exact situation where the essense of your statement 
is valid (and then avoid generalizing that).

Re: delete-selection-mode

[Jason Rumney]

David Kastrup wrote:
> Expectations should never take precedence when they are connected with
> an inferior way to accomplish things.
>   

Is that really an objective point of view? To me it looks like 
arrogance, and if I were a prospective new user of Emacs encountering 
it, I might be inclined to look elsewhere.

Re: delete-selection-mode

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Don't mix C-SPC setting of the mark and Shift-movement. Use one or the 
> other.


I would actually suggest one mixing:

- If the user activated the region with Shift-movement and then types 
C-SPC then keep the current active region, but switch to the C-SPC 
semantics for the current active region (ie arrow keys should not 
deactivate the region).

Re: delete-selection-mode

[Paul R]

> As an example: I can explain Emacs' general mouse cut/copy/paste
> interface in 4 lines of text:
>
> Single/double/triple left mouse clicks mark character/word/line start
> respectively of the region.  Dragging or single right mouse click marks
> the other end, double right mouse click deletes the region.  In either
> case, middle mouse pastes the previous region contents.

The "incremental" nature of this interface makes the trial-error
methodology very efficient in this case. IOW, people can understand
immediatly, and without refering to huge documentation of which they
aren't even aware of existence. We agree on this particular case.

> After all: new users might give up because they don't realize that what
> fails to make them more efficient than when using other editors is only
> a default setting, not inherent to the emacs program itself.

Yes. But I am not trying to argue what is the most efficient way to
work, I'm leaving this decision to each emacs user feeling. I just
want newcomers to feel sufficiently welcome to stay a bit and see.
They will then have plenty of time to discover how to increase the
productivity of their tool.

If you had a shop at the first floor of a building, would you build
some stairs with 1 meter high steps each, just because you know its
doable with lots of training, and incidentatly more efficient than
many many tiny 20cm high steps, like in every other place ?

--
      Paul

Re: delete-selection-mode

[Juanma Barranquero]

On Mon, Apr 21, 2008 at 9:48 PM, David Kastrup <dak@gnu.org> wrote:

>  If you read more than a few isolated lines from a single mail

I do.

 Juanma

Re: delete-selection-mode

[Lennart Borgman (gmail)]

Alfred M. Szmidt wrote:
> A default setting is default because it
> common by those who use something alot;

For a small application with a closed user group that is probably 
correct, but I think in most application the default setting has grown 
out of what both new and old users expect.

Re: delete-selection-mode

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> Expectations should never take precedence when they are connected with
>> an inferior way to accomplish things.
>
> Is that really an objective point of view?

Strawman.  It is not a point of view at all.  It is a design principle.
And where "inferior" means "with a lot more hassle" or
"self-inconsistent", I consider this an eminently prudent principle.

> To me it looks like arrogance, and if I were a prospective new user of
> Emacs encountering it, I might be inclined to look elsewhere.

An program can not be arrogant, and whether or not you want to call my
discourse on emacs-devel an exhibition of arrogance does not concern
prospective new users.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[David Kastrup]

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

> On Mon, Apr 21, 2008 at 9:48 PM, David Kastrup <dak@gnu.org> wrote:
>
>>  If you read more than a few isolated lines from a single mail
>
> I do.

Playing games is not the purpose of emacs-devel.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Juanma Barranquero]

On Mon, Apr 21, 2008 at 10:09 PM, David Kastrup <dak@gnu.org> wrote:

>  Playing games is not the purpose of emacs-devel.

You now not only tell us what Emacs is or should be, but what
emacs-devel is or should be. I think I agree with Jason.

 Juanma

Re: delete-selection-mode

[David Kastrup]

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

> Jason Rumney wrote:
>> Don't mix C-SPC setting of the mark and Shift-movement. Use one or
>> the other.
>
>
> I would actually suggest one mixing:
>
> - If the user activated the region with Shift-movement and then types
> C-SPC then keep the current active region, but switch to the C-SPC
> semantics for the current active region (ie arrow keys should not
> deactivate the region).

Anyway, we have at least three active region semantics in Emacs' default
behavior:

a) semi-traditional transient-mark-mode (with mark-even-if-inactive)
b) temporary transient-mark-mode triggered by mouse commands
c) whatever transient-mark-mode triggered by shift-movement

It turns out that (b) and (c), for some reason, can extend a region set
by each other, while (a) can't.

However, you can extend a region set with (a) with a (b) type mouse
command (right click to extend region).  You can't extend (a) using (c).
For a region selected with (b), hitting DEL will erase the region.  This
is not the case for either (a) or (c).

This is pretty much an incoherent mess.  Since the objective was to have
a "newbie-mode", I propose that we at the very least fold (b) and (c)
into a single mode.

This implies that hitting DEL after either (b) or (c) style marking
should delete the region.

For this single mode, we might want to have the equivalent of
delete-selection-mode available (possibly by default, but at the very
least optional): erasing an active region selection by one of the two
"well-known/newbie/industry-standard" methods (b) and (c) when a
self-inserting character is typed.

Note that I am talking about a consolidated _default_ behavior of Emacs
here.  It is not clear to me which of the multitude of existing mode
variables should actually be retained.  I don't think it realistic to
get coherent behavior for all combinations of existing and necessary new
mode variable settings.  At the very least, I think that the exact
current semantics of temporary-transient-mark-mode in connection with
mouse commands is not worth trying to preserve with some setting
combination in the course of this cleanup.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[David Kastrup]

Paul R <paul.r.ml@gmail.com> writes:

>> After all: new users might give up because they don't realize that
>> what fails to make them more efficient than when using other editors
>> is only a default setting, not inherent to the emacs program itself.
>
> Yes. But I am not trying to argue what is the most efficient way to
> work, I'm leaving this decision to each emacs user feeling.

But it is inefficient to dig around for customization options and
different work styles all the time...

> If you had a shop at the first floor of a building, would you build
> some stairs with 1 meter high steps each, just because you know its
> doable with lots of training, and incidentatly more efficient than
> many many tiny 20cm high steps, like in every other place ?

It isn't more efficient.  Simple biomechanics (muscles work best in
intermediate elongation, in particular when we are talking about those
bending a limb).  Even if you believed it to be more efficient, nobody
keeps you from taking five steps at a time.

I think there is no necessity to throw bad-fitting analogies into the
discussion: there is enough material to cover without them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: delete-selection-mode

[Alan Mackenzie]

Hi, Thomas!

On Sun, Apr 20, 2008 at 08:59:43PM -0700, Thomas Lord wrote:
> Richard Stallman wrote:
> >Here's a possible idea: enable delete-selection-mode by default but
> >only after shift-selection and mouse-selection.
 
> A useful "quasi-quantization" to consider is how many bits of state a
> user must keep in mind to accurately predict the dynamically variable
> behavior of self-insert-command.  (One is probably pushing it and I
> gather that emacs is going well into N>1 territory.   Bummer.)

I think this is the most important point in this discussion (and many
others).  An essential feature of Emacs is that N = 0, or at least has
been until recently.  That is what distinguishes it from both vi and
typical lesser editors, and IMAO is a critical part of what makes Emacs
such a joy to use.  

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
>> A useful "quasi-quantization" to consider is how many bits of state a
>> user must keep in mind to accurately predict the dynamically variable
>> behavior of self-insert-command.  (One is probably pushing it and I
>> gather that emacs is going well into N>1 territory.   Bummer.)
> 
> I think this is the most important point in this discussion (and many
> others).  An essential feature of Emacs is that N = 0, or at least has
> been until recently.  That is what distinguishes it from both vi and
> typical lesser editors, and IMAO is a critical part of what makes Emacs
> such a joy to use.  

Hi Alan and Thomas,

In a sense I agree, but for that I have to stretch my definition of 0 
quite a bit ... ;-)

Beeing more serious I think that the base mix of states should be as 
stable as possible. However that should be true both for new and old users.

As we have seen from the discussion even long time users may have great 
trouble accomodating to changes in the base state. For some period 
(short or long) the new and old base state must be available in memory 
and I guess this can interfere with other psychic activity.

I believe that for new users it is even worse. They tend to use other 
applications beside Emacs and that means that the new and old base state 
comes from different applications and must be kept available in memory 
for as long time that the user uses both Emacs and other applications 
(or have changed Emacs to use cua-mode and maybe some other things).

I am not sure how important the burden of the state is, but I guess that 
some of the upset feeling might come from this burden. Some surely come 
from other psychic domains. BTW, do you know that stressed animals tend 
to seek the familiar surroundings even if the stress factor is there? 
Perhaps this can be translated to that stress is something that can 
block creativity in certain circumstances.

Re: delete-selection-mode

[Richard Stallman]

    Is that really an objective point of view? To me it looks like 
    arrogance, and if I were a prospective new user of Emacs encountering 
    it, I might be inclined to look elsewhere.

That would be no disaster.

All else being equal, we would prefer to make each potential user
feel more at home with Emacs.  But that does not mean we will
make incompatible changes that are bad for existing users.
This is a non-starter.

Re: delete-selection-mode

[Thomas Lord]

Richard Stallman wrote:
>     Is that really an objective point of view? To me it looks like 
>     arrogance, and if I were a prospective new user of Emacs encountering 
>     it, I might be inclined to look elsewhere.
>
> That would be no disaster.
>
> All else being equal, we would prefer to make each potential user
> feel more at home with Emacs.  But that does not mean we will
> make incompatible changes that are bad for existing users.
> This is a non-starter.
>   

I don't wish to direct any productive labor *away* from GNU Emacs
but, perhaps it would be worth mentioning here that:

1) Editors in the Emacsen family are not *that* hard to write from
    scratch and, historically, each one (more or less) has found new
    ideas worth exploring.

2) It's a fun project, if you can afford to work on it and see it through.

3) It's a lot easier than throwing lots of losing arguments at an 
Emacs-family
    project that gets along just fine without that.


Go hack!  Why argue?  Start afresh, if the current state seems so bad.

-t






>
>
>   

Re: delete-selection-mode

[Jason Rumney]

Richard Stallman wrote:
> All else being equal, we would prefer to make each potential user
> feel more at home with Emacs.  But that does not mean we will
> make incompatible changes that are bad for existing users.
> This is a non-starter.
>   

I don't think that your suggestion is an incompatible change:

  Here's a possible idea: enable delete-selection-mode by default
  but only after shift-selection and mouse-selection.

Users who are used to the traditional Emacs behaviour get no surprises 
as long as they continue to set the mark in the traditional way. Users 
who are used to other programs' behaviour get the behaviour they are 
used to, as long as they use the keys they are used to.

Re: delete-selection-mode

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman wrote:
>> All else being equal, we would prefer to make each potential user
>> feel more at home with Emacs.  But that does not mean we will
>> make incompatible changes that are bad for existing users.
>> This is a non-starter.
>>   
>
> I don't think that your suggestion is an incompatible change:
>
>  Here's a possible idea: enable delete-selection-mode by default
>  but only after shift-selection and mouse-selection.
>
> Users who are used to the traditional Emacs behaviour get no surprises
> as long as they continue to set the mark in the traditional way.

Setting the region with the mouse has been supported since Emacs 19 at
least.  That's pretty traditional in my book.

Anyway, we don't have a way to enable delete-selection-mode for a subset
of region activations.

While I am in favor of merging shift-selection and mouse-selection
behavior in all respects (in particular with regard to typing DEL) in
order to cut down on different semantics, delete-selection-mode for
"traditional transient-mark-mode" (a bit of an oxymoron since
transient-mark-mode has not been the default until recently) seems to
have quite a different impact than for shift-selection/mouse-selection.

-- 
David Kastrup

Re: delete-selection-mode

[Robert J. Chassell]

   > No, the arrow keys without shift do NOT deactivate the region ...

   I think that depends on how you activate the region ...

   2) If the region was activated with a shifted arrow key then unshifted 
   arrow keys deactivates the region. I think this is what users accustomed 
   to other applications expects.

No, the arrow keys without shift do NOT deactivate the region; they
deactivate the HIGHLIGHTING for the region.  I am not only able to
call `exchange-point-and-mark' (which I invoke with `C-x C-x'), which
tells me the region continues to exist, but the highlighting
reappears.

    To reproduce this, call

        emacs -Q -D 

    and expect point to appear in the *scratch* buffer two lines below
    the default text.  Set the mark by calling `set-mark-command'
    (which I invoke with `C-SPC').

    Move point back three line with `previous-line' (which I invoke by
    pressing `C-p' three times); you will see the region marked with
    highlighting.

    Then mark the line on which point is with `move-end-of-line' with
    a shift key prefix (which I invoke by pressing Shift-Control-e,
    S-C-e).

    Two lines of highlighting disappear.  You are only able to
    exchange point and mark on the line although you can pop to the
    previous mark by prefixing `set-mark-command' with a
    `universal-argument' (which I invoke with `C-u C-SPC').

    The highlighting stays vanished when you call `set-mark-command'
    with a `universal-argument' but reappears when you call
    `exchange-point-and-mark'.

    To get rid of the initial highlighting, 

        emacs -Q -D --eval="(transient-mark-mode -1)"

    but presumably no one wants experienced Emacs contributors to
    evaluate `transient-mark-mode' on the command line since we are
    asked to provide examples with `emacs -q' or equivalent.  (For
    emacs-devel, I think it is both smart and good to call Emacs
    without evaluating any expressions by --eval or in a .emacs file.)

Today's GNU Emacs CVS snapshot, Tue, 2008 Apr 22  10:19 UTC
GNU Emacs 23.0.60.19 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
started with

    emacs -Q -D

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: delete-selection-mode

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    > No, the arrow keys without shift do NOT deactivate the region ...
>
>    I think that depends on how you activate the region ...
>
>    2) If the region was activated with a shifted arrow key then unshifted 
>    arrow keys deactivates the region. I think this is what users accustomed 
>    to other applications expects.
>
> No, the arrow keys without shift do NOT deactivate the region; they
> deactivate the HIGHLIGHTING for the region.  I am not only able to
> call `exchange-point-and-mark' (which I invoke with `C-x C-x'), which
> tells me the region continues to exist, but the highlighting
> reappears.

I should think you are wrong here.  An existing region and an active
region are two different things, in particular when
mark-even-if-inactive is t (which it is by default).  And C-x C-x
reactivates region and mark anyway without complaint.

An _active_ region, for example, constrains the scope of M-%.  An
existing region doesn't.

-- 
David Kastrup

Re: delete-selection-mode

[David Reitter]

On 22 Apr 2008, at 13:20, Robert J. Chassell wrote:
> No, the arrow keys without shift do NOT deactivate the region; they
> deactivate the HIGHLIGHTING for the region.  I am not only able to
> call `exchange-point-and-mark' (which I invoke with `C-x C-x'), which
> tells me the region continues to exist, but the highlighting
> reappears.

I've always found this behavior confusing.  To keep the mark, that's  
fine and desirable (to do things like C-x C-x), but re-activating the  
region seems odd.

Jason Rumney wrote:

> Here's a possible idea: enable delete-selection-mode by default
> but only after shift-selection and mouse-selection.

This would be great if highlighting serves as indication to the user.   
That is, enable delete-selection-mode by default if and only if the  
region is highlighted.  Without the highlighting, you'd introduce an  
additional invisible mode, which is bad UI design. 

Re: delete-selection-mode

[Robert J. Chassell]

    An existing region and an active region are two different things,
    in particular when mark-even-if-inactive is t ...

You are right.  I thought mark-even-if-inactive was nil and
transient-mark-mode was t but both are t.  This is confusing.

Today's GNU Emacs CVS snapshot, Tue, 2008 Apr 22  10:19 UTC
GNU Emacs 23.0.60.19 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
started with

    emacs -Q -D

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: delete-selection-mode

[Richard Stallman]

    I don't think that your suggestion is an incompatible change:

      Here's a possible idea: enable delete-selection-mode by default
      but only after shift-selection and mouse-selection.

Indeed, I was looking for a way to do this without an incompatible
change.

Re: delete-selection-mode

[Richard Stallman]

    Setting the region with the mouse has been supported since Emacs 19 at
    least.  That's pretty traditional in my book.

At least for part of that time we had a feature analogous to delsel mode
for that particular kind of selection.

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

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

[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

[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

[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

[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

[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

[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]

> 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

[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: 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]

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

[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

[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

[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

[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:
> 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

[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

[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

[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

[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

[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

[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

[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

[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: 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

[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

[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

[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

[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

[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:

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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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/

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/

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

[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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

>     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

[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

[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

[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

[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]

    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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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

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

[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

[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

[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

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

[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

[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]

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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

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

[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]

> 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

[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

[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

[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

[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

[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

[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

[Richard Stallman]

Has anyone else here begun trying delete-selection-mode?
If so, what are your experiences with it?

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

[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

[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

[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

[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

[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

[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

[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]

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.

delete-selection-mode

[Richard Stallman]

I have finished my trial of delete-selection-mode.
It was not intolerable, but it was surprising and annoying.

Re: delete-selection-mode

[Stefan Monnier]

> I have finished my trial of delete-selection-mode.
> It was not intolerable, but it was surprising and annoying.

When were you surprised?  Can you give specifics?
I'd like to make the DEL part default (i.e. hitting DEL when the
selection is active deletes the selection),


        Stefan

Re: delete-selection-mode

[James Cloos]

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

SM> I'd like to make the DEL part default (i.e. hitting DEL when the
SM> selection is active deletes the selection),

With the ability to yank it back, or without?

The ability to delete text w/o any way to recover it would be a disaster.

And I haven't been able to deduce the answer to that question from the
various posts on the various threads which I've read.

If the deleted text /can/ be yanked back, then your proposal is welcome.

(Even though I used the work yank, recovery via (undo) also would do.)

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

Re: delete-selection-mode

[Deniz Dogan]

2010/4/29 James Cloos <cloos@jhcloos.com>:
>>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> SM> I'd like to make the DEL part default (i.e. hitting DEL when the
> SM> selection is active deletes the selection),
>
> With the ability to yank it back, or without?
>
> The ability to delete text w/o any way to recover it would be a disaster.
>
> And I haven't been able to deduce the answer to that question from the
> various posts on the various threads which I've read.
>
> If the deleted text /can/ be yanked back, then your proposal is welcome.
>
> (Even though I used the work yank, recovery via (undo) also would do.)
>

I don't see how it would be a disaster not to be able to yank it back.
You would still be able to kill-region with C-w.

I'm in favor of making DEL delete the selection (*not* killing it).
Not being able to "undo" back text after deleting it would be a
terrible idea, but I'd doubt anyone is suggesting we do that.

-- 
Deniz Dogan

RE: delete-selection-mode

[Drew Adams]

> > With the ability to yank it back, or without?
> >
> > The ability to delete text w/o any way to recover it would 
> > be a disaster.
> >
> > And I haven't been able to deduce the answer to that 
> > question from the various posts on the various threads
> > which I've read.
> >
> > If the deleted text /can/ be yanked back, then your 
> > proposal is welcome.
> >
> > (Even though I used the work yank, recovery via (undo) also 
> > would do.)
> 
> I don't see how it would be a disaster not to be able to yank it back.
> You would still be able to kill-region with C-w.
> 
> I'm in favor of making DEL delete the selection (*not* killing it).
> Not being able to "undo" back text after deleting it would be a
> terrible idea, but I'd doubt anyone is suggesting we do that.

`delete-selection-mode' has always acted the way you request: delete, not kill
for DEL.

;;  'supersede
;;      Delete the active region and ignore the current command,
;;      i.e. the command will just delete the region.

(put 'delete-backward-char 'delete-selection 'supersede)
(put 'backward-delete-char-untabify 'delete-selection 'supersede)
(put 'delete-char 'delete-selection 'supersede)

And any user can easily change the behavior. Just put this in your .emacs if you
want DEL to kill the region:

(put 'delete-backward-char 'delete-selection 'kill)
(put 'backward-delete-char-untabify 'delete-selection 'kill)

Re: delete-selection-mode

[Kim F. Storm]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

> 2010/4/29 James Cloos <cloos@jhcloos.com>:
>>>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>> SM> I'd like to make the DEL part default (i.e. hitting DEL when the
>> SM> selection is active deletes the selection),
>>
>> With the ability to yank it back, or without?
>>
>> The ability to delete text w/o any way to recover it would be a disaster.
>>
>> And I haven't been able to deduce the answer to that question from the
>> various posts on the various threads which I've read.
>>
>> If the deleted text /can/ be yanked back, then your proposal is welcome.
>>
>> (Even though I used the work yank, recovery via (undo) also would do.)
>>
>
> I don't see how it would be a disaster not to be able to yank it back.
> You would still be able to kill-region with C-w.
>
> I'm in favor of making DEL delete the selection (*not* killing it).
> Not being able to "undo" back text after deleting it would be a
> terrible idea, but I'd doubt anyone is suggesting we do that.

[off topic] With CUA, using a numeric prefix 1-9 for C-x and C-c will
put the killed/copied text into numeric register 1-9 instead of on the
kill-ring. Giving C-v a numeric prefix will yank from that register
rather than the kill ring.  This works for rectangles too.

[on topic] With CUA, deleting text (including selected text deleted by
"delete-selection-mode") automatically copies the deleted text into
register 0.  This means that the last stretch of text deleted (rather
than killed) can be yanked back with C-0 C-v.

Of course, it's gone as soon as you delete something else - but it's
saved my day more than once :-)

-- 
Kim F. Storm  http://www.cua.dk

Re: delete-selection-mode

[Richard Stallman]

    When were you surprised?  Can you give specifics?

Often by typing a self-inserting char when there was an active region.
Today it happened with C-o.

I think this feature should only apply to selections made using the mouse
and shift-arrows.  The people who are used to deleting selections
are used to making selections in those ways.