Re: (org-insert-headline '(4)) should insert new headline before point

[Leonard Randall <leonard.a.randall@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

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 <bzg@gnu.org> wrote:

> Hi York,
>
> thanks for coming back to this.
>
> York Zhao <gtdplatform@gmail.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2426 bytes --]