From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leonard Randall Subject: Re: (org-insert-headline '(4)) should insert new headline before point Date: Wed, 23 Apr 2014 22:42:43 +0100 Message-ID: References: <87a9bk9guf.fsf@bzg.ath.cx> <87zjjdafa3.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0160c660ce98a104f7bc9cdf Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wd4wI-0002us-2J for emacs-orgmode@gnu.org; Wed, 23 Apr 2014 17:42:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wd4wG-0001Yx-V7 for emacs-orgmode@gnu.org; Wed, 23 Apr 2014 17:42:46 -0400 In-Reply-To: <87zjjdafa3.fsf@bzg.ath.cx> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: York Zhao , emacs-orgmode --089e0160c660ce98a104f7bc9cdf Content-Type: text/plain; charset=UTF-8 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 > > --089e0160c660ce98a104f7bc9cdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bastien,
I just wanted to report an = issue with this fix. In many use cases it makes C-RET less useful, and rend= ers the speedkeys command `i' useless. It makes C-RET function much lik= e M-RET, and it makes `i' insert headlines before any content.

So if I call C-RET in the middle of the following headline:<= br>---
** Important Meeting
SCHEDULED: <2014-04-26 Sat 16:30>
headline content...
---
I get: ---
** Important

** Meeting
SCHEDULED: <2014-04-26 Sat 16:0= 0>
headline content...
---
And= when I use the speedkeys command `i' at the beginning, I get
--- ** Important Meeting

**
SCHEDULED: <2014-04-26 Sat 16:00><= br>
headline content...
---
Both of t= hese break the scheduling cookie and defeat the main purpose of these comma= nds.

Reverting the change restores expected behavior in these cas= es, but then I suppose we are left with York's problem.

All best,
Leonard


On 22 April 2014 10:23, Bastien <bzg@gnu.org><= /span> wrote:
Hi York,

thanks for coming back to this.

York Zhao <gtdplatform@gmail.co= m> 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. =C2=A0As Nicol= as
noted, this is the same than C-RET.

--
=C2=A0Bastien


--089e0160c660ce98a104f7bc9cdf--