bug#1958: 23.0.60; org-mode does not honour shift-select-mode

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Chong Yidong]

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.

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Chong Yidong]

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.

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Lennart Borgman]

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?

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Andreas Amann]

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Chong Yidong]

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?

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Lennart Borgman]

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.

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Chong Yidong]

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.

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Bastien]

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Lennart Borgman]

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Bastien]

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Carsten Dominik]

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Lennart Borgman]

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.

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Bastien]

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[Leo]

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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[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

bug#1958: 23.0.60; org-mode does not honour shift-select-mode

[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