Re: [O] M-RET vs C-RET

[Rasmus]

Nicolas Goaziou <address@hidden> writes:

> Rasmus <address@hidden> writes:
>
>> I don't have a grand vision, but, ideally, I'd want M-RET to "do the
>> right thing", which is my book is often create an element similar to
>> element at point, and is certainly not but my #+begin_src emacs-lisp
>> code on a headline.  I agree the logical action is to the eye of the
>> beholder.  To me, some elements have a very clear-cut "next logical
>> thing" (item, headline, white space (headline), some keywords, maybe
>> tables), others don't (e.g. src-blocks and export blocks.).  IMO, we can
>> disable most of element-actions (literately keywords and tables) out of
>> the box, much like e.g. `scroll-left'.
>
> It would be nice to have complete specifications of "do the right
> thing".

I agree.

Some quick thoughts:

babel-call → maybe insert new call line?
comment → new commented line?
Drawer, property-drawer → insert new drawer template?
fixed-width → clone :
headline → `org-insert-headline'
inlinetask → insert new inlinetask? 
item → `org-insert-headline'
keyword → `org-insert-keyword' but doesn't cover all keywords...
paragraph → `org-insert-headline'
plain-list → `org-insert-headline'
table-row → what it does now

No clue:

center-block → 
clock →
comment-block → 
diary-sexp →
dynamic-block → 
example-block → 
export-block → 
horizontal-rule →
latex-environment →
node-property →
planning → 
quote-block → 
special-block →
src-block →
table →
verse-block → 

I agree that if there exited a "list of rights things to do", and it was
implemented, it may not be optimal to put it on M-RET [I'm not
sure]. . .

> Also, it is important to have a way to insert a headline whatever is
> around, and one to insert a headline at the end of the current section
> or even great-parent.

For the two latter: I only learned about the current possibility of
doing this reading the docstring of `org-insert-headline'.  I haven't
used it, and I don't think it's immediately helpful to me, but who
knows.

> Currently C-RET is sub-optimal since it is equivalent to C-u M-RET. It
> might be possible to re-define both M-RET and C-RET so they can cover
> all use-cases in a predictable, and meaningful, fashion.

Would be cool.

>> Here's another of my pet-griefs
>> - a
>> - b
>>
>> | → M-RET will give me an itme 
>> | → M-RET will give me a headline
>>
>> Why is the behavior a function of amount of whitespace/newlines to
>> nearest element?  This makes not sense to me and goes against what I
>> want, namely act in accordance to element at point. . .
>
> Blank lines belong to the element at point above.
>
> In particular, number of blank lines is meaningful in plain lists and
> footnote definitions (2 blank lines mark the end of the element). In
> the first line, you're still in the list, in the next one, you're not
> anymore, hence the behaviour.
>
> Think about
>
>   - a
>
>   - b

/I/ know why it does what it does.  But how about the guy who's been
using Org for five minutes?  Even knowing the technical/syntax reason, I
do not find this to be "predictable, and meaningful"—especially in my
initial example, less so when separating items by two lines.

Cheers,
Rasmus

-- 
Don't panic!!!