From: Lennart Borgman <lennart.borgman@gmail.com>
To: Carsten Dominik <dominik@science.uva.nl>
Cc: Bastien <bastienguerry@googlemail.com>,
Chong Yidong <cyd@stupidchicken.com>,
1958@emacsbugs.donarmstrong.com
Subject: bug#1958: 23.0.60; org-mode does not honour shift-select-mode
Date: Tue, 20 Jan 2009 22:56:30 +0100 [thread overview]
Message-ID: <e01d8a50901201356t354de73btae8c3012a4616b45@mail.gmail.com> (raw)
In-Reply-To: <58010E7D-AF80-4562-952D-41B21FDF4AE7@uva.nl>
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.
next prev parent reply other threads:[~2009-01-20 21:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e01d8a50901201356t354de73btae8c3012a4616b45@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=1958@emacsbugs.donarmstrong.com \
--cc=bastienguerry@googlemail.com \
--cc=cyd@stupidchicken.com \
--cc=dominik@science.uva.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).