Re: M-RET and C-RET

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

Michael Brand <michael.ch.brand@gmail.com> writes:

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

Maybe nothing. I may be missing your point. Though, from what I read,
I think that you really mean to argue for a change of the default value
of `org-M-RET-may-split-line' (to, i.e. '((default . t) (item))) not for
a change of code.

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

I'm not talking about your cursor shape, but about Emacs' point
representation. Point is never on "j" in Emacs, whatever you want to
prefer. To convince yourself, you can experiment with:

               M-: (char-to-string (char-after (point)))

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

I don't like it when I consider the line: " - jkl".

It means that the new behaviour you suggest (adding an item below the
current one) would only happen in one precise position on the line: just
before the "j". Calling M-RET anywhere before that would create the item
above, and anywhere after it would split the line (by default).

I fail to see any logic here: point is still before the contents of the
item, but M-RET adds a new item below nonetheless. I would call that
a convenient hack. But it's just me.

Moreover, with `org-M-RET-may-split-line' set to nil (at least for
items), this hack is totally useless, as there's plenty of room to call
M-RET from (like the end of _line_) when one wants to add an item below.

So again, aren't you arguing for a change of `org-M-RET-may-split-line'
value instead?

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

Certainly, but not with the more simple choice, despite what you claimed
at the beginning of this message.

Again:

  - Actually, M-RET before item's body creates an item before, and it
    splits body otherwise.

  - Your suggestion: M-RET before item's bullet creates and item before,
    M-RET between item's bullet and item's body (which may be reduced to
    one position only) creates an item after, and it splits body
    otherwise.

I can see the consistency with headlines, but not the simplicity. Also,
from my obviously biased point of view, I could argue that you may
modify headlines' behaviour to be more consistent with plain lists
instead ;)

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

Again, your suggestion may not be totally wrong, but it's not
simplifying anything.

> 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

Then the documentation with regards to that variable may be
defective. How do you think it can be improved?

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

Well, even with a default `org-M-RET-may-split-line', M-RET M-DOWN
achieves the same result without requiring to move to the next
item. With a modified value, C-e M-RET will do the same.


Regards,

-- 
Nicolas Goaziou