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

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

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