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!!!
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. . .
Re: [O] M-RET and C-RET turn current line of text into a heading?
On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com wrote: Hi, My user input is partially to blame for this, I think. See toward the end of this thread: http://comments.gmane.org/gmane.emacs.orgmode/69794 I was under the impression that the behavior of M-RET had changed, but I may have given a wrong or incomplete description of the old behavior I seemed to remember and wanted back. I agree that the current behavior does not seem ideal either. Here's some more misguided user input: Wouldn't it be intuitive if M-RET at the beginning of a line turned that line into a heading (as it currently does), but M-RET at the end of a line inserted a new heading below (would require a change from the current workings)? Not sure about M-RET somewhere in the middle of a line. I've been following this thread and there has been some great discussion about future plans for re-write and context-sensitive functionality. In the mean time, can we revert the C-RET behavior back to adding a new headline? I'm finding it incredibly frustration to have no way to just add a new headline below the current contents of a headline, even if it's folded. I'm adding some individuals to my contact file and have no way to just M-RET or C-RET to add a new headline quickly except to navigate and manually type a series of *'s. If we could return one of these to the old functionality, that would be great. (Or a recommended new way to just add a headline vs. transforming the last line into a header.) Thanks, John Yours, Christian Eric Abrahamsen writes: For the past couple of weeks I'm finding that both M-RET and C-RET turn the line under point into a heading, instead of inserting a new heading elsewhere. This happens with `org-M-RET-may-split-line' set to anything. So this: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: In which not [point is here] very much happens. But this is a further test to see what happens on multiline text. #+end_src becomes: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: * In which not very much happens. But this is a further test to see what happens on multiline text. #+end_src This also happens with emacs -Q. Has no one else seen this? Thanks, Eric
Re: [O] M-RET and C-RET turn current line of text into a heading?
On Mon, May 20, 2013 at 10:54 AM, John Hendy jw.he...@gmail.com wrote: On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com wrote: Hi, My user input is partially to blame for this, I think. See toward the end of this thread: http://comments.gmane.org/gmane.emacs.orgmode/69794 I was under the impression that the behavior of M-RET had changed, but I may have given a wrong or incomplete description of the old behavior I seemed to remember and wanted back. I agree that the current behavior does not seem ideal either. Here's some more misguided user input: Wouldn't it be intuitive if M-RET at the beginning of a line turned that line into a heading (as it currently does), but M-RET at the end of a line inserted a new heading below (would require a change from the current workings)? Not sure about M-RET somewhere in the middle of a line. I've been following this thread and there has been some great discussion about future plans for re-write and context-sensitive functionality. In the mean time, can we revert the C-RET behavior back to adding a new headline? I'm finding it incredibly frustration to have no way to just add a new headline below the current contents of a headline, even if it's folded. I'm adding some individuals to my contact file and have no way to just M-RET or C-RET to add a new headline quickly except to navigate and manually type a series of *'s. If we could return one of these to the old functionality, that would be great. (Or a recommended new way to just add a headline vs. transforming the last line into a header.) Sorry for the noise. I think I just pulled on Friday, but a pull just now and re-make seems to have returned C-RET to doing what I thought it should. I may have pulled and never restarted my emacs session, so it's quite possible this was fixed earlier. Thanks for that! John Thanks, John Yours, Christian Eric Abrahamsen writes: For the past couple of weeks I'm finding that both M-RET and C-RET turn the line under point into a heading, instead of inserting a new heading elsewhere. This happens with `org-M-RET-may-split-line' set to anything. So this: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: In which not [point is here] very much happens. But this is a further test to see what happens on multiline text. #+end_src becomes: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: * In which not very much happens. But this is a further test to see what happens on multiline text. #+end_src This also happens with emacs -Q. Has no one else seen this? Thanks, Eric
Re: [O] M-RET and C-RET turn current line of text into a heading?
John Hendy jw.he...@gmail.com writes: On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com wrote: I've been following this thread and there has been some great discussion about future plans for re-write and context-sensitive functionality. In the mean time, can we revert the C-RET behavior back to adding a new headline? I'm finding it incredibly frustration to have no way to just add a new headline below the current contents of a headline, even if it's folded. I'm adding some individuals to my contact file and have no way to just M-RET or C-RET to add a new headline quickly except to navigate and manually type a series of *'s. If we could return one of these to the old functionality, that would be great. (Or a recommended new way to just add a headline vs. transforming the last line into a header.) Sorry for the noise. I think I just pulled on Friday, but a pull just now and re-make seems to have returned C-RET to doing what I thought it should. I may have pulled and never restarted my emacs session, so it's quite possible this was fixed earlier. That's curious. It has not been fixed here with the latest git. I reported this in another thread: http://permalink.gmane.org/gmane.emacs.orgmode/72399 Sorry to have missed this thread. Matt
Re: [O] M-RET and C-RET turn current line of text into a heading?
On Mon, May 20, 2013 at 11:14 AM, Matt Lundin m...@imapmail.org wrote: John Hendy jw.he...@gmail.com writes: On Wed, May 15, 2013 at 2:54 AM, Christian Moe m...@christianmoe.com wrote: I've been following this thread and there has been some great discussion about future plans for re-write and context-sensitive functionality. In the mean time, can we revert the C-RET behavior back to adding a new headline? I'm finding it incredibly frustration to have no way to just add a new headline below the current contents of a headline, even if it's folded. I'm adding some individuals to my contact file and have no way to just M-RET or C-RET to add a new headline quickly except to navigate and manually type a series of *'s. If we could return one of these to the old functionality, that would be great. (Or a recommended new way to just add a headline vs. transforming the last line into a header.) Sorry for the noise. I think I just pulled on Friday, but a pull just now and re-make seems to have returned C-RET to doing what I thought it should. I may have pulled and never restarted my emacs session, so it's quite possible this was fixed earlier. That's curious. It has not been fixed here with the latest git. Very curious! Your thread is exactly what I was experiencing before my pull/make clean/make this morning. Now I'm on: Org-mode version 8.0.3 (release_8.0.3-139-g419b69 @ /home/jwhendy/.elisp/org.git/lisp/) It's working and I verified it several times to make sure. Indeed, as with you, the most frustrating was it turning the last line of a folded headline into a new headline while staying sort of folded (or, for me, even bumping the ellipsis down below the current headline so one couldn't unfold it anymore). I guess I'm not sure what to say. I am experiencing what I would expect since my last pull, so I don't really feel compelled to re-pull to see if it's re-broken! Best regards, John I reported this in another thread: http://permalink.gmane.org/gmane.emacs.orgmode/72399 Sorry to have missed this thread. Matt
Re: [O] M-RET and C-RET turn current line of text into a heading?
On 16.5.2013, at 21:11, Jason F. McBrayer jmcb...@carcosa.net wrote: Bastien b...@gnu.org writes: Thanks a lot Samuel for writing this. Just a quick note to tell you that this discussion *is* important, and well read, as we plan to rewrite those functions. Presenting features wrt contexts so clearly is great -- thanks for doing this. Another thing to take into account in the rewrite is doing the right thing even when electric-indent-mode or electric-layout-mode are enabled. The current implementation is not compatible with electric-indent-mode. Never heard about these - need to look them up. - Carsten -- +---+ | Jason F. McBrayerjmcb...@carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada|
Re: [O] M-RET and C-RET turn current line of text into a heading?
Hi everyone, yes, thanks for making this table, Samuel. I think the functionality is a bit overkill, in particular the implementation with pressing M-RET twice for special functionality. This becomes too confusing, I think. The elementary function of M-RET is continue in the current list/outline. C-RET is a way to get out of list environments and to get a new heading. Both are entirely necessary when taking notes, IMO. So I would propose the following adapted version of Samuel's table: |-+--++| | command | context | pos| action | |-+--++| | c-ret | any | any| create headline below entry| | m-ret | headline or item | beg| create new above header/item | | m-ret | headline or item | middle | split | | m-ret | headline or item | end| create new below header/item | | m-ret | line | beg| turn into headline, this is| | | || just a special case of split | | m-ret | line | middle | turn rest of line into heading | | m-ret | line | end| new heading after line | | C-o M-ret | line | beg| new heading before line| |-+--++| There was discussion about `C-c *'. For me the main application of this command it to turn an item into a headline, and to turn *several* lines into a series of headline (by selecting the lines first) - this is a very frequent application when I paste text that I then need to structure. Nobody mentioned this in this thread, so maybe this feature is not known well enough. - Carsten
Re: [O] M-RET and C-RET turn current line of text into a heading?
Carsten Dominik carsten.domi...@gmail.com writes: On 16.5.2013, at 21:11, Jason F. McBrayer jmcb...@carcosa.net wrote: Another thing to take into account in the rewrite is doing the right thing even when electric-indent-mode or electric-layout-mode are enabled. The current implementation is not compatible with electric-indent-mode. Never heard about these - need to look them up. I think they were introduced in Emacs 24, to replace globally the various hacks people were using previously. I found a workaround online at [[http://foldl.me/2012/disabling-electric-indent-mode/][foldl]]. -- +---+ | Jason F. McBrayerjmcb...@carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada|
Re: [O] M-RET and C-RET turn current line of text into a heading?
On Fri, May 17, 2013 at 03:26:09PM +0200, Carsten Dominik wrote: There was discussion about `C-c *'. For me the main application of this command it to turn an item into a headline, and to turn *several* lines into a series of headline (by selecting the lines first) - this is a very frequent application when I paste text that I then need to structure. Nobody mentioned this in this thread, so maybe this feature is not known well enough. I use `C-c *' and `C-c -' to turn lists - headlines all the time...
Re: [O] M-RET and C-RET turn current line of text into a heading?
Samuel Wales samolog...@gmail.com writes: |-+--++--| | command | context | pos| action | |-+--++--| | c-ret | any | any| create headline above ENTRY | | m-ret | headline or item | beg| create new above header/item | | m-ret | headline or item | middle | split| | m-ret | headline or item | end| create new below header/item | | m-ret | line | beg| create headline above LINE | | m-ret twice | line | beg| create item above line | | m-ret | line | middle | turn line into a headline| | m-ret twice | line | middle | turn line into an item | | m-ret | line | end| create headline below line | | m-ret twice | line | end| create item below line | |-+--++--| Thanks a lot Samuel for writing this. Just a quick note to tell you that this discussion *is* important, and well read, as we plan to rewrite those functions. Presenting features wrt contexts so clearly is great -- thanks for doing this. -- Bastien
Re: [O] M-RET and C-RET turn current line of text into a heading?
Hi! I still think it's pretty important to have an option for creating a new headline *below* all the contents of the current subtree -- what C-RET used to do. I like to second, that there needs to be a short key binding to insert a new headline below the current entry when the context is in the middle. (Could be C-M-RET or at least C-u C-RET, although I'm very used to type C-RET for doing that.). Regards, Daniel Bausch
Re: [O] M-RET and C-RET turn current line of text into a heading?
On Thu, 16 May 2013 09:22:30 +0200 Daniel Bausch danielbau...@gmx.de wrote: Hi! I still think it's pretty important to have an option for creating a new headline *below* all the contents of the current subtree -- what C-RET used to do. I like to second, that there needs to be a short key binding to insert a new headline below the current entry when the context is in the middle. (Could be C-M-RET or at least C-u C-RET, although I'm very used to type C-RET for doing that.). +1 Regards Detlef Regards, Daniel Bausch
Re: [O] M-RET and C-RET turn current line of text into a heading?
Once this gets implemented I'd really like to see the same table in org manual. It's a really good summary. Regards, Miro On Thu, May 16, 2013 at 8:21 AM, Bastien b...@gnu.org wrote: Samuel Wales samolog...@gmail.com writes: |-+--++--| | command | context | pos| action | |-+--++--| | c-ret | any | any| create headline above ENTRY | | m-ret | headline or item | beg| create new above header/item | | m-ret | headline or item | middle | split | | m-ret | headline or item | end| create new below header/item | | m-ret | line | beg| create headline above LINE | | m-ret twice | line | beg| create item above line | | m-ret | line | middle | turn line into a headline | | m-ret twice | line | middle | turn line into an item | | m-ret | line | end| create headline below line | | m-ret twice | line | end| create item below line | |-+--++--| Thanks a lot Samuel for writing this. Just a quick note to tell you that this discussion *is* important, and well read, as we plan to rewrite those functions. Presenting features wrt contexts so clearly is great -- thanks for doing this. -- Bastien
Re: [O] M-RET and C-RET turn current line of text into a heading?
Samuel Wales samolog...@gmail.com writes: Hi Eric, On 5/15/13, Eric Abrahamsen e...@ericabrahamsen.net wrote: I still think it's pretty important to have an option for creating a new headline *below* all the contents of the current subtree -- what C-RET used to do. This might be a good thing to make a user preference. Also, the above provides a whole lot of options for creating a new headline/item above the current line -- is that really such a common thing to do? It is for me. And the variable `org-M-RET-may-split-line' is still not taken into account... I don't see why it shouldn't be taken into account. You're right, I guess I just meant it wasn't explicit in your table. I like the use of double M-RETs, I think that can be useful. I still think C-RET should create a new heading at the end of the subtree. A user setting to that effect is fine with me. I'd be happy if C-RET at the beginning of a heading created a new headline above, but in the middle or at the end I think it should still jump down and make a new headline below all content. Just to register my usage, as a single data point: I make heavy use of both M-RET to create headings below point (very often to split a single run of paragraphs into two subtrees), and C-RET to make headings below subtree text. Very occasionally I use C-u C-u M-RET to make a bottom sibling. Very occasionally I use 'C-c *' to toggle heading. Just two cents. E
Re: [O] M-RET and C-RET turn current line of text into a heading?
On 2013-05-15 23:17, Eric Abrahamsen wrote: Samuel Wales samolog...@gmail.com writes: Also, C-RET and M-RET currently seem to be identical? I still think it's pretty important to have an option for creating a new headline *below* all the contents of the current subtree -- what C-RET used to do. Also, the above provides a whole lot of options for creating a new headline/item above the current line -- is that really such a common thing to do? Agreed. Personally, i rarely need to insert headlines/items above the current line. Actually, the thing I find myself wanting a key for is inserting a child headline between a headline and it's body text -- I often find myself wanting to break up a section into new sub-sections. e.g, turning #+BEGIN_SRC org * Headline para 1 para 2 #+END_SRC into #+BEGIN_SRC org * Headline ** Subhead 1 para 1 ** Subhead 2 para2 #+BEGIN_SRC org rick
Re: [O] M-RET and C-RET turn current line of text into a heading?
Eric Abrahamsen e...@ericabrahamsen.net writes: Samuel Wales samolog...@gmail.com writes: How about this? IMO this would be ideal. - M-RET is for the current context - C-RET is for a new context [...] I still think it's pretty important to have an option for creating a new headline *below* all the contents of the current subtree -- what C-RET used to do. +1. I do not like the new behaviour at all. C-RET is wired into my brain and I am used to using it *all* the time without worrying about where point actually is. I seldom use M-RET other than on items. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.2-103-gb3a88b
Re: [O] M-RET and C-RET turn current line of text into a heading?
Bastien b...@gnu.org writes: Thanks a lot Samuel for writing this. Just a quick note to tell you that this discussion *is* important, and well read, as we plan to rewrite those functions. Presenting features wrt contexts so clearly is great -- thanks for doing this. Another thing to take into account in the rewrite is doing the right thing even when electric-indent-mode or electric-layout-mode are enabled. The current implementation is not compatible with electric-indent-mode. -- +---+ | Jason F. McBrayerjmcb...@carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada|
Re: [O] M-RET and C-RET turn current line of text into a heading?
Hi, My user input is partially to blame for this, I think. See toward the end of this thread: http://comments.gmane.org/gmane.emacs.orgmode/69794 I was under the impression that the behavior of M-RET had changed, but I may have given a wrong or incomplete description of the old behavior I seemed to remember and wanted back. I agree that the current behavior does not seem ideal either. Here's some more misguided user input: Wouldn't it be intuitive if M-RET at the beginning of a line turned that line into a heading (as it currently does), but M-RET at the end of a line inserted a new heading below (would require a change from the current workings)? Not sure about M-RET somewhere in the middle of a line. Yours, Christian Eric Abrahamsen writes: For the past couple of weeks I'm finding that both M-RET and C-RET turn the line under point into a heading, instead of inserting a new heading elsewhere. This happens with `org-M-RET-may-split-line' set to anything. So this: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: In which not [point is here] very much happens. But this is a further test to see what happens on multiline text. #+end_src becomes: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: * In which not very much happens. But this is a further test to see what happens on multiline text. #+end_src This also happens with emacs -Q. Has no one else seen this? Thanks, Eric
Re: [O] M-RET and C-RET turn current line of text into a heading?
Christian Moe m...@christianmoe.com writes: Hi, My user input is partially to blame for this, I think. See toward the end of this thread: http://comments.gmane.org/gmane.emacs.orgmode/69749 I was under the impression that the behavior of M-RET had changed, but I may have given a wrong or incomplete description of the old behavior I seemed to remember and wanted back. I agree that the current behavior does not seem ideal either. Here's some more misguided user input: Wouldn't it be intuitive if M-RET at the beginning of a line turned that line into a heading (as it currently does), but M-RET at the end of a line inserted a new heading below (would require a change from the current workings)? Not sure about M-RET somewhere in the middle of a line. Hey, I'm all about misguided user input :) I read that brief thread, and it looks like there was a call for opinions that I missed! Better late than never... I don't see why `org-ctrl-c-star' -- `org-toggle-heading' isn't enough for creating headlines out of existing text. At the very least, we shouldn't now have three keystrokes (C-c *, M-RET, C-RET) that do the same thing! Also, `org-M-RET-may-split-line', which was once a very interesting variable, now does nothing since M-RET simply doesn't split the line. Or am I missing something about the new arrangement? However it falls out, I would love to have two commands back: one that starts a new heading under point, and one that starts a new heading at the end of the current subtree. Ie, what M-RET and C-RET used to do... Eric Yours, Christian Eric Abrahamsen writes: For the past couple of weeks I'm finding that both M-RET and C-RET turn the line under point into a heading, instead of inserting a new heading elsewhere. This happens with `org-M-RET-may-split-line' set to anything. So this: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: In which not [point is here] very much happens. But this is a further test to see what happens on multiline text. #+end_src becomes: #+begin_src org * Chapter One :PROPERTIES: :some_prop: t :END: * In which not very much happens. But this is a further test to see what happens on multiline text. #+end_src This also happens with emacs -Q. Has no one else seen this? Thanks, Eric
Re: [O] M-RET and C-RET turn current line of text into a heading?
Eric Abrahamsen writes: I don't see why `org-ctrl-c-star' -- `org-toggle-heading' isn't enough for creating headlines out of existing text. Fair point, but I find it useful to have a simpler and speedier combination, redundant or not. For instance, I often use Org to make structured documents out of plain text, text copy-pasted from PDFs etc., which involves scrolling through the document and repeatedly turning the lines at point into headings. It quickly becomes a nuisance to do this with a sequence of two double keypresses (`C-c *', that is, `C-c S-8' -- not to mention that I routinely switch between keyboards for three languages with somewhat different ideas where `*' should be). At the very least, we shouldn't now have three keystrokes (C-c *, M-RET, C-RET) that do the same thing! Also, `org-M-RET-may-split-line', which was once a very interesting variable, now does nothing since M-RET simply doesn't split the line. True. I think this needs to be revisited (before too many people get used to the recent arrangement). Yours, Christian
Re: [O] M-RET and C-RET turn current line of text into a heading?
Christian Moe m...@christianmoe.com writes: Eric Abrahamsen writes: I don't see why `org-ctrl-c-star' -- `org-toggle-heading' isn't enough for creating headlines out of existing text. Fair point, but I find it useful to have a simpler and speedier combination, redundant or not. For instance, I often use Org to make structured documents out of plain text, text copy-pasted from PDFs etc., which involves scrolling through the document and repeatedly turning the lines at point into headings. It quickly becomes a nuisance to do this with a sequence of two double keypresses (`C-c *', that is, `C-c S-8' -- not to mention that I routinely switch between keyboards for three languages with somewhat different ideas where `*' should be). At the very least, we shouldn't now have three keystrokes (C-c *, M-RET, C-RET) that do the same thing! Also, `org-M-RET-may-split-line', which was once a very interesting variable, now does nothing since M-RET simply doesn't split the line. True. I think this needs to be revisited (before too many people get used to the recent arrangement). Ugh, I've had plenty of experience trying to impose structure on unstructured text. PDF copy-n-paste is a nightmare, particular where columns were involved. However! Having a useful set of commands is one thing, and having useful keybindings for those commands is another. M-RET/C-RET are still pretty crucial for taking notes out of thin air. They each have their own behavior when point is at beginning, middle, and end of line, as well, and I'd hope that all would be left in place. `org-ctrl-c-star' either calls `org-table-recalculate' or `org-toggle-heading', which are strange bedfellows. The key chord seems much more tied to table recalculation (there are multiple various behaviors triggered by prefix args) than to heading toggling. We might consider splitting `org-toggle-heading' off onto its own key. Or perhaps it would be enough tweak keybindings? Maybe leave the current bindings and behavior of `org-ctrl-c-star', but add the fat finger bindings of 'C-c 8' and 'C-c C-8' to `org-ctrl-c-star' (or even bind them directly to `org-toggle-heading'). It would be inelegant, but that way you could park a pinkie on the control key, and travel through a buffer with 'C-s' or '(C-u, C-digit) C-n', hitting 'C-c C-8' as needed. Just one possibility, E
Re: [O] M-RET and C-RET turn current line of text into a heading?
How about this? IMO this would be ideal. - M-RET is for the current context - C-RET is for a new context |-+--++--| | command | context | pos| action | |-+--++--| | c-ret | any | any| create headline above ENTRY | | m-ret | headline or item | beg| create new above header/item | | m-ret | headline or item | middle | split| | m-ret | headline or item | end| create new below header/item | | m-ret | line | beg| create headline above LINE | | m-ret twice | line | beg| create item above line | | m-ret | line | middle | turn line into a headline| | m-ret twice | line | middle | turn line into an item | | m-ret | line | end| create headline below line | | m-ret twice | line | end| create item below line | |-+--++--| Notes: - C-RET (in all contexts) creates new headline ABOVE (not below) the current entry - beg does not only refer to beginning of line. it also refers to the blank spaces before a list item or stars and space in a headline I should mention that M-RET still takes several seconds. Also, C-RET and M-RET currently seem to be identical? Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] M-RET and C-RET turn current line of text into a heading?
Hi Eric, On 5/15/13, Eric Abrahamsen e...@ericabrahamsen.net wrote: I still think it's pretty important to have an option for creating a new headline *below* all the contents of the current subtree -- what C-RET used to do. This might be a good thing to make a user preference. Also, the above provides a whole lot of options for creating a new headline/item above the current line -- is that really such a common thing to do? It is for me. And the variable `org-M-RET-may-split-line' is still not taken into account... I don't see why it shouldn't be taken into account. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Re: [O] M-RET and C-RET
Please keep in mind that C-ret is not an ascii or 8-bit character (or even a character, really), so people using emacs in an xterm (rather than via X) do not have C-ret available. In general I find that org mode becomes a little awkward in a terminal due to usage of ungeneratable characters. pgpCicp38AtwY.pgp Description: PGP signature
Re: [O] M-RET and C-RET
Hello, Michael Brand michael.ch.br...@gmail.com writes: 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? Maybe nothing. I may be missing your point. Though, from what I read, I think that you really mean to argue for a change of the default value of `org-M-RET-may-split-line' (to, i.e. '((default . t) (item))) not for a change of code. 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. I'm not talking about your cursor shape, but about Emacs' point representation. Point is never on j in Emacs, whatever you want to prefer. To convince yourself, you can experiment with: M-: (char-to-string (char-after (point))) 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? I don't like it when I consider the line: - jkl. It means that the new behaviour you suggest (adding an item below the current one) would only happen in one precise position on the line: just before the j. Calling M-RET anywhere before that would create the item above, and anywhere after it would split the line (by default). I fail to see any logic here: point is still before the contents of the item, but M-RET adds a new item below nonetheless. I would call that a convenient hack. But it's just me. Moreover, with `org-M-RET-may-split-line' set to nil (at least for items), this hack is totally useless, as there's plenty of room to call M-RET from (like the end of _line_) when one wants to add an item below. So again, aren't you arguing for a change of `org-M-RET-may-split-line' value instead? 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? Certainly, but not with the more simple choice, despite what you claimed at the beginning of this message. Again: - Actually, M-RET before item's body creates an item before, and it splits body otherwise. - Your suggestion: M-RET before item's bullet creates and item before, M-RET between item's bullet and item's body (which may be reduced to one position only) creates an item after, and it splits body otherwise. I can see the consistency with headlines, but not the simplicity. Also, from my obviously biased point of view, I could argue that you may modify headlines' behaviour to be more consistent with plain lists instead ;) 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). Again, your suggestion may not be totally wrong,
Re: [O] M-RET and C-RET
Hi Nicolas Thank you for all the explanations. On Sun, Dec 4, 2011 at 11:33, Nicolas Goaziou n.goaz...@gmail.com wrote: Though, from what I read, I think that you really mean to argue for a change of the default value of `org-M-RET-may-split-line' (to, i.e. '((default . t) (item))) not for a change of code. With my better understanding of the insert anchor (see below): Yes. I'm not talking about your cursor shape, but about Emacs' point representation. Point is never on j in Emacs, whatever you want to prefer. To convince yourself, you can experiment with: M-: (char-to-string (char-after (point))) Interesting. At least when referring with the word point I better switch... I fail to see any logic here: point is still before the contents of the item, but M-RET adds a new item below nonetheless. I would call that a convenient hack. But it's just me. Finally I got it and this lets me readjust my opinion too. Before I could only think of the list item bullet as the insert anchor for the decision whether to insert above or below. Now I realize that there is also the different and also valid perspective to have just the first character of the item text as this insert anchor. Moreover, with `org-M-RET-may-split-line' set to nil (at least for items), this hack is totally useless, as there's plenty of room to call M-RET from (like the end of _line_) when one wants to add an item below. So again, aren't you arguing for a change of `org-M-RET-may-split-line' value instead? With my better understanding of the insert anchor: Yes. I can see the consistency with headlines, but not the simplicity. Also, from my obviously biased point of view, I could argue that you may modify headlines' behaviour to be more consistent with plain lists instead ;) Indeed. Seriously, for me this would now be the better way to go to increase consistency, if this is of a broader interest than only mine. Then the documentation with regards to that variable may be defective. How do you think it can be improved? I don't see a problem with the doc itself. More with me not reading and remembering the right thing at the right time. But your suggestion to change the default of org-M-RET-may-split-line seems the right thing to me. My vote for the _default_ is (defcustom org-M-RET-may-split-line '((default . t) (item)) Who is interested to vote for a default? The Org-mode customization survey from January 2009 on Worg showed only one user differing from the default still in use: nil for headline (John Wiegley, CCed). The other 35 had the default (I claim that some of them don't care). With a default of nil for item I would not have followed the wrong path of using - and TAB to insert list items and not have made the noise related to this and more. Michael
Re: [O] M-RET and C-RET
Hello, Michael Brand michael.ch.br...@gmail.com 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. 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. You shouldn't compare lists and headlines behaviour, they don't have the same constraints. Changing to the behavior expected by me would make it possible to add a new list item below the last one in a list (a very frequent task) Go to the end of the last item, and use M-RET. If it is really frequent, the following function will do what you want: #+begin_src emacs-lisp (defun org-insert-item-at-end (optional arg) Insert a new list item at the end of the current list. When optional argument ARG is non-nil, add a check-box to the item. (interactive P) (let ((itemp (org-in-item-p))) (unless itemp (error Not in an item)) (goto-char (org-in-item-p)) (let* ((struct (org-list-struct)) (prevs (org-list-prevs-alist struct))) ;; Move to the end of the last item in list, before any white ;; space, and insert item there. (goto-char (org-list-get-item-end (org-list-get-last-item itemp struct prevs) struct)) (skip-chars-backward \r\t\n) ;; Repair list. (setq struct (org-list-insert-item (point) struct prevs arg)) (org-list-write-struct struct (org-list-parents-alist struct)) ;; Take care of check-boxes count, if needed. (when arg (org-update-checkbox-count-maybe)) ;; Position point at body's start. (looking-at org-list-full-item-re) (goto-char (match-end 0) #+end_src 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? 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. Regards, -- Nicolas Goaziou
Re: [O] M-RET and C-RET
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 n.goaz...@gmail.com wrote: Michael Brand michael.ch.br...@gmail.com 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
Re: [O] M-RET and C-RET
Hi all Now that I use M-RET more often when editing lists I was about trying to make a patch to remove what seems to me an inconsistency between headings and list items. But after I have read the docstrings of org-insert-item and org-list-insert-item the current behavior seems so intentional that I must have just missed some good reasons. Which are they? With #+begin_src org ,*** abc ,*** def ,- ghi ,- jkl #+end_src M-RET on e or on k splits the line, ok. M-RET on the first * (here also C-RET) or on - inserts a line above, ok. M-RET on d inserts a line _below_ (and C-RET _below_ the end of the whole entry), ok. 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. Changing to the behavior expected by me would make it possible to add a new list item below the last one in a list (a very frequent task) without caring about configuring org-M-RET-may-split-line away from its default. 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. 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 Another inconsistency in my view: Since M-RET inserts above when on - or before I would like to see M-RET and C-RET also insert above when on the last * (or single visible * when hidestars) or before, not only on the first * of the line. Michael On Sat, Nov 26, 2011 at 20:53, sindikat sindi...@mail36.net wrote: You can use M-RET-may-split-line, to make it respect content in lists, more or less. I would guess the reason that they are different is to be able to always easily start a new heading. This is very helpful, thank you. But how to make it so M-RET will: 1. not split line; 2. add new list item while on plain list; AND 3. add new heading after content of the current heading? Maybe there should be a variable in addition to 'org-M-RET-may-split-line' such as 'org-M-RET-add-after-content'. [...]
Re: [O] M-RET and C-RET
On Fri, 25 Nov 2011 17:49:09 +0100, sindikat sindi...@mail36.net wrote: Hello everyone, M-RET works with both headings and plainlists, it's DWIM. C-RET works only with headings. I wanted to ask, why C-RET is not DWIM? Wouldn't users want to add new list item respecting the content? You can use M-RET-may-split-line, to make it respect content in lists, more or less. I would guess the reason that they are different is to be able to always easily start a new heading. Tom
