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

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

[York Zhao]

Hi list,

(org-insert-headline '(4)) used to insert new heading before point. But this had
broken recently. According to the docstring, this command inserts new
heading at the end of the parent subtree  ONLY if two universal prefix
arguments is given, not one. Here's the reproducer:

--8<---------------cut here---------------start------------->8---
emacs -Q -L path/to/org-mode/lisp/ --eval \
"(let ((buf (get-buffer-create \"test-org\")))
(with-current-buffer buf
(org-mode)
(insert \"* headline 1\")
(goto-char (line-beginning-position))
(org-insert-heading '(4)))
(switch-to-buffer buf))"
--8<---------------cut here---------------end--------------->8---

Thanks

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

[York Zhao]

Any one?

On Thu, Apr 3, 2014 at 6:59 PM, York Zhao <gtdplatform@gmail.com> wrote:
> Hi list,
>
> (org-insert-headline '(4)) used to insert new heading before point. But this had
> broken recently. According to the docstring, this command inserts new
> heading at the end of the parent subtree  ONLY if two universal prefix
> arguments is given, not one. Here's the reproducer:
>
> --8<---------------cut here---------------start------------->8---
> emacs -Q -L path/to/org-mode/lisp/ --eval \
> "(let ((buf (get-buffer-create \"test-org\")))
> (with-current-buffer buf
> (org-mode)
> (insert \"* headline 1\")
> (goto-char (line-beginning-position))
> (org-insert-heading '(4)))
> (switch-to-buffer buf))"
> --8<---------------cut here---------------end--------------->8---
>
> Thanks

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

[Grant Rettke]

They are working on the next release right now so things might be quiet.
Grant Rettke | AAAS, ACM, AMA, COG, FSF, IEEE, Sigma Xi
grettke@acm.org | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Fri, Apr 4, 2014 at 10:01 PM, York Zhao <gtdplatform@gmail.com> wrote:
> Any one?
>
> On Thu, Apr 3, 2014 at 6:59 PM, York Zhao <gtdplatform@gmail.com> wrote:
>> Hi list,
>>
>> (org-insert-headline '(4)) used to insert new heading before point. But this had
>> broken recently. According to the docstring, this command inserts new
>> heading at the end of the parent subtree  ONLY if two universal prefix
>> arguments is given, not one. Here's the reproducer:
>>
>> --8<---------------cut here---------------start------------->8---
>> emacs -Q -L path/to/org-mode/lisp/ --eval \
>> "(let ((buf (get-buffer-create \"test-org\")))
>> (with-current-buffer buf
>> (org-mode)
>> (insert \"* headline 1\")
>> (goto-char (line-beginning-position))
>> (org-insert-heading '(4)))
>> (switch-to-buffer buf))"
>> --8<---------------cut here---------------end--------------->8---
>>
>> Thanks
>

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

[Bastien]

Hi York,

York Zhao <gtdplatform@gmail.com> writes:

> (org-insert-headline '(4)) used to insert new heading before point. But this had
> broken recently. According to the docstring, this command inserts new
> heading at the end of the parent subtree  ONLY if two universal prefix
> arguments is given, not one. Here's the reproducer:

Not sure what precise error you're reporting here, but I fixed the
docstring in the master branch -- please have a look and report if
the behavior differs from what the docstring says.

Thanks,

-- 
 Bastien

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

[York Zhao]

Hi Bastian,

I apologize for missing your reply until I check in the folder "Sent".

I'm sorry that my bug report might not be clear enough. 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. In this regard the behavior
should be exactly the same as when this command is executed with no prefix
argument. I've written a test for this:

--8<---------------cut here---------------start------------->8---
(ert-deftest yz-test-org/org-insert-heading ()
  "Test `org-insert-heading' with one universal prefix argument."
  (org-test-with-temp-text
      "* Headline"
    (org-insert-heading '(4)) ; This test will pass without prefix argument
    (forward-line)
    (should (looking-at "\\* Headline"))))
--8<---------------cut here---------------end--------------->8---

This test fails on current org-mode version, but will pass if you test it on the
version shipped with Emacs 24.3. Also, if you change `(org-insert-heading '(4))'
to `(org-insert-heading)' this test will pass too.

Also, with current org-mode, if you replace `(forward-line)' in the test with
`(forward-line -1)' (moving to previous line) the test will pass, which means
that the new heading had been inserted after the current heading, not before.

Let me know if this is still not clear.


Thanks,

York

On Thu, Apr 17, 2014 at 10:21 AM, Bastien <bzg@gnu.org> wrote:
> Hi York,
>
> York Zhao <gtdplatform@gmail.com> writes:
>
>> (org-insert-headline '(4)) used to insert new heading before point. But this had
>> broken recently. According to the docstring, this command inserts new
>> heading at the end of the parent subtree  ONLY if two universal prefix
>> arguments is given, not one. Here's the reproducer:
>
> Not sure what precise error you're reporting here, but I fixed the
> docstring in the master branch -- please have a look and report if
> the behavior differs from what the docstring says.
>
> Thanks,
>
> --
>  Bastien

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

[Nicolas Goaziou]

Hello,

York Zhao <gtdplatform@gmail.com> writes:

> I'm sorry that my bug report might not be clear enough. 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. In this regard the behavior
> should be exactly the same as when this command is executed with no prefix
> argument.

C-u M-RET behaves exactly as C-RET, not as M-RET. It seems to be
intended.


Regards,

-- 
Nicolas Goaziou

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

[Bastien]

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

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

[Leonard Randall]

[-- 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 --]

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

[Leonard Randall]

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

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.randall@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 <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: 3055 bytes --]

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

[Eric Abrahamsen]

Leonard Randall <leonard.a.randall@gmail.com> writes:

> 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

Yes, please, this has gotten really difficult to use all of a sudden!
New headings are inserted between the old heading and the old heading's
PROPERTIES drawer, which seems very wrong...

> On 23 April 2014 22:42, Leonard Randall <leonard.a.randall@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 <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
>        
>    
>    

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

[Bastien]

Hi Leonard,

I just fixed this in maint -- please let me know if it works
back as expected.

Thanks,

-- 
 Bastien

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

[Leonard Randall]

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

Hi Bastien,
On 25 April 2014 08:29, Bastien <bzg@gnu.org> wrote:


> I just fixed this in maint -- please let me know if it works
> back as expected.
>


Yes, now C-RET and the speedkey `i' now function as
described in the documentation. The only place where the
function differs from the documentation is at the beginning of
a normal line. The documentation says, `If point is at the
beginning of a normal line, turn this line into a heading.'

Currently, calling M-RET will create a newline before the
text on the current line.So, if I call M-RET at the beginning of
(a), I get (b), rather than (c) which is what I would expect from
the documentation.

-----a----
Text I may later turn into a headline.
----------

----b----
*
Text I may later turn into a headline.
---------

----c----
* Text I may later turn into a headline
--------


Hope this helps,
All best,
Leonard

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

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

[Bastien]

Hi Leonard,

Leonard Randall <leonard.a.randall@gmail.com> writes:

> Currently, calling M-RET will create a newline before the
> text on the current line.

I can't reproduce this, either on maint or on the master branch.

Let me know if there is any special config that is needed to
reproduce the problem.

Thanks,

-- 
 Bastien

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

[Leonard Randall]

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

Hi Bastien,

I can't reproduce this, either on maint or on the master branch.
>
> Let me know if there is any special config that is needed to
> reproduce the problem


I tried it with a minimal init, having just pulled from master this
morning. It will work fine on the first line of a file.  But will not work
on the second. This is what I got:
---
* this is a test
*
this is   another
---
As I say M-Ret worked fine on the first line, but inserted a new line when
called on the second.

All best,
Leonard


On 29 April 2014 13:35, Bastien <bzg@gnu.org> wrote:

> Hi Leonard,
>
> Leonard Randall <leonard.a.randall@gmail.com> writes:
>
> > Currently, calling M-RET will create a newline before the
> > text on the current line.
>
> I can't reproduce this, either on maint or on the master branch.
>
> Let me know if there is any special config that is needed to
> reproduce the problem.
>
> Thanks,
>
> --
>  Bastien
>

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

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

[Bastien]

Hi Leonard,

Leonard Randall <leonard.a.randall@gmail.com> writes:

> I tried it with a minimal init, having just pulled from master this
> morning. It will work fine on the first line of a file.  But will not
> work on the second. This is what I got:
> ---
> * this is a test
> *
> this is   another
> ---
> As I say M-Ret worked fine on the first line, but inserted a new line
> when called on the second.

I'm having a hard time finding out what you *did* exactly -- can you
describe the way to reproduce the bug from an empty buffer, step by
step?  Something like

1. emacs -q
2. C-x C-f ~/test.org RET
3. [insert "bla"]
4. C-a
5. M-RET

The recipe above is fine for me -- whether "bla" is on the first or
the second line.

Let me know,

-- 
 Bastien

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

[Leonard Randall]

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

On 29 April 2014 15:20, Bastien <bzg@gnu.org> wrote:

>
> I'm having a hard time finding out what you *did* exactly -- can you
> describe the way to reproduce the bug from an empty buffer, step by
> step?
>

Sorry, I should have been more explicit about what I was doing. Step by
step instructions would look something like this.

 If I type the following commands,

1. emacs -q -l ~/minimal-init.el
2. C-x C-f ~/test.org RET
3. bla
4. C-a
5. M-RET
6. C-e
7. RET
8. bla bla
9. C-a
10. M-RET

I get:
----begin-example---
* bla
*
bla bla
----end-example---

If I perform the same commands without loading the minimal init file
(Minimal-init just adds the most recent version org-mode to the load path,
and says to debug on error), I get this

----begin example---

* bla
* bla bla
----end-example---

It adds a new line before the first headline, but otherwise it acts as
expected. I am not sure if it makes any difference. But I am running the
the Homebrew version of emacs 24.3.1 on OS X Mavericks.

All best,
Leonard

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

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

[Bastien]

Hi Leonard,

Okay, I see now and this is fixed -- thanks for your patience,

-- 
 Bastien

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

[Leonard Randall]

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

Hi Bastien,
Thanks for the fix, and sorry to be the bearer of bad news, but there seems
to be a new issue. Now, if you press M-RET in a lower level tree anywhere
but in the headline, it will produce a new first level headline. So, given
buffer contents as in example (a), if i press M-Ret at the end of `two', I
get (b)  which is what I would expect, but if i press RET, then M-RET, I
get (c) which is certainly not what I would expect.

--example-a--
* Level one

** Level two
--end-example-a--

--example b--
* Level one

** Level two

**
--end-example-b--

----example-c--
* Level one

** Level two

*
----end-example-c-

Thanks again.

All best,
Leonard

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

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

[Leonard Randall]

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

Hi Bastien,

Just to follow up on the error, reverting commit 0ca4092 fixes the bug that
I mentioned in my last email and reverting the fourth hunk of commit
b8c85a1 should fix the bug that you tried to fix with that commit.  Carsten
had added an 'unless (bolp)' condition to the function that controls
inserting new lines outside of headlines to avoid deleting whitespace.
However, so far as I can tell, the other measures Carsten put in place with
that commit made adding this condition unnecessary. Outside of the contexts
where it produces the first bug I mentioned it does not seem to affect
headline insertion behaviour.

Anyway, reverting those commits should get headline insertion to work as
advertised.

All best

Leonard

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

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

[Bastien]

Hi Leonard,

I followed your directions and added another fix.

Things should be okay now, let me know if not.

Thanks,

-- 
 Bastien

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

[Leonard Avery Randall]

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

Thanks!
All best,
Leonard

> Bastien <mailto:bzg@gnu.org>
> May 21, 2014 at 2:43 AM
> Hi Leonard,
>
> I followed your directions and added another fix.
>
> Things should be okay now, let me know if not.
>
> Thanks,
>
> Leonard Randall <mailto:leonard.a.randall@gmail.com>
> May 4, 2014 at 3:37 AM
> Hi Bastien,
>
> Just to follow up on the error, reverting commit 0ca4092 fixes the bug 
> that I mentioned in my last email and reverting the fourth hunk of 
> commit b8c85a1 should fix the bug that you tried to fix with that 
> commit.  Carsten had added an 'unless (bolp)' condition to the 
> function that controls inserting new lines outside of headlines to 
> avoid deleting whitespace. However, so far as I can tell, the other 
> measures Carsten put in place with that commit made adding this 
> condition unnecessary. Outside of the contexts where it produces the 
> first bug I mentioned it does not seem to affect headline insertion 
> behaviour.
>
> Anyway, reverting those commits should get headline insertion to work 
> as advertised.
>
> All best
>
> Leonard
>
> Leonard Randall <mailto:leonard.a.randall@gmail.com>
> April 30, 2014 at 6:03 PM
>
> Hi Bastien,
> Thanks for the fix, and sorry to be the bearer of bad news, but there 
> seems to be a new issue. Now, if you press M-RET in a lower level tree 
> anywhere but in the headline, it will produce a new first level 
> headline. So, given buffer contents as in example (a), if i press 
> M-Ret at the end of `two', I get (b)  which is what I would expect, 
> but if i press RET, then M-RET, I get (c) which is certainly not what 
> I would expect.
>
> --example-a--
> * Level one
>
> ** Level two
> --end-example-a--
>
> --example b--
> * Level one
>
> ** Level two
>
> **
> --end-example-b--
>
> ----example-c--
> * Level one
>
> ** Level two
>
> *
> ----end-example-c-
>
> Thanks again.
>
> All best,
> Leonard
> Bastien <mailto:bzg@gnu.org>
> April 30, 2014 at 9:44 AM
> Hi Leonard,
>
> Okay, I see now and this is fixed -- thanks for your patience,
>
> Leonard Randall <mailto:leonard.a.randall@gmail.com>
> April 30, 2014 at 8:12 AM
>
>
>
>
>     I'm having a hard time finding out what you *did* exactly -- can you
>     describe the way to reproduce the bug from an empty buffer, step by
>     step?
>
>
> Sorry, I should have been more explicit about what I was doing. Step 
> by step instructions would look something like this.
>
>  If I type the following commands,
>
> 1. emacs -q -l ~/minimal-init.el
> 2. C-x C-f ~/test.org <http://test.org> RET
> 3. bla
> 4. C-a
> 5. M-RET
> 6. C-e
> 7. RET
> 8. bla bla
> 9. C-a
> 10. M-RET
>
> I get:
> ----begin-example---
> * bla
> *
> bla bla
> ----end-example---
>
> If I perform the same commands without loading the minimal init file 
> (Minimal-init just adds the most recent version org-mode to the load 
> path, and says to debug on error), I get this
>
> ----begin example---
>
> * bla
> * bla bla
> ----end-example---
>
> It adds a new line before the first headline, but otherwise it acts as 
> expected. I am not sure if it makes any difference. But I am running 
> the the Homebrew version of emacs 24.3.1 on OS X Mavericks.
>
> All best,
> Leonard

[-- Attachment #2.1: Type: text/html, Size: 9058 bytes --]

[-- Attachment #2.2: postbox-contact.jpg --]
[-- Type: image/jpeg, Size: 1402 bytes --]

[-- Attachment #2.3: compose-unknown-contact.jpg --]
[-- Type: image/jpeg, Size: 770 bytes --]