GNU bug report logs - #1958
23.0.60; org-mode does not honour shift-select-mode

Previous Next

Full log

View this message in rfc822 format

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Carsten Dominik <dominik <at> science.uva.nl>
Cc: Bastien <bastienguerry <at> googlemail.com>, 1958 <at> debbugs.gnu.org,
        Chong Yidong <cyd <at> stupidchicken.com>
Subject: bug#1958: 23.0.60; org-mode does not honour shift-select-mode
Date: Tue, 20 Jan 2009 22:56:30 +0100

On Tue, Jan 20, 2009 at 8:21 PM, Carsten Dominik <dominik <at> 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 <at> googlemail.com>
>> wrote:
>>>
>>> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>>>
>>>> On Tue, Jan 20, 2009 at 2:40 PM, Chong Yidong <cyd <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.