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: 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: FW: commands to select things of different kinds

[Richard Stallman]

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

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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

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

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

[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

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

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

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