* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-21 13:54 ` Carsten Dominik
@ 2010-04-21 14:04 ` Bernt Hansen
2010-04-21 14:44 ` Dan Davison
2010-04-21 20:27 ` Matti De Craene
2 siblings, 0 replies; 17+ messages in thread
From: Bernt Hansen @ 2010-04-21 14:04 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Matti De Craene, emacs-orgmode, Bastien
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Apr 21, 2010, at 3:32 PM, Bastien wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> do others agree with Matti's view?
>>
>> FWIW, I do.
>
> There is still another difference.
>
> Currently, when I execute the indentation command
> several times in a row, the range to which this applies
> is locked.
>
> So for example"
>
> - level 1a
> - level 2a
> - level 2b
> - level 2c
> - level 1b
>
> If I now go on level 1a and use M-S-left, level 1b becomes a sibling
> of 2c. If I immediately after this do M-S-right, 1b should be indented
> along with 2c, but this does not happen because the item range is
> locked. If, however, you do something in between, like moving the
> cursor by one character, 1b will be included.
>
> I believe I did this a long time ago, because I felt that not locking
> the range for commands in direct succession would too quickly modify
> the structure, including at places outside of the current view (
> beyond the window end)
>
> If you are calling for more consistency, maybe this "feature" should
> go as well?
Wouldn't keeping it simple be best? ie. just have M-left and M-right
move the current entry and let M-S-left and M-S-right move as it does
today (including locked regions etc)
I've found I want to move this one list entry in the middle left and
can't since it drags the entire substructure with it -- so I resort to
deleting (or inserting) spaces to move the one line. It's works but
it's a little more cumbersome than prompting/demoting the entire
structure.
But then it's only one line so it's not hard to edit a single line...
I don't think removing the lock is really a good idea personally.
Regards,
Bernt
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-21 13:54 ` Carsten Dominik
2010-04-21 14:04 ` Bernt Hansen
@ 2010-04-21 14:44 ` Dan Davison
2010-04-22 16:02 ` Carsten Dominik
2010-04-21 20:27 ` Matti De Craene
2 siblings, 1 reply; 17+ messages in thread
From: Dan Davison @ 2010-04-21 14:44 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Matti De Craene, emacs-orgmode, Bastien
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Apr 21, 2010, at 3:32 PM, Bastien wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> do others agree with Matti's view?
>>
>> FWIW, I do.
>
> There is still another difference.
>
> Currently, when I execute the indentation command
> several times in a row, the range to which this applies
> is locked.
>
> So for example"
>
> - level 1a
> - level 2a
> - level 2b
> - level 2c
> - level 1b
>
> If I now go on level 1a and use M-S-left, level 1b becomes a sibling
> of 2c. If I immediately after this do M-S-right, 1b should be indented
> along with 2c, but this does not happen because the item range is
> locked. If, however, you do something in between, like moving the
> cursor by one character, 1b will be included.
>
> I believe I did this a long time ago, because I felt that not locking
> the range for commands in direct succession would too quickly modify
> the structure, including at places outside of the current view (
> beyond the window end)
>
> If you are calling for more consistency, maybe this "feature" should
> go as well?
I hope that this is sufficiently closely related to belong in this
thread: I find it surprising that org-do-demote deactivates the
region. Let's say I start out with
* 1
** 11
* 111
* 112
* 2
and I wish to move to make 111 and 112 be children of 11
The way that seems natural to me is to select headings 111 and 112, and
apply org-demote-subtree twice in succession. So with point at the
beginning of the 111 line,
C-space down down M-right M-right
However, this leads me to
* 1
** 11
** 111
** 112
** 2
because after one application of org-demote-subtree, the region becomes
deactivated and the second demotion applies to heading 2, which is
unlikely to have been intended.
Dan
>
> - Carsten
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-21 14:44 ` Dan Davison
@ 2010-04-22 16:02 ` Carsten Dominik
2010-04-23 8:26 ` Carsten Dominik
0 siblings, 1 reply; 17+ messages in thread
From: Carsten Dominik @ 2010-04-22 16:02 UTC (permalink / raw)
To: Dan Davison; +Cc: Matti De Craene, emacs-orgmode, Bastien
On Apr 21, 2010, at 4:44 PM, Dan Davison wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On Apr 21, 2010, at 3:32 PM, Bastien wrote:
>>
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>
>>>> do others agree with Matti's view?
>>>
>>> FWIW, I do.
>>
>> There is still another difference.
>>
>> Currently, when I execute the indentation command
>> several times in a row, the range to which this applies
>> is locked.
>>
>> So for example"
>>
>> - level 1a
>> - level 2a
>> - level 2b
>> - level 2c
>> - level 1b
>>
>> If I now go on level 1a and use M-S-left, level 1b becomes a sibling
>> of 2c. If I immediately after this do M-S-right, 1b should be
>> indented
>> along with 2c, but this does not happen because the item range is
>> locked. If, however, you do something in between, like moving the
>> cursor by one character, 1b will be included.
>>
>> I believe I did this a long time ago, because I felt that not locking
>> the range for commands in direct succession would too quickly modify
>> the structure, including at places outside of the current view (
>> beyond the window end)
>>
>> If you are calling for more consistency, maybe this "feature" should
>> go as well?
>
> I hope that this is sufficiently closely related to belong in this
> thread: I find it surprising that org-do-demote deactivates the
> region. Let's say I start out with
>
> * 1
> ** 11
> * 111
> * 112
> * 2
>
> and I wish to move to make 111 and 112 be children of 11
>
> The way that seems natural to me is to select headings 111 and 112,
> and
> apply org-demote-subtree twice in succession. So with point at the
> beginning of the 111 line,
>
> C-space down down M-right M-right
Hi Dan,
I do agree with your observation. However, keeping the mark active
would mean that further cursor motions will still have the highlighted
region hanging around, and I found this the bigger headache.
What I do in these cases is
M-right C-x C-x M-right
which is not pretty but workable.
- Carsten
>
> However, this leads me to
>
> * 1
> ** 11
> ** 111
> ** 112
> ** 2
>
> because after one application of org-demote-subtree, the region
> becomes
> deactivated and the second demotion applies to heading 2, which is
> unlikely to have been intended.
>
> Dan
>
>
>>
>> - Carsten
>>
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
- Carsten
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-22 16:02 ` Carsten Dominik
@ 2010-04-23 8:26 ` Carsten Dominik
0 siblings, 0 replies; 17+ messages in thread
From: Carsten Dominik @ 2010-04-23 8:26 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Dan Davison, Matti De Craene, emacs-orgmode, Bastien
On Apr 22, 2010, at 6:02 PM, Carsten Dominik wrote:
>
> On Apr 21, 2010, at 4:44 PM, Dan Davison wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> On Apr 21, 2010, at 3:32 PM, Bastien wrote:
>>>
>>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>>
>>>>> do others agree with Matti's view?
>>>>
>>>> FWIW, I do.
>>>
>>> There is still another difference.
>>>
>>> Currently, when I execute the indentation command
>>> several times in a row, the range to which this applies
>>> is locked.
>>>
>>> So for example"
>>>
>>> - level 1a
>>> - level 2a
>>> - level 2b
>>> - level 2c
>>> - level 1b
>>>
>>> If I now go on level 1a and use M-S-left, level 1b becomes a sibling
>>> of 2c. If I immediately after this do M-S-right, 1b should be
>>> indented
>>> along with 2c, but this does not happen because the item range is
>>> locked. If, however, you do something in between, like moving the
>>> cursor by one character, 1b will be included.
>>>
>>> I believe I did this a long time ago, because I felt that not
>>> locking
>>> the range for commands in direct succession would too quickly modify
>>> the structure, including at places outside of the current view (
>>> beyond the window end)
>>>
>>> If you are calling for more consistency, maybe this "feature" should
>>> go as well?
>>
>> I hope that this is sufficiently closely related to belong in this
>> thread: I find it surprising that org-do-demote deactivates the
>> region. Let's say I start out with
>>
>> * 1
>> ** 11
>> * 111
>> * 112
>> * 2
>>
>> and I wish to move to make 111 and 112 be children of 11
>>
>> The way that seems natural to me is to select headings 111 and 112,
>> and
>> apply org-demote-subtree twice in succession. So with point at the
>> beginning of the 111 line,
>>
>> C-space down down M-right M-right
>
> Hi Dan,
>
> I do agree with your observation. However, keeping the mark active
> would mean that further cursor motions will still have the
> highlighted region hanging around, and I found this the bigger
> headache.
>
> What I do in these cases is
>
> M-right C-x C-x M-right
>
> which is not pretty but workable.
If you have a better solution, please let me know.
- Carsten
>
> - Carsten
>
>>
>> However, this leads me to
>>
>> * 1
>> ** 11
>> ** 111
>> ** 112
>> ** 2
>>
>> because after one application of org-demote-subtree, the region
>> becomes
>> deactivated and the second demotion applies to heading 2, which is
>> unlikely to have been intended.
>>
>> Dan
>>
>>
>>>
>>> - Carsten
>>>
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> - Carsten
>
>
>
- Carsten
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-21 13:54 ` Carsten Dominik
2010-04-21 14:04 ` Bernt Hansen
2010-04-21 14:44 ` Dan Davison
@ 2010-04-21 20:27 ` Matti De Craene
2010-04-21 21:07 ` Carsten Dominik
2 siblings, 1 reply; 17+ messages in thread
From: Matti De Craene @ 2010-04-21 20:27 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Bastien
Hello Carsten and others,
> If you are calling for more consistency, maybe this "feature" should
> go as well?
I do not have a strong opinion on this. In (my) day-to-day use of
org-mode, cases in which the difference between having a lock or not
matters rarely do occur.
If consistency here is important, then it seems more sensible to me to
have the lock for headings as well, instead of removing it for list
items. When I grab a chunk of text to move back and forth, I do not
expect it to suddenly get hands and grab other pieces of text :-)
I've discovered a bug in my patch today:
M-Right and M-Left on collapsed items take the complete subtree. On
collapsed headings they only take the current heading. I'm not sure
what would be the desired behaviour here...
Kind Regards,
Matti
On Wed, Apr 21, 2010 at 3:54 PM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
>
> On Apr 21, 2010, at 3:32 PM, Bastien wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> do others agree with Matti's view?
>>
>> FWIW, I do.
>
> There is still another difference.
>
> Currently, when I execute the indentation command
> several times in a row, the range to which this applies
> is locked.
>
> So for example"
>
> - level 1a
> - level 2a
> - level 2b
> - level 2c
> - level 1b
>
> If I now go on level 1a and use M-S-left, level 1b becomes a sibling
> of 2c. If I immediately after this do M-S-right, 1b should be indented
> along with 2c, but this does not happen because the item range is
> locked. If, however, you do something in between, like moving the
> cursor by one character, 1b will be included.
>
> I believe I did this a long time ago, because I felt that not locking
> the range for commands in direct succession would too quickly modify
> the structure, including at places outside of the current view (
> beyond the window end)
>
> If you are calling for more consistency, maybe this "feature" should
> go as well?
>
> - Carsten
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-21 20:27 ` Matti De Craene
@ 2010-04-21 21:07 ` Carsten Dominik
2010-04-22 10:15 ` Bastien
0 siblings, 1 reply; 17+ messages in thread
From: Carsten Dominik @ 2010-04-21 21:07 UTC (permalink / raw)
To: Matti De Craene; +Cc: emacs-orgmode, Bastien
On Apr 21, 2010, at 10:27 PM, Matti De Craene wrote:
> Hello Carsten and others,
>
>
>> If you are calling for more consistency, maybe this "feature" should
>> go as well?
>
> I do not have a strong opinion on this. In (my) day-to-day use of
> org-mode, cases in which the difference between having a lock or not
> matters rarely do occur.
>
> If consistency here is important, then it seems more sensible to me to
> have the lock for headings as well, instead of removing it for list
> items. When I grab a chunk of text to move back and forth, I do not
> expect it to suddenly get hands and grab other pieces of text :-)
Yes, I agree we should keep the lock for lists. For headlines I
have never felt the need as much.
>
> I've discovered a bug in my patch today:
> M-Right and M-Left on collapsed items take the complete subtree. On
> collapsed headings they only take the current heading. I'm not sure
> what would be the desired behaviour here...
Excellent question. I think the cleanest would be that M-left/right
on a folded item that does have children throws an error.
- Carsten
>
> Kind Regards,
>
> Matti
>
>
> On Wed, Apr 21, 2010 at 3:54 PM, Carsten Dominik
> <carsten.dominik@gmail.com> wrote:
>>
>> On Apr 21, 2010, at 3:32 PM, Bastien wrote:
>>
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>
>>>> do others agree with Matti's view?
>>>
>>> FWIW, I do.
>>
>> There is still another difference.
>>
>> Currently, when I execute the indentation command
>> several times in a row, the range to which this applies
>> is locked.
>>
>> So for example"
>>
>> - level 1a
>> - level 2a
>> - level 2b
>> - level 2c
>> - level 1b
>>
>> If I now go on level 1a and use M-S-left, level 1b becomes a sibling
>> of 2c. If I immediately after this do M-S-right, 1b should be
>> indented
>> along with 2c, but this does not happen because the item range is
>> locked. If, however, you do something in between, like moving the
>> cursor by one character, 1b will be included.
>>
>> I believe I did this a long time ago, because I felt that not locking
>> the range for commands in direct succession would too quickly modify
>> the structure, including at places outside of the current view (
>> beyond the window end)
>>
>> If you are calling for more consistency, maybe this "feature" should
>> go as well?
>>
>> - Carsten
>>
>>
- Carsten
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-21 21:07 ` Carsten Dominik
@ 2010-04-22 10:15 ` Bastien
2010-04-22 20:37 ` Matti De Craene
2010-04-23 8:26 ` Carsten Dominik
0 siblings, 2 replies; 17+ messages in thread
From: Bastien @ 2010-04-22 10:15 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Matti De Craene
Carsten Dominik <carsten.dominik@gmail.com> writes:
> Excellent question. I think the cleanest would be that M-left/right
> on a folded item that does have children throws an error.
+1
--
Bastien
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-22 10:15 ` Bastien
@ 2010-04-22 20:37 ` Matti De Craene
2010-04-23 8:26 ` Carsten Dominik
1 sibling, 0 replies; 17+ messages in thread
From: Matti De Craene @ 2010-04-22 20:37 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode, Carsten Dominik
Hello Carsten, Bastien, others,
>> Excellent question. I think the cleanest would be that M-left/right
>> on a folded item that does have children throws an error.
I see two alternatives to showing an error:
(a) First unfold, then proceed with M-left/right
(b) Act as if M-S-left/right was called ( = current behaviour of
folded list items)
Personally, I like (a) somewhat more than showing error. Then again,
in most cases I would manually unfold first anyway to see what's below
the parent.
Matti
On Thu, Apr 22, 2010 at 12:15 PM, Bastien <bastien.guerry@wikimedia.fr> wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Excellent question. I think the cleanest would be that M-left/right
>> on a folded item that does have children throws an error.
>
> +1
>
> --
> Bastien
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-22 10:15 ` Bastien
2010-04-22 20:37 ` Matti De Craene
@ 2010-04-23 8:26 ` Carsten Dominik
2010-04-26 22:07 ` Matti De Craene
1 sibling, 1 reply; 17+ messages in thread
From: Carsten Dominik @ 2010-04-23 8:26 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode, Matti De Craene
On Apr 22, 2010, at 12:15 PM, Bastien wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Excellent question. I think the cleanest would be that M-left/right
>> on a folded item that does have children throws an error.
>
> +1
This is how it now works.
>
> --
> Bastien
- Carsten
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-23 8:26 ` Carsten Dominik
@ 2010-04-26 22:07 ` Matti De Craene
2010-04-27 5:57 ` Carsten Dominik
0 siblings, 1 reply; 17+ messages in thread
From: Matti De Craene @ 2010-04-26 22:07 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Bastien
Thank you Carsten!
--
I think I noticed one small bug - possibly introduced by this change.
Minimal example:
* test
- item a
- item b
Then:
M-Right / M-left is not possible on list item b, if that item is on
the last line of the org file. (M-S-Left/Right are possible)
Kind Regards,
Matti
On Fri, Apr 23, 2010 at 10:26 AM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
>
> On Apr 22, 2010, at 12:15 PM, Bastien wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Excellent question. I think the cleanest would be that M-left/right
>>> on a folded item that does have children throws an error.
>>
>> +1
>
>
> This is how it now works.
>
>>
>> --
>> Bastien
>
> - Carsten
>
>
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Patch] M-Right and M-Left behave differently on headings and list items
2010-04-26 22:07 ` Matti De Craene
@ 2010-04-27 5:57 ` Carsten Dominik
0 siblings, 0 replies; 17+ messages in thread
From: Carsten Dominik @ 2010-04-27 5:57 UTC (permalink / raw)
To: Matti De Craene; +Cc: emacs-orgmode, Bastien
On Apr 27, 2010, at 12:07 AM, Matti De Craene wrote:
> Thank you Carsten!
>
> --
> I think I noticed one small bug - possibly introduced by this change.
>
> Minimal example:
>
> * test
> - item a
> - item b
>
> Then:
> M-Right / M-left is not possible on list item b, if that item is on
> the last line of the org file. (M-S-Left/Right are possible)
Yes, thank your for your report - fixed now.
- Carsten
>
> Kind Regards,
>
> Matti
>
>
> On Fri, Apr 23, 2010 at 10:26 AM, Carsten Dominik
> <carsten.dominik@gmail.com> wrote:
>>
>> On Apr 22, 2010, at 12:15 PM, Bastien wrote:
>>
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>
>>>> Excellent question. I think the cleanest would be that M-left/
>>>> right
>>>> on a folded item that does have children throws an error.
>>>
>>> +1
>>
>>
>> This is how it now works.
>>
>>>
>>> --
>>> Bastien
>>
>> - Carsten
>>
>>
>>
>>
- Carsten
^ permalink raw reply [flat|nested] 17+ messages in thread