Sorry, I should clarify that the C-RET functions as expected in the content of an entry, it is only problematic when it is called from the headline. All best, Leonard On 23 April 2014 22:42, Leonard Randall wrote: > Hi Bastien, > I just wanted to report an issue with this fix. In many use cases it makes > C-RET less useful, and renders the speedkeys command `i' useless. It makes > C-RET function much like M-RET, and it makes `i' insert headlines before > any content. > > So if I call C-RET in the middle of the following headline: > --- > ** Important Meeting > SCHEDULED: <2014-04-26 Sat 16:30> > headline content... > --- > I get: > --- > ** Important > > ** Meeting > SCHEDULED: <2014-04-26 Sat 16:00> > headline content... > --- > And when I use the speedkeys command `i' at the beginning, I get > --- > ** Important Meeting > > ** > SCHEDULED: <2014-04-26 Sat 16:00> > headline content... > --- > Both of these break the scheduling cookie and defeat the main purpose of > these commands. > > Reverting the change restores expected behavior in these cases, but then I > suppose we are left with York's problem. > > All best, > Leonard > > > On 22 April 2014 10:23, Bastien wrote: > >> Hi York, >> >> thanks for coming back to this. >> >> York Zhao writes: >> >> > What I meant was that with one prefix argument, the command >> > `org-insert-heading' should insert a new heading *before* the >> > current heading, not after. >> >> Actually, this has little to do with the prefix argument: when >> at the beginning of a heading or a list item, M-RET should add >> a new heading/item *before* the current heading/item. >> >> This is fixed now, thanks for reporting this, >> >> PS: Using C-u M-RET will force `org-insert-heading-respect-content' >> to `t', i.e. add the headline at the end of the subtree. As Nicolas >> noted, this is the same than C-RET. >> >> -- >> Bastien >> >> >