Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Rasmus <ras...@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".
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!!!
