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 <leonard.a.rand...@gmail.com> 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 <b...@gnu.org> wrote:
>
>> Hi York,
>>
>> thanks for coming back to this.
>>
>> York Zhao <gtdplatf...@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
>>
>>
>

Reply via email to