Insert heading above current one

Insert heading above current one

[Luciano Passuello]

Hello everybody, first message here.

According to org-insert-heading documentation: "If point is at the
beginning of a heading, insert a new heading or a new headline above
the current one."

I like this behavior very much, and in orgmode 8.x, calling
org-insert-heading at the beginning of a line indeed creates a heading
before the current one, even when org-insert-heading-respect-content
is set.

For orgmode 9.x, this only works when org-insert-heading-respect-content is nil.
I find this annoying, because I like to have
org-insert-heading-respect-content non-nil AND to be able to insert a
heading before the current one.

Is that by design or a bug? I couldn't find any mention to the new
behavior in the Changes <http://orgmode.org/Changes.html> page.

Thanks!

Re: Insert heading above current one

[Kaushal Modi]

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

On Fri, Sep 29, 2017 at 10:14 AM Luciano Passuello <lucianop@litemind.com>
wrote:

> Hello everybody, first message here.
>
> According to org-insert-heading documentation: "If point is at the
> beginning of a heading, insert a new heading or a new headline above
> the current one."
>
> I like this behavior very much, and in orgmode 8.x, calling
> org-insert-heading at the beginning of a line indeed creates a heading
> before the current one, even when org-insert-heading-respect-content
> is set.
>
> For orgmode 9.x, this only works when org-insert-heading-respect-content
> is nil.
> I find this annoying, because I like to have
> org-insert-heading-respect-content non-nil AND to be able to insert a
> heading before the current one.
>
> Is that by design or a bug? I couldn't find any mention to the new
> behavior in the Changes <http://orgmode.org/Changes.html> page.
>

Looks like this was an intended change:
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2b03e945a19701194e510791a96006c5eee9edc6

Related discussion:
http://lists.gnu.org/archive/html/emacs-orgmode/2016-10/msg00080.html

PS: The commit message includes gmane.org links which are now dead. I think
we should reference lists.gnu.org links (like above) for longevity of
references.
-- 

Kaushal Modi

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

Re: Insert heading above current one

[Kaushal Modi]

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

On Fri, Sep 29, 2017 at 10:41 AM Kaushal Modi <kaushal.modi@gmail.com>
wrote:

> Looks like this was an intended change:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2b03e945a19701194e510791a96006c5eee9edc6
>
> Related discussion:
> http://lists.gnu.org/archive/html/emacs-orgmode/2016-10/msg00080.html
>
> PS: The commit message includes gmane.org links which are now dead. I
> think we should reference lists.gnu.org links (like above) for longevity
> of references.
>

To add, I also think that the earlier behavior made sense, if the point is
at bolp, insert before, else insert after.

But I never noticed this change as I
leave org-insert-heading-respect-content at its default value of nil.

So talking of consistency, it would be nice to get that "if bolp, insert
before" behavior regardless of the value
of org-insert-heading-respect-content.

@Nicolas?
-- 

Kaushal Modi

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

Re: Insert heading above current one

[Nicolas Goaziou]

Hello,

Kaushal Modi <kaushal.modi@gmail.com> writes:

> On Fri, Sep 29, 2017 at 10:41 AM Kaushal Modi <kaushal.modi@gmail.com>
> wrote:
>
>> Looks like this was an intended change:
>> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2b03e945a19701194e510791a96006c5eee9edc6
>>
>> Related discussion:
>> http://lists.gnu.org/archive/html/emacs-orgmode/2016-10/msg00080.html
>>
>> PS: The commit message includes gmane.org links which are now dead. I
>> think we should reference lists.gnu.org links (like above) for longevity
>> of references.

This is already the case. Latest commit message include links to
lists.gnu.org.

> To add, I also think that the earlier behavior made sense, if the point is
> at bolp, insert before, else insert after.

I think the current behaviour makes more sense, if the command is called
with an universal argument. Indeed, what would be the point of using an
universal argument if you get the exact same behaviour as without it?

> But I never noticed this change as I
> leave org-insert-heading-respect-content at its default value of nil.

Out of curiosity is there any to set this variable to something else
than nil? There are already comfortable keybindings to set this
temporarily (C-RET and C-u M-RET). Why would one have M-RET to behave
exactly as C-RET? And even if there was a good reason to do so, why not
simply re-binding M-RET in that case?

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: Insert heading above current one

[Luciano Passuello]

Hi, thanks for the replies!

>> To add, I also think that the earlier behavior made sense, if the point is
>> at bolp, insert before, else insert after.
>
> I think the current behaviour makes more sense, if the command is called
> with an universal argument. Indeed, what would be the point of using an
> universal argument if you get the exact same behaviour as without it?

I also think the earlier behavior made more sense. The variable
org-insert-heading-respect-content (or the universal argument)
controls how a new headline is inserted BELOW the current header
(either add immediately after the current line or down below). I don't
see how this variable should alter the behavior of adding a heading
ABOVE the current header (ie. "respecting content" or not has no
effect here, above is always above).

> Out of curiosity is there any to set this variable to something else
> than nil? There are already comfortable keybindings to set this
> temporarily (C-RET and C-u M-RET). Why would one have M-RET to behave
> exactly as C-RET? And even if there was a good reason to do so, why not
> simply re-binding M-RET in that case?

You have a good point. Looking this way, the
org-insert-heading-respect-content variable is indeed of little use.
But since the variable does exist (even though perhaps it should be
deprecated?), it should behave correctly.
And I just don't see how the behavior of adding a header above the
current line should be impacted by it.

Thanks!
Luciano.

Re: Insert heading above current one

[Nicolas Goaziou]

Hello,

Luciano Passuello <lucianop@litemind.com> writes:

> I also think the earlier behavior made more sense.

Then we have to agree to disagree, I guess.

> The variable
> org-insert-heading-respect-content (or the universal argument)
> controls how a new headline is inserted BELOW the current header
> (either add immediately after the current line or down below). I don't
> see how this variable should alter the behavior of adding a heading
> ABOVE the current header (ie. "respecting content" or not has no
> effect here, above is always above).

Quoting `org-insert-heading-respect-content':

  Non-nil means insert new headings after the current subtree.

I see no exception there. Consequently, both C-u M-RET and C-RET insert
new heading after the current subtree. If you want to insert it before
current header, use M-RET. There is no feature lost. 

OTOH, if we force the previous behaviour, as you suggest, there is no
way to insert a new headline after the current subtree when point is at
the beginning of a headline. A feature is lost.

> You have a good point. Looking this way, the
> org-insert-heading-respect-content variable is indeed of little use.
> But since the variable does exist (even though perhaps it should be
> deprecated?), it should behave correctly.

It does behave correctly, since it obeys its docstring. 

And I agree it should be deprecated. If there is no objection, I'll
remove it.


Regards,

-- 
Nicolas Goaziou

Re: Insert heading above current one

[Luciano Passuello]

Hello,

On Sat, Sep 30, 2017 at 4:29 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> OTOH, if we force the previous behaviour, as you suggest, there is no
> way to insert a new headline after the current subtree when point is at
> the beginning of a headline. A feature is lost.

Isn't that consistent with the regular org-insert-heading (M-RET)?
When cursor is in the beginning of a headline, there's no way to
create a heading below that line (using standard M-RET). It will
always create it above. So, having the cursor in the beginning of the
line overrides the standard behavior. Unless we move the cursor
somewhere else, that feature is also lost.

I see no reason why C-RET should behave differently, even if only for
consistency reasons.

> And I agree it should be deprecated. If there is no objection, I'll
> remove it.

I'm too much of a n00b to foresee all consequences of such
deprecation, so I prefer not to give my opinion here.
Doing a quick search on "org-insert-heading-respect-content t" I see
some people do find value in it.

Regards,
Luciano.

Re: Insert heading above current one

[Nicolas Goaziou]

Luciano Passuello <lucianop@litemind.com> writes:

> Isn't that consistent with the regular org-insert-heading (M-RET)?
> When cursor is in the beginning of a headline, there's no way to
> create a heading below that line (using standard M-RET). It will
> always create it above. So, having the cursor in the beginning of the
> line overrides the standard behavior. Unless we move the cursor
> somewhere else, that feature is also lost.

Sorry, but this makes no sense. You want to insert a headline above
current one? Use M-RET. You want it below current headline? Use C-RET.
You have the best of both worlds, any behaviour is still available to
your fingertips.

> I see no reason why C-RET should behave differently, even if only for
> consistency reasons.

I do see reasons, and I explained them. M-RET and C-RET/C-u M-RET are
different beasts, just don't expect them to behave exactly the same.

I stand on my ground: current behaviour is better.

Regards,

Re: Insert heading above current one

[Luciano Passuello]

On Sat, Sep 30, 2017 at 5:21 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> M-RET and C-RET/C-u M-RET are
> different beasts, just don't expect them to behave exactly the same.

And then you hit exactly the heart of our discussion right there.
Im my line of reasoning, org-insert-heading and
org-insert-heading-respect-content should behave exactly the same,
except for the fact that org-insert-heading-respect-content should,
well, respect the content; Other than that, they should be 100%
symmetric.

> I stand on my ground: current behaviour is better.
Given we're not striving for behavior symmetry, I can see your point.

Regards,

Re: Insert heading above current one

[Rasmus]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>>> Looks like this was an intended change:
>>> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2b03e945a19701194e510791a96006c5eee9edc6
>>>
>>> Related discussion:
>>> http://lists.gnu.org/archive/html/emacs-orgmode/2016-10/msg00080.html
>>>
>>> PS: The commit message includes gmane.org links which are now dead. I
>>> think we should reference lists.gnu.org links (like above) for longevity
>>> of references.
>
> This is already the case. Latest commit message include links to
> lists.gnu.org.

Aside:

Is there any way to have list.gnus.org links shown directly in Gnus?  I
have Gmane links under the "Archived-At" header (presumably because I use
Gmane NNTP).

Rasmus

-- 
And I faced endless streams of vendor-approved Ikea furniture. . .