Re: M-RET vs C-RET

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Rasmus <rasmus@gmx.us> 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".

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.

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.

> 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

  |


Regards,