Re: [Patch] M-Right and M-Left behave differently on headings and list items

[Carsten Dominik <carsten.dominik@gmail.com>]

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