unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
@ 2009-01-19 17:09 Andreas Amann
       [not found] ` <28B24655-C322-482B-8615-820CA6A99D09@gmail.com>
  0 siblings, 1 reply; 22+ messages in thread
From: Andreas Amann @ 2009-01-19 17:09 UTC (permalink / raw)
  To: emacs-pretest-bug; +Cc: carsten, andreas.amann

start with "emacs -Q test.org"

type "* bla"
and then shift-left

expected behaviour: since shift-select-mode is set to t by default
(see src/callint.c), I would expect that shift-movements select
a region, and that major modes should not override this behaviour,
without being asked of doing so. 

actual behaviour: upon shift-left the binding org-shiftleft is called
which marks the current item as "DONE". This is very confusing for
people accostumed to shift-selection, which works very well in all
other emacs modes I know.

Possible solution: in lisp/org/org.el
only include the bindings 

         '([(shift up)]          org-shiftup)
          '([(shift down)]        org-shiftdown)
          '([(shift left)]        org-shiftleft)
          '([(shift right)]       org-shiftright)
 
if the variable shift-select-mode is nil. 




In GNU Emacs 23.0.60.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2009-01-14 on lnx0015f2465ec6
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--prefix=/home/aamann/local/emacs-cvs' 'LDFLAGS=-L/home/aamann/local/lib64' 'CPPFLAGS=-I/home/aamann/local/include''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_IE.utf8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Org

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
* S-SPC b l a <S-left> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
test.org has auto save data; consider M-x recover-this-file
OVERVIEW






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
@ 2009-01-20  3:18 Chong Yidong
  2009-01-20  5:22 ` Carsten Dominik
  0 siblings, 1 reply; 22+ messages in thread
From: Chong Yidong @ 2009-01-20  3:18 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: 1958, Andreas Amann

Hi Carsten,

Here's a bug report/feature request for org mode.  Adding
shift-selection should be as simple as changing (interactive "P") to
(interactive "^P") in the relevant functions.  I don't know if this
might break XEmacs, though.


"Andreas Amann" <andreas.amann@tyndall.ie> wrote:

> since shift-select-mode is set to t by default (see src/callint.c), I
> would expect that shift-movements select a region, and that major
> modes should not override this behaviour, without being asked of doing
> so.

> actual behaviour: upon shift-left the binding org-shiftleft is called
> which marks the current item as "DONE". This is very confusing for
> people accostumed to shift-selection, which works very well in all
> other emacs modes I know.







^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20  3:18 bug#1958: 23.0.60; org-mode does not honour shift-select-mode Chong Yidong
@ 2009-01-20  5:22 ` Carsten Dominik
  2009-01-20 13:40   ` Chong Yidong
  0 siblings, 1 reply; 22+ messages in thread
From: Carsten Dominik @ 2009-01-20  5:22 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 1958, Andreas Amann, Carsten Dominik

Hi Chong,

thank you for bringing this to my attention.  However, it not
clear to me how modifying the interactive form would solve the
issue that in Org, S-curser keys are used for different fuctionality?

- Carsten

On Jan 20, 2009, at 4:18 AM, Chong Yidong wrote:

> Hi Carsten,
>
> Here's a bug report/feature request for org mode.  Adding
> shift-selection should be as simple as changing (interactive "P") to
> (interactive "^P") in the relevant functions.  I don't know if this
> might break XEmacs, though.
>
>
> "Andreas Amann" <andreas.amann@tyndall.ie> wrote:
>
>> since shift-select-mode is set to t by default (see src/callint.c), I
>> would expect that shift-movements select a region, and that major
>> modes should not override this behaviour, without being asked of  
>> doing
>> so.
>
>> actual behaviour: upon shift-left the binding org-shiftleft is called
>> which marks the current item as "DONE". This is very confusing for
>> people accostumed to shift-selection, which works very well in all
>> other emacs modes I know.
>







^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
       [not found] ` <28B24655-C322-482B-8615-820CA6A99D09@gmail.com>
@ 2009-01-20 10:12   ` Andreas Amann
  0 siblings, 0 replies; 22+ messages in thread
From: Andreas Amann @ 2009-01-20 10:12 UTC (permalink / raw)
  To: Carsten Dominik
  Cc: emacs-pretest-bug, Carsten Dominik, 1958,
	Emacs-orgmode mailing list, andreas.amann, Andreas Amann

I just tested this patch, and can confirm that it works and solves my
problem. Thanks!

Btw: I never associated shift-select with windows (which I have no
experience with). Wasn't shift-select available with Motif since the 
mid 90's?

Andreas

On Mon, Jan 19, 2009 at 09:54:31PM +0100, Carsten Dominik wrote:
>
> I am aware of this conflict, but I had no idea that this mode is on by 
> default?
> What ever happened with Emacs that we have become this much 
> Windows-biased????
>
> Anyway, if the Emacs Gods decide that this has to change, the way to do it 
> would be this:
>
>
> - Carsten
>
>
>
> --- org.el.orig 2009-01-19 21:52:10.000000000 +0100
> +++ org.el      2009-01-19 21:52:42.000000000 +0100
> @@ -246,7 +246,7 @@
>    :group 'org-startup
>    :type 'boolean)
>
> -(defcustom org-replace-disputed-keys nil
> +(defcustom org-replace-disputed-keys shift-select-mode
>    "Non-nil means use alternative key bindings for some keys.
>  Org-mode uses S-<cursor> keys for changing timestamps and priorities.
>  These keys are also used by other packages like `CUA-mode' or 
> `windmove.el'.
>
>
>
>
> On Jan 19, 2009, at 6:09 PM, Andreas Amann wrote:
>
>> start with "emacs -Q test.org"
>>
>> type "* bla"
>> and then shift-left
>>
>> expected behaviour: since shift-select-mode is set to t by default
>> (see src/callint.c), I would expect that shift-movements select
>> a region, and that major modes should not override this behaviour,
>> without being asked of doing so.
>>
>> actual behaviour: upon shift-left the binding org-shiftleft is called
>> which marks the current item as "DONE". This is very confusing for
>> people accostumed to shift-selection, which works very well in all
>> other emacs modes I know.
>>
>> Possible solution: in lisp/org/org.el
>> only include the bindings
>>
>>         '([(shift up)]          org-shiftup)
>>          '([(shift down)]        org-shiftdown)
>>          '([(shift left)]        org-shiftleft)
>>          '([(shift right)]       org-shiftright)
>>
>> if the variable shift-select-mode is nil.
>>
>>
>>
>>
>> In GNU Emacs 23.0.60.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll 
>> bars)
>> of 2009-01-14 on lnx0015f2465ec6
>> Windowing system distributor `The X.Org Foundation', version 11.0.10300000
>> configured using `configure  '--prefix=/home/aamann/local/emacs-cvs' 
>> 'LDFLAGS=-L/home/aamann/local/lib64' 
>> 'CPPFLAGS=-I/home/aamann/local/include''
>>
>> Important settings:
>>  value of $LC_ALL: nil
>>  value of $LC_COLLATE: nil
>>  value of $LC_CTYPE: nil
>>  value of $LC_MESSAGES: nil
>>  value of $LC_MONETARY: nil
>>  value of $LC_NUMERIC: nil
>>  value of $LC_TIME: nil
>>  value of $LANG: en_IE.utf8
>>  value of $XMODIFIERS: @im=none
>>  locale-coding-system: utf-8-unix
>>  default-enable-multibyte-characters: t
>>
>> Major mode: Org
>>
>> Minor modes in effect:
>>  tooltip-mode: t
>>  tool-bar-mode: t
>>  mouse-wheel-mode: t
>>  menu-bar-mode: t
>>  file-name-shadow-mode: t
>>  global-font-lock-mode: t
>>  font-lock-mode: t
>>  blink-cursor-mode: t
>>  global-auto-composition-mode: t
>>  auto-composition-mode: t
>>  auto-encryption-mode: t
>>  auto-compression-mode: t
>>  line-number-mode: t
>>  transient-mark-mode: t
>>
>> Recent input:
>> * S-SPC b l a <S-left> <help-echo> <help-echo> <help-echo>
>> <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
>> <help-menu> <send-emacs-bug-report>
>>
>> Recent messages:
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> test.org has auto save data; consider M-x recover-this-file
>> OVERVIEW






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20  5:22 ` Carsten Dominik
@ 2009-01-20 13:40   ` Chong Yidong
  2009-01-20 14:12     ` Lennart Borgman
                       ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Chong Yidong @ 2009-01-20 13:40 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: 1958, Andreas Amann

Carsten Dominik <dominik@science.uva.nl> writes:

> thank you for bringing this to my attention.  However, it not
> clear to me how modifying the interactive form would solve the
> issue that in Org, S-curser keys are used for different fuctionality?

Ah OK.  I didn't investigate carefully enough.  I see now that Org binds
S-arrow keys to commands that don't have anything to do with cursor
motion.

I don't think consistency demands that S-arrow perform text selection in
other major modes.  So, unless you wish to change it, we can leave this
one alone.






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 13:40   ` Chong Yidong
@ 2009-01-20 14:12     ` Lennart Borgman
  2009-01-23 12:34       ` Andreas Amann
       [not found]     ` <A0F1225F-0B0A-45E6-88EB-F28E4202C240@uva.nl>
  2009-01-20 15:41     ` Lennart Borgman
  2 siblings, 1 reply; 22+ messages in thread
From: Lennart Borgman @ 2009-01-20 14:12 UTC (permalink / raw)
  To: Chong Yidong, 1958; +Cc: Andreas Amann, Carsten Dominik

On Tue, Jan 20, 2009 at 2:40 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> thank you for bringing this to my attention.  However, it not
>> clear to me how modifying the interactive form would solve the
>> issue that in Org, S-curser keys are used for different fuctionality?
>
> Ah OK.  I didn't investigate carefully enough.  I see now that Org binds
> S-arrow keys to commands that don't have anything to do with cursor
> motion.
>
> I don't think consistency demands that S-arrow perform text selection in
> other major modes.  So, unless you wish to change it, we can leave this
> one alone.


Is not this at the same level as any other key binding that should
have a global impact? As I understand it there has been a long fight
to get key bindings consistent. Wouldn't it be unfortunate to step off
that road now?






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
       [not found]     ` <A0F1225F-0B0A-45E6-88EB-F28E4202C240@uva.nl>
@ 2009-01-20 14:23       ` Chong Yidong
  2009-01-20 14:44         ` Carsten Dominik
  0 siblings, 1 reply; 22+ messages in thread
From: Chong Yidong @ 2009-01-20 14:23 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: 1958

Carsten Dominik <dominik@science.uva.nl> writes:

> Thanks, then I will leave it the way it is.  In fact, people who want
> to use shift-selection in Org-mode can do so by setting a single
> variable.

For reference, which variable is that?






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 14:23       ` Chong Yidong
@ 2009-01-20 14:44         ` Carsten Dominik
  0 siblings, 0 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-01-20 14:44 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 1958, Carsten Dominik


On Jan 20, 2009, at 3:23 PM, Chong Yidong wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> Thanks, then I will leave it the way it is.  In fact, people who want
>> to use shift-selection in Org-mode can do so by setting a single
>> variable.
>
> For reference, which variable is that?

org-replace-disputed-keys


It has this rather generic name because not only shift-selection,
but also windmove.el, and I believe more packages compete for these  
keys.

- Carsten






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 13:40   ` Chong Yidong
  2009-01-20 14:12     ` Lennart Borgman
       [not found]     ` <A0F1225F-0B0A-45E6-88EB-F28E4202C240@uva.nl>
@ 2009-01-20 15:41     ` Lennart Borgman
  2009-01-20 16:14       ` Chong Yidong
  2009-01-20 16:20       ` Bastien
  2 siblings, 2 replies; 22+ messages in thread
From: Lennart Borgman @ 2009-01-20 15:41 UTC (permalink / raw)
  To: Chong Yidong, 1958

On Tue, Jan 20, 2009 at 2:40 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> thank you for bringing this to my attention.  However, it not
>> clear to me how modifying the interactive form would solve the
>> issue that in Org, S-curser keys are used for different fuctionality?
>
> Ah OK.  I didn't investigate carefully enough.  I see now that Org binds
> S-arrow keys to commands that don't have anything to do with cursor
> motion.
>
> I don't think consistency demands that S-arrow perform text selection in
> other major modes.  So, unless you wish to change it, we can leave this
> one alone.

Once again then: I really prefer consistency. What do you mean with
"other major modes"? I really thought that S-arrow should perform
selection in all major modes since it is a very basic editing command.






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 15:41     ` Lennart Borgman
@ 2009-01-20 16:14       ` Chong Yidong
  2009-01-20 16:20       ` Bastien
  1 sibling, 0 replies; 22+ messages in thread
From: Chong Yidong @ 2009-01-20 16:14 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 1958

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

>> I don't think consistency demands that S-arrow perform text selection in
>> other major modes.  So, unless you wish to change it, we can leave this
>> one alone.
>
> Once again then: I really prefer consistency. What do you mean with
> "other major modes"? I really thought that S-arrow should perform
> selection in all major modes since it is a very basic editing command.

All things being equal, it's nice to have consistency, but the needs of
individual major modes can outweigh this.  To give another example,
eshell rebinds the up and down arrows to move around in the shell
command history, decoupling the usual equivalence of C-p/up and
C-n/down.

I don't use Org mode myself, but since Carsten, the package maintainer,
appears to have given some thought into this, there is no harm deferring
to him.






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 15:41     ` Lennart Borgman
  2009-01-20 16:14       ` Chong Yidong
@ 2009-01-20 16:20       ` Bastien
  2009-01-20 18:00         ` Lennart Borgman
  1 sibling, 1 reply; 22+ messages in thread
From: Bastien @ 2009-01-20 16:20 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 1958, Chong Yidong, Carsten Dominik

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

> On Tue, Jan 20, 2009 at 2:40 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>>
>> I don't think consistency demands that S-arrow perform text selection in
>> other major modes.  So, unless you wish to change it, we can leave this
>> one alone.
>
> Once again then: I really prefer consistency. What do you mean with
> "other major modes"? I really thought that S-arrow should perform
> selection in all major modes since it is a very basic editing command.

I'm all for consistency as well, but I don't think it implies that
S-<arrow> should have exactly the same behavior in any major-mode, 
or in any editing context.

Org-mode distinguishes between several contexts: tables, lists,
properties, headline, etc.

I think it's reasonable to expect S-<arrow> keys to behave like in
any other modes outside of these specific contexts.  For now this is
not the case, it returns an error like this:

  "org-shiftcursor-error: This command is active in special context like
  tables, headlines or timestamps"

IMHO, getting rid of this error makes Org-mode consistent enough with
other modes.

-- 
 Bastien






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 16:20       ` Bastien
@ 2009-01-20 18:00         ` Lennart Borgman
  2009-01-20 18:57           ` Bastien
  2009-01-20 19:21           ` Carsten Dominik
  0 siblings, 2 replies; 22+ messages in thread
From: Lennart Borgman @ 2009-01-20 18:00 UTC (permalink / raw)
  To: Bastien; +Cc: 1958, Chong Yidong, Carsten Dominik

On Tue, Jan 20, 2009 at 5:20 PM, Bastien <bastienguerry@googlemail.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Tue, Jan 20, 2009 at 2:40 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>>>
>>> I don't think consistency demands that S-arrow perform text selection in
>>> other major modes.  So, unless you wish to change it, we can leave this
>>> one alone.
>>
>> Once again then: I really prefer consistency. What do you mean with
>> "other major modes"? I really thought that S-arrow should perform
>> selection in all major modes since it is a very basic editing command.
>
> I'm all for consistency as well, but I don't think it implies that
> S-<arrow> should have exactly the same behavior in any major-mode,
> or in any editing context.
>
> Org-mode distinguishes between several contexts: tables, lists,
> properties, headline, etc.
>
> I think it's reasonable to expect S-<arrow> keys to behave like in
> any other modes outside of these specific contexts.  For now this is
> not the case, it returns an error like this:
>
>  "org-shiftcursor-error: This command is active in special context like
>  tables, headlines or timestamps"
>
> IMHO, getting rid of this error makes Org-mode consistent enough with
> other modes.

Is not that counter-intuitive? For me it would be fine to use
S-<arrow> for something else than selecting in a context where
selecting is not possible at all. But I wonder if there are any such
contexts in Emacs ...?






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 18:00         ` Lennart Borgman
@ 2009-01-20 18:57           ` Bastien
  2009-01-20 19:21           ` Carsten Dominik
  1 sibling, 0 replies; 22+ messages in thread
From: Bastien @ 2009-01-20 18:57 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 1958, Chong Yidong, Carsten Dominik

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

> Is not that counter-intuitive? For me it would be fine to use
> S-<arrow> for something else than selecting in a context where
> selecting is not possible at all. But I wonder if there are any such
> contexts in Emacs ...?

Calendar?

-- 
 Bastien






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 18:00         ` Lennart Borgman
  2009-01-20 18:57           ` Bastien
@ 2009-01-20 19:21           ` Carsten Dominik
  2009-01-20 21:56             ` Lennart Borgman
                               ` (2 more replies)
  1 sibling, 3 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-01-20 19:21 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: Bastien, Chong Yidong, Carsten Dominik, 1958


On Jan 20, 2009, at 7:00 PM, Lennart Borgman wrote:

> On Tue, Jan 20, 2009 at 5:20 PM, Bastien  
> <bastienguerry@googlemail.com> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Tue, Jan 20, 2009 at 2:40 PM, Chong Yidong  
>>> <cyd@stupidchicken.com> wrote:
>>>>
>>>> I don't think consistency demands that S-arrow perform text  
>>>> selection in
>>>> other major modes.  So, unless you wish to change it, we can  
>>>> leave this
>>>> one alone.
>>>
>>> Once again then: I really prefer consistency. What do you mean with
>>> "other major modes"? I really thought that S-arrow should perform
>>> selection in all major modes since it is a very basic editing  
>>> command.
>>
>> I'm all for consistency as well, but I don't think it implies that
>> S-<arrow> should have exactly the same behavior in any major-mode,
>> or in any editing context.
>>
>> Org-mode distinguishes between several contexts: tables, lists,
>> properties, headline, etc.
>>
>> I think it's reasonable to expect S-<arrow> keys to behave like in
>> any other modes outside of these specific contexts.  For now this is
>> not the case, it returns an error like this:
>>
>> "org-shiftcursor-error: This command is active in special context  
>> like
>> tables, headlines or timestamps"
>>
>> IMHO, getting rid of this error makes Org-mode consistent enough with
>> other modes.
>
> Is not that counter-intuitive? For me it would be fine to use
> S-<arrow> for something else than selecting in a context where
> selecting is not possible at all. But I wonder if there are any such
> contexts in Emacs ...?

I think I have to agree here with Lennart.  If a user expects shifted
cursor motion to do selection, a variable reaction of Emacs depending
on context will be confusing.

For me this issue is that s-cursor commands do very valuable and
intuitive stuff in Org, and these commands are heavily advertised
in the manual and likely used by a large number of active users, who
would also be confused if we suddenly changed this behavior.

In addition to that, Emacs's has alternative methods for
creating a selection that are far superior in my mind.  Setting
the mark and then moving the cursor by any means, in
particular also search ans jumping to the beginning/end
of the buffer - I miss this so much in any program outside Emacs.

I therefore think it is the right decision to have a variable for
setting this and my personal preference would be to let me have my
current default setting in Org-mode which allows me to use these
valuable keys.

After all, it is Emacs 23 that changes its default for these keys
from what we were used to, not Org.

- Carsten













^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 19:21           ` Carsten Dominik
@ 2009-01-20 21:56             ` Lennart Borgman
  2009-01-21  0:03             ` Bastien
  2009-01-21  5:59             ` Leo
  2 siblings, 0 replies; 22+ messages in thread
From: Lennart Borgman @ 2009-01-20 21:56 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: Bastien, Chong Yidong, 1958

On Tue, Jan 20, 2009 at 8:21 PM, Carsten Dominik <dominik@science.uva.nl> wrote:
>
> On Jan 20, 2009, at 7:00 PM, Lennart Borgman wrote:
>
>> On Tue, Jan 20, 2009 at 5:20 PM, Bastien <bastienguerry@googlemail.com>
>> wrote:
>>>
>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>
>>>> On Tue, Jan 20, 2009 at 2:40 PM, Chong Yidong <cyd@stupidchicken.com>
>>>> wrote:
>>>>>
>>>>> I don't think consistency demands that S-arrow perform text selection
>>>>> in
>>>>> other major modes.  So, unless you wish to change it, we can leave this
>>>>> one alone.
>>>>
>>>> Once again then: I really prefer consistency. What do you mean with
>>>> "other major modes"? I really thought that S-arrow should perform
>>>> selection in all major modes since it is a very basic editing command.
>>>
>>> I'm all for consistency as well, but I don't think it implies that
>>> S-<arrow> should have exactly the same behavior in any major-mode,
>>> or in any editing context.
>>>
>>> Org-mode distinguishes between several contexts: tables, lists,
>>> properties, headline, etc.
>>>
>>> I think it's reasonable to expect S-<arrow> keys to behave like in
>>> any other modes outside of these specific contexts.  For now this is
>>> not the case, it returns an error like this:
>>>
>>> "org-shiftcursor-error: This command is active in special context like
>>> tables, headlines or timestamps"
>>>
>>> IMHO, getting rid of this error makes Org-mode consistent enough with
>>> other modes.
>>
>> Is not that counter-intuitive? For me it would be fine to use
>> S-<arrow> for something else than selecting in a context where
>> selecting is not possible at all. But I wonder if there are any such
>> contexts in Emacs ...?
>
> I think I have to agree here with Lennart.  If a user expects shifted
> cursor motion to do selection, a variable reaction of Emacs depending
> on context will be confusing.
>
> For me this issue is that s-cursor commands do very valuable and
> intuitive stuff in Org, and these commands are heavily advertised
> in the manual and likely used by a large number of active users, who
> would also be confused if we suddenly changed this behavior.
>
> In addition to that, Emacs's has alternative methods for
> creating a selection that are far superior in my mind.  Setting
> the mark and then moving the cursor by any means, in
> particular also search ans jumping to the beginning/end
> of the buffer - I miss this so much in any program outside Emacs.

I am not sure that matters here (even though it is good).

> I therefore think it is the right decision to have a variable for
> setting this and my personal preference would be to let me have my
> current default setting in Org-mode which allows me to use these
> valuable keys.
>
> After all, it is Emacs 23 that changes its default for these keys
> from what we were used to, not Org.


This is an unfortunate situation that is difficult to resolve without
doing any (short term) harm. I suggest adding a note about S-<arrow>
(or even better S-<move>) in the manual:

   (info "(elisp) Key Binding Conventions")

This could make it easier in the future to follow the S-* convention.
Whatever the decision for org-mode will be now I think it would be
good to try to follow the S-* convention in the future.






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 19:21           ` Carsten Dominik
  2009-01-20 21:56             ` Lennart Borgman
@ 2009-01-21  0:03             ` Bastien
  2009-01-21  9:30               ` Carsten Dominik
  2009-01-21  5:59             ` Leo
  2 siblings, 1 reply; 22+ messages in thread
From: Bastien @ 2009-01-21  0:03 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: 1958, Chong Yidong

Carsten Dominik <dominik@science.uva.nl> writes:

> I therefore think it is the right decision to have a variable for
> setting this and my personal preference would be to let me have my
> current default setting in Org-mode which allows me to use these
> valuable keys.

I agree with all this.  But still: maybe S-cursor keys could perform
selection outside of special contexts, instead of sending an error.   

In other words, S-cursor would have a special behavior in special
contexts, but the normal (=Emacs) one in a normal context...

What do you think?

-- 
 Bastien






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 19:21           ` Carsten Dominik
  2009-01-20 21:56             ` Lennart Borgman
  2009-01-21  0:03             ` Bastien
@ 2009-01-21  5:59             ` Leo
  2 siblings, 0 replies; 22+ messages in thread
From: Leo @ 2009-01-21  5:59 UTC (permalink / raw)
  To: bug-gnu-emacs

On 2009-01-20 19:21 +0000, Carsten Dominik wrote:
> I therefore think it is the right decision to have a variable for
> setting this and my personal preference would be to let me have my
> current default setting in Org-mode which allows me to use these
> valuable keys.

Agree.

S-<arrow> for selection is only useful for new users. I do not use it at
all. Trying to adopt a key binding from applications that do not have
many key bindings to manage is asking for trouble.

And this functionality can be so easily activated.

Allowing a bit of micro-programming is elegant and consistent.

Best,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.








^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-21  0:03             ` Bastien
@ 2009-01-21  9:30               ` Carsten Dominik
  0 siblings, 0 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-01-21  9:30 UTC (permalink / raw)
  To: Bastien; +Cc: 1958, Chong Yidong, Carsten Dominik


On Jan 21, 2009, at 1:03 AM, Bastien wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> I therefore think it is the right decision to have a variable for
>> setting this and my personal preference would be to let me have my
>> current default setting in Org-mode which allows me to use these
>> valuable keys.
>
> I agree with all this.  But still: maybe S-cursor keys could perform
> selection outside of special contexts, instead of sending an error.
>
> In other words, S-cursor would have a special behavior in special
> contexts, but the normal (=Emacs) one in a normal context...

I think this would be too confusing, in fact.  Just imagine starting
outside a time stamp, and then moving with S-cursor into the time stamp.
outlise the region would bet larger, but upon reaching the time stamp,
the time stamp will change instead....

Or starting somewhere and enlarging the region across a headline....

- Carsten






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-20 14:12     ` Lennart Borgman
@ 2009-01-23 12:34       ` Andreas Amann
  2009-01-23 15:32         ` Carsten Dominik
                           ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Andreas Amann @ 2009-01-23 12:34 UTC (permalink / raw)
  To: 1958; +Cc: Chong Yidong, Carsten Dominik


May I just add one little aspect to this:

Note that in org-mode the shift-arrow keys only work, when the cursor is on an item line 
(i.e. one starting with at least one "*")! Otherwise the shift-arrow keys simply give the error 
"Not in an item", and blocks a potentially useful binding without real benefit. 

Would it therefore be possible to only switch on the org-specific shift-arrow binding on item lines, 
where they are only useful anyhow?  I.e. instead of printing the error message, one could fall back 
to whatever the standard binding outside org-mode is. This would be fairly intuitive from a user 
point of view in my opinion. The only complication might be to decide, what should happen, when 
shift-selecting from a non-item line into an item line. 

Andreas






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-23 12:34       ` Andreas Amann
@ 2009-01-23 15:32         ` Carsten Dominik
  2009-01-26 13:26         ` Carsten Dominik
  2009-01-27 11:46         ` Carsten Dominik
  2 siblings, 0 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-01-23 15:32 UTC (permalink / raw)
  To: Andreas Amann; +Cc: 1958, Chong Yidong, Carsten Dominik

Hi Andreas,

something like this could be done, but would that not be more confusing?

- Carsten

On Jan 23, 2009, at 1:34 PM, Andreas Amann wrote:

>
> May I just add one little aspect to this:
>
> Note that in org-mode the shift-arrow keys only work, when the  
> cursor is on an item line
> (i.e. one starting with at least one "*")! Otherwise the shift-arrow  
> keys simply give the error
> "Not in an item", and blocks a potentially useful binding without  
> real benefit.
>
> Would it therefore be possible to only switch on the org-specific  
> shift-arrow binding on item lines,
> where they are only useful anyhow?  I.e. instead of printing the  
> error message, one could fall back
> to whatever the standard binding outside org-mode is. This would be  
> fairly intuitive from a user
> point of view in my opinion. The only complication might be to  
> decide, what should happen, when
> shift-selecting from a non-item line into an item line.
>
> Andreas







^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-23 12:34       ` Andreas Amann
  2009-01-23 15:32         ` Carsten Dominik
@ 2009-01-26 13:26         ` Carsten Dominik
  2009-01-27 11:46         ` Carsten Dominik
  2 siblings, 0 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-01-26 13:26 UTC (permalink / raw)
  To: Andreas Amann; +Cc: 1958, Chong Yidong, Bastien Guerry, Carsten Dominik

Hi,

I do now have an implementation that does just what Andreas proposes:
It will allow shift selection to proceed outside special contexts.
Furthermore, if the region is already started, it will extend regions
even across special contexts.

The question is:  Should this still go into Emacs 23.1?  If yes,
I can install it later today.
	
Thanks.

- Carsten

On Jan 23, 2009, at 1:34 PM, Andreas Amann wrote:

>
> May I just add one little aspect to this:
>
> Note that in org-mode the shift-arrow keys only work, when the  
> cursor is on an item line
> (i.e. one starting with at least one "*")! Otherwise the shift-arrow  
> keys simply give the error
> "Not in an item", and blocks a potentially useful binding without  
> real benefit.
>
> Would it therefore be possible to only switch on the org-specific  
> shift-arrow binding on item lines,
> where they are only useful anyhow?  I.e. instead of printing the  
> error message, one could fall back
> to whatever the standard binding outside org-mode is. This would be  
> fairly intuitive from a user
> point of view in my opinion. The only complication might be to  
> decide, what should happen, when
> shift-selecting from a non-item line into an item line.
>
> Andreas







^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#1958: 23.0.60; org-mode does not honour shift-select-mode
  2009-01-23 12:34       ` Andreas Amann
  2009-01-23 15:32         ` Carsten Dominik
  2009-01-26 13:26         ` Carsten Dominik
@ 2009-01-27 11:46         ` Carsten Dominik
  2 siblings, 0 replies; 22+ messages in thread
From: Carsten Dominik @ 2009-01-27 11:46 UTC (permalink / raw)
  To: Andreas Amann; +Cc: 1958, Chong Yidong, Carsten Dominik

This bug is now closed, do I need to do something to mark it as such?

I have now checked in a patch that allows users to
set a variable to get shift-selection working in most or
all of Org.

But the default remains to be the old behavior, because
it seems to may that automatically doing shift-selection
in some places but not in other will be confusing to users.

The solution is now that an attempt to do shift selection
will cause an error message with a pointer to the variable
that needs to be configured.  In this way, users can make
an informed decision.

- Carsten

On Jan 23, 2009, at 1:34 PM, Andreas Amann wrote:

>
> May I just add one little aspect to this:
>
> Note that in org-mode the shift-arrow keys only work, when the  
> cursor is on an item line
> (i.e. one starting with at least one "*")! Otherwise the shift-arrow  
> keys simply give the error
> "Not in an item", and blocks a potentially useful binding without  
> real benefit.
>
> Would it therefore be possible to only switch on the org-specific  
> shift-arrow binding on item lines,
> where they are only useful anyhow?  I.e. instead of printing the  
> error message, one could fall back
> to whatever the standard binding outside org-mode is. This would be  
> fairly intuitive from a user
> point of view in my opinion. The only complication might be to  
> decide, what should happen, when
> shift-selecting from a non-item line into an item line.
>
> Andreas







^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2009-01-27 11:46 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-20  3:18 bug#1958: 23.0.60; org-mode does not honour shift-select-mode Chong Yidong
2009-01-20  5:22 ` Carsten Dominik
2009-01-20 13:40   ` Chong Yidong
2009-01-20 14:12     ` Lennart Borgman
2009-01-23 12:34       ` Andreas Amann
2009-01-23 15:32         ` Carsten Dominik
2009-01-26 13:26         ` Carsten Dominik
2009-01-27 11:46         ` Carsten Dominik
     [not found]     ` <A0F1225F-0B0A-45E6-88EB-F28E4202C240@uva.nl>
2009-01-20 14:23       ` Chong Yidong
2009-01-20 14:44         ` Carsten Dominik
2009-01-20 15:41     ` Lennart Borgman
2009-01-20 16:14       ` Chong Yidong
2009-01-20 16:20       ` Bastien
2009-01-20 18:00         ` Lennart Borgman
2009-01-20 18:57           ` Bastien
2009-01-20 19:21           ` Carsten Dominik
2009-01-20 21:56             ` Lennart Borgman
2009-01-21  0:03             ` Bastien
2009-01-21  9:30               ` Carsten Dominik
2009-01-21  5:59             ` Leo
  -- strict thread matches above, loose matches on Subject: below --
2009-01-19 17:09 Andreas Amann
     [not found] ` <28B24655-C322-482B-8615-820CA6A99D09@gmail.com>
2009-01-20 10:12   ` Andreas Amann

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).