Re: behavior of (org-insert-heading-respect-content)
Le 18 Sep 2021, Marco Wahl a écrit : > Would be great if you could test the fix. Hi Marco! Sorry, I was unable to try it until today. I just did and It works perfectly. Thanks! Victor
Re: behavior of (org-insert-heading-respect-content)
Marco Wahl writes: > Bastien! > >> Marco Wahl writes: >> >>> Would be great if you could test the fix. >> >> If you're confident with the fix, please go ahead and push the commit. > > This has been committed some days ago. See > > > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=069bcba529142bdb91647258924513f0fb0f3fa1 Okay, thanks for confirming! -- Bastien
Re: behavior of (org-insert-heading-respect-content)
Bastien! > Marco Wahl writes: > >> Would be great if you could test the fix. > > If you're confident with the fix, please go ahead and push the commit. This has been committed some days ago. See https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=069bcba529142bdb91647258924513f0fb0f3fa1
Re: behavior of (org-insert-heading-respect-content)
Hi Marco, Marco Wahl writes: > Would be great if you could test the fix. If you're confident with the fix, please go ahead and push the commit. Thanks, -- Bastien
Re: behavior of (org-insert-heading-respect-content)
Victor! > Le 13 Sep 2021, Marco Wahl a écrit : > >> As far is I see it, the intended behavior of >> org-insert-heading-respect-content with point before the first heading >> is to >> >> - insert the new heading immediately before the first heading. Respect >> the content! > Hi Marco ! > > I agree with you. But this does not work. Say I have a buffer with this > content : > > put point HERE and C- > Some more stuff > * Heading > content > > > When point is at HERE and I C-, org inserts a new asterisk on > the after "stuff", but on the same line → not a proper heading. >> >> - If there is no heading at all in the file the heading shall be >> inserted at the bottom of the file. > > Yes. But I get the same behavior with > > put point HERE and C- > Some more stuff > > The asterisk is inserted right after "stuff", on the same line → not > a proper heading. > >> >> Do we agree on the desired behavior of >> org-insert-heading-respect-content? > > Yes, we do! >> >> With your proposition the respect for the content gets lost, >> doesn't it? > > Yes, you’re right. It currently does not respect the content before > first heading. Therefore it’s not a fix for the behavior of > org-insert-heading-respect-content. > It’s just the quickest workaround I’ve come up with to make my own > function work (in my use-case, when I call that function, either point > is at point-min in a brand new buffer, or point is below the first > heading). Okay, thanks for clarifying. Would be great if you could test the fix. Thank you!
Re: behavior of (org-insert-heading-respect-content)
Le 13 Sep 2021, Marco Wahl a écrit : > As far is I see it, the intended behavior of > org-insert-heading-respect-content with point before the first heading > is to > > - insert the new heading immediately before the first heading. Respect > the content! Hi Marco ! I agree with you. But this does not work. Say I have a buffer with this content : --8<---cut here---start->8--- put point HERE and C- Some more stuff * Heading content --8<---cut here---end--->8--- When point is at HERE and I C-, org inserts a new asterisk on the after "stuff", but on the same line → not a proper heading. > > - If there is no heading at all in the file the heading shall be > inserted at the bottom of the file. Yes. But I get the same behavior with --8<---cut here---start->8--- put point HERE and C- Some more stuff --8<---cut here---end--->8--- The asterisk is inserted right after "stuff", on the same line → not a proper heading. > > Do we agree on the desired behavior of > org-insert-heading-respect-content? Yes, we do! > > With your proposition the respect for the content gets lost, > doesn't it? Yes, you’re right. It currently does not respect the content before first heading. Therefore it’s not a fix for the behavior of org-insert-heading-respect-content. It’s just the quickest workaround I’ve come up with to make my own function work (in my use-case, when I call that function, either point is at point-min in a brand new buffer, or point is below the first heading). Regards, Victor
Re: behavior of (org-insert-heading-respect-content)
Hi Victor, > Le 09 Sep 2021, Marco Wahl a écrit : > >> My impression is that org-insert-heading-respect-content should be >> called only with point in a subtree. >> >> The fix would be to signal an error when point is not located in a >> subtree. >> >> Does this sound reasonable? > > In a way, yes. I guess that the error would not appear too often. > But falling back gracefully to org-insert-heading could be even > better, especially when org-insert-heading-respect-content is called > from Lisp (rather than interactively). > > For now, I use this and it seems to do the job: > > #+begin_src elisp > (if (equal 1 (line-number-at-pos nil t)) > (org-insert-heading) > (org-insert-heading-respect-content)) > #+end_src > > If I’m not mistaken, org-insert-heading-respect-content works as > expected even when point is not in a subtree. It seems to only fail if > point is on the 1st line. As far is I see it, the intended behavior of org-insert-heading-respect-content with point before the first heading is to - insert the new heading immediately before the first heading. Respect the content! - If there is no heading at all in the file the heading shall be inserted at the bottom of the file. Do we agree on the desired behavior of org-insert-heading-respect-content? With your proposition the respect for the content gets lost, doesn't it? Ciao!
Re: behavior of (org-insert-heading-respect-content)
Le 09 Sep 2021, Marco Wahl a écrit : > My impression is that org-insert-heading-respect-content should be > called only with point in a subtree. > > The fix would be to signal an error when point is not located in a > subtree. > > Does this sound reasonable? In a way, yes. I guess that the error would not appear too often. But falling back gracefully to org-insert-heading could be even better, especially when org-insert-heading-respect-content is called from Lisp (rather than interactively). For now, I use this and it seems to do the job: #+begin_src elisp (if (equal 1 (line-number-at-pos nil t)) (org-insert-heading) (org-insert-heading-respect-content)) #+end_src If I’m not mistaken, org-insert-heading-respect-content works as expected even when point is not in a subtree. It seems to only fail if point is on the 1st line. Regards, Victor
Re: behavior of (org-insert-heading-respect-content)
Hi! "Victor A. Stoichita" writes: > I see the following behavior which seems erroneous to me : > - When I issue (org-insert-heading-respect-content) in a brand new org > buffer, with point at point-min I get the error "Beginning of buffer" > and no heading is inserted. > - If I write something on the 1st line, say "test", but no newline, and > then issue (org-insert-heading-respect-content), the result is : > "test * " which is not a properly formatted heading > - Only if there is a newline before point does > (org-insert-heading-respect-content) insert a proper heading. > > Am I getting something wrong or is this a bug ? I think so. My impression is that org-insert-heading-respect-content should be called only with point in a subtree. The fix would be to signal an error when point is not located in a subtree. Does this sound reasonable?
behavior of (org-insert-heading-respect-content)
Hi, I see the following behavior which seems erroneous to me : - When I issue (org-insert-heading-respect-content) in a brand new org buffer, with point at point-min I get the error "Beginning of buffer" and no heading is inserted. - If I write something on the 1st line, say "test", but no newline, and then issue (org-insert-heading-respect-content), the result is : "test * " which is not a properly formatted heading - Only if there is a newline before point does (org-insert-heading-respect-content) insert a proper heading. Am I getting something wrong or is this a bug ? Regards, Victor
