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

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

[Matti De Craene]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Hello all,

When operating on a heading, M-Right/M-Left promotes or demotes one
heading only, and M-S-Right/M-S-Left promotes or demotes an entire
subtree.

When operating on list items however, there is no distinction between
M-Right/M-Left and M-S-Right/M-S-Left. Both key combinations operate
on the current item and on all subitems

Example: No difference between M-Right and M-S-Right on item 1 below:
- item 1
    - item 2
    - item 3

I find this behaviour somewhat confusing.

Attached patch seems to fix that for me.

Kind Regards,

Matti

[-- Attachment #2: M-right-M-left-on-list-items.patch --]
[-- Type: text/x-patch, Size: 970 bytes --]

diff --git a/lisp/org-list.el b/lisp/org-list.el
index d3bfb6b..05793e7 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -975,12 +975,15 @@ I.e. to the text after the last item."
     (setq firstp (org-first-list-item-p))
     (save-excursion
       (setq end (and (org-region-active-p) (region-end)))
-      (if (memq last-command '(org-shiftmetaright org-shiftmetaleft))
+      (if (and (memq last-command '(org-shiftmetaright org-shiftmetaleft))
+	        (memq this-command '(org-shiftmetaright org-shiftmetaleft)))
 	  (setq beg org-last-indent-begin-marker
 		end org-last-indent-end-marker)
 	(org-beginning-of-item)
 	(setq beg (move-marker org-last-indent-begin-marker (point)))
-	(org-end-of-item)
+	(if (memq this-command '(org-shiftmetaright org-shiftmetaleft))
+	  (org-end-of-item)
+	  (org-end-of-line))
 	(setq end (move-marker org-last-indent-end-marker (or end (point)))))
       (goto-char beg)
       (setq ind-bul (org-item-indent-positions)

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Carsten Dominik]

Hi,

do others agree with Matti's view?

Thanks.

- Carsten

On Apr 20, 2010, at 12:29 AM, Matti De Craene wrote:

> Hello all,
>
> When operating on a heading, M-Right/M-Left promotes or demotes one
> heading only, and M-S-Right/M-S-Left promotes or demotes an entire
> subtree.
>
> When operating on list items however, there is no distinction between
> M-Right/M-Left and M-S-Right/M-S-Left. Both key combinations operate
> on the current item and on all subitems
>
> Example: No difference between M-Right and M-S-Right on item 1 below:
> - item 1
>    - item 2
>    - item 3
>
> I find this behaviour somewhat confusing.
>
> Attached patch seems to fix that for me.
>
> Kind Regards,
>
> Matti
> <M-right-M-left-on-list- 
> items.patch>_______________________________________________
> 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

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

[Sébastien Vauban]

Hi Carsten and Matti,

> do others agree with Matti's view?

Yes, for me.

> On Apr 20, 2010, at 12:29 AM, Matti De Craene wrote:
>
>> Hello all,
>>
>> When operating on a heading, M-Right/M-Left promotes or demotes one
>> heading only, and M-S-Right/M-S-Left promotes or demotes an entire
>> subtree.
>>
>> When operating on list items however, there is no distinction between
>> M-Right/M-Left and M-S-Right/M-S-Left. Both key combinations operate
>> on the current item and on all subitems
>>
>> Example: No difference between M-Right and M-S-Right on item 1 below:
>> - item 1
>>    - item 2
>>    - item 3
>>
>> I find this behaviour somewhat confusing.
>>
>> Attached patch seems to fix that for me.

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

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

[Anthony Lander]

On 10-Apr-21, at 8:53 AM, Carsten Dominik wrote:

> Hi,
>
> do others agree with Matti's view?
>

I agree. I think it would be better if the arrow keys behaved the same  
on a headline and on a list.

   -Anthony


> Thanks.
>
> - Carsten
>
> On Apr 20, 2010, at 12:29 AM, Matti De Craene wrote:
>
>> Hello all,
>>
>> When operating on a heading, M-Right/M-Left promotes or demotes one
>> heading only, and M-S-Right/M-S-Left promotes or demotes an entire
>> subtree.
>>
>> When operating on list items however, there is no distinction between
>> M-Right/M-Left and M-S-Right/M-S-Left. Both key combinations operate
>> on the current item and on all subitems
>>
>> Example: No difference between M-Right and M-S-Right on item 1 below:
>> - item 1
>>   - item 2
>>   - item 3
>>
>> I find this behaviour somewhat confusing.
>>
>> Attached patch seems to fix that for me.
>>
>> Kind Regards,
>>
>> Matti
>> <M-right-M-left-on-list- 
>> items.patch>_______________________________________________
>> 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
>
>
>
>
>
> _______________________________________________
> 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

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

[Bastien]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> do others agree with Matti's view?

FWIW, I do.

-- 
 Bastien

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

[Carsten Dominik]

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

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

[Bernt Hansen]

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

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

[Dan Davison]

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

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

[Matti De Craene]

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

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

[Carsten Dominik]

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

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

[Bastien]

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

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

[Carsten Dominik]

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

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

[Matti De Craene]

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
>

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

[Carsten Dominik]

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

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

[Carsten Dominik]

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

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

[Matti De Craene]

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

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

[Carsten Dominik]

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