[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] M-RET and C-RET
From: |
Michael Brand |
Subject: |
Re: [O] M-RET and C-RET |
Date: |
Sat, 3 Dec 2011 17:58:23 +0100 |
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 <address@hidden> wrote:
> Michael Brand <address@hidden> 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