Re: [O] M-RET vs C-RET
Hi, [ ... ] 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. Just to add to that side thread: I too fall regularly into that and have to undo, add more newlines and hit M-RET again. I have been using orgmode for quite some time and still this is not 'predictable' for me. Regards, Andreas
Re: [O] M-RET vs C-RET
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. 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,
Re: [O] M-RET vs C-RET
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!!!
[O] M-RET vs C-RET
Hello, In a similar vein to this thread, I've always wondered if the following is normal or not. Having such a file: --8---cut here---start-8--- ** TODO Research - Who are the competitors? - What are our product's advantages? - Target market - Elevator pitch| Check out with Laura... Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ** TODO Define priorities --8---cut here---end---8--- If I want to cut the task into 2 at the point of the cursor (vertical bar, after pitch), I thought doing M-RET or C-RET were the way to go. But: - M-RET inserts a new item in the list - C-RET inserts a new headline... but after the Lorem paragraph. That's only a minor annoyance to me. I often just undo, and type ** myself. If you think that the above is expected, just forget about this. Or, maybe, I do have to (un)set some variable? Best regards, Seb -- Sebastien Vauban
Re: [O] M-RET vs C-RET
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: In a similar vein to this thread, I've always wondered if the following is normal or not. Having such a file: ** TODO Research - Who are the competitors? - What are our product's advantages? - Target market - Elevator pitch| Check out with Laura... Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ** TODO Define priorities If I want to cut the task into 2 at the point of the cursor (vertical bar, after pitch), I thought doing M-RET or C-RET were the way to go. But: - M-RET inserts a new item in the list - C-RET inserts a new headline... but after the Lorem paragraph. One used to be able to type C-u M-RET and get a headline in the middle of the list, but this was changed in 6c9b3ad91f6d3758471d194b75cbbf7a1030e18b. Regards, -- Nicolas Goaziou
Re: [O] M-RET vs C-RET
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rasmus ras...@gmx.us writes: From my point of view, we can make every function tied to M-RET beyond `org-insert-headline' configurable and turned off by default. This may, however, also add confusion (why did M-RET work in X's Org but not in mine...). In this case, S-RET is a superior (as in less confusing) choice. I see. That's probably OK. Anyway, I assume M-RET on keywords is just a first step. So, what's the big picture? I think it would help to know the complete specifications of the M-RET you envision, as it could make more sense than the sum of its parts. You're the architect. I just submit an occasional patch or bug-fix (under much guidance). 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'. Sebastien Vauban sva-n...@mygooglest.com writes: Having such a file: ** TODO Research - [...] - Elevator pitch| Check out with Laura... Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod [...] If I want to cut the task into 2 at the point of the cursor (vertical bar, after pitch), I thought doing M-RET or C-RET were the way to go. 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. . . —Rasmus -- Need more coffee. . .
