Re: M-RET and C-RET

[Michael Brand <michael.ch.brand@gmail.com>]

Hi Nicolas

I try to argue for some supposed common Org user that likes it simple
like me, is used to the behavior of M-RET and C-RET on headings and
is about to learn to use lists and M-RET but doesn't want to know
about org-M-RET-may-split-line that he prefers to leave on its default
as typical for trying out step by step. I don't argue for myself, I
had already found out and understand how to configure and how to do.
But if M-RET with point on "j" would insert _below_:
1) it would be simpler to understand (from the user view, not
   necessarily for implementation but often there too) because also
   M-RET with point on "d" inserts already below
2) it would make possible to add a new list item below the last with
   M-RET already with the default org-M-RET-may-split-line or even
   emacs -Q
I can not see anything that could not be done with this that can be
done now. What am I missing?

On Sat, Dec 3, 2011 at 11:24, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Michael Brand <michael.ch.brand@gmail.com> writes:
>> With
>>
>> #+begin_src org
>>   ,*** abc
>>   ,*** def
>>   ,    - ghi
>>   ,    - jkl
>> #+end_src
>>
>> M-RET on "j" inserts a line above but I expected it below. If I
>> want a line above I would move the point to "-" before doing M-RET
>> like I do on a heading where I move to the first "*" to get the insert
>> above.
>
> Point isn't on "j". It's either before or after it. In your case, point
> is before "j".

When I wrote this I exactly asked myself which of these two
perspectives I want to choose:
- "point is before 'j'":
  - in some cases it leaves the question open if it means just before
    or rather between something (e. g. beginning of line) and "j"
  - sounds to me like referring to an edit cursor shape that is a bar
    between characters which is not the cursor shape of all users
- "point is on 'j'":
  - can refer to the position of point in the buffer like with "C-x ="
    or the Emacs Lisp functions "point" and some "point-*"
  - can refer to the character address or fsetpos() position in the
    corresponding file
  - can refer to an edit cursor shape that is a box on a character
    (the only possibility for some terminal emulators and the default
    for the windowed GNU Emacs on Linux, Mac OS X and Solaris)
I hope that this explains my preference for the second.

> And using M-RET on an item before its body start will
> result in creating an item before it.
>
> This is done so to avoid splitting counters or check-boxes.

I don't understand this. What would be wrong with
- point on "-": M-RET inserts above
- point on "[X]": M-RET inserts below
  (consistent with point on TODO on a line "*** TODO def")
- point on "j": M-RET inserts below
- point on "kl": M-RET splits (default config)
when considering the line "    - [X] jkl"?

> You shouldn't compare lists and headlines behaviour, they don't have the
> same constraints.

Nevertheless, wouldn't point 1) at the top add more consistency?

>> I configured it to nil for headline and item only to be able to insert
>> a new list item below the current with M-RET where I am forced to be
>> on or at right of "k" which by default splits which I want only in
>> very rare cases.
>
> If you want to split lines only on very rare occasions, why is it
> a problem to set `org-M-RET-may-split-line' to nil?

Not a problem for me, trying to simplify for others, see at the top
and also its point 2).

>> And one should not be invited to avoid M-RET and edit lists with "-"
>> and TAB as illustrated in the thread "org-list-indent-offset only
>> works partially": http://thread.gmane.org/gmane.emacs.orgmode/47954
>
> Which part of the thread are you referring to? I see no suggestion about
> avoiding usage of M-RET.

I'm sorry for the confusion and hope it becomes clearer this way:

As illustrated in the thread "org-list-indent-offset only works
partially" here
http://thread.gmane.org/gmane.emacs.orgmode/47954
one should not insert list items by editing with "-" and TAB but use
M-RET.

What I meant with the "invitation to avoid M-RET" is that until I
understood better a few weeks ago I used "-" and TAB to insert a new
item below the current line because more or less intentionally I left
org-M-RET-may-split-line at its default and because
- M-RET did not let me add a new list item below the last, and the
  relation to org-M-RET-may-split-line was not obvious for me
- when I wanted to insert a new list item below the current line I
  didn't like (maybe silly, I know) to move to the next item to be
  able to use M-RET to insert above from there

Michael