Headings and Headlines

Headings and Headlines

[André A. Gomes]

Hi,

The project's documentation refers to headings and headlines as
synonyms.  Relying on a single definition would be beneficial.  If I had
to choose between the two, I'd go with heading.

If the community finds this valuable, I could prepare a patch.

Thank you.


--
André A. Gomes
"Free Thought, Free World"

Re: Headings and Headlines

[Eric S Fraga]

I agree that consistency would be good and I also think heading is a
better choice than headline.  The former's definition fits what it means
in org; the latter's is more equivalent to a title than anything else.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Headings and Headlines

[Christopher Dimech]

Headline gave an indication that the heading is contained in a single line.

> Sent: Saturday, July 24, 2021 at 1:56 AM
> From: "Eric S Fraga" <e.fraga@ucl.ac.uk>
> To: "André A. Gomes" <andremegafone@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Headings and Headlines
>
> I agree that consistency would be good and I also think heading is a
> better choice than headline.  The former's definition fits what it means
> in org; the latter's is more equivalent to a title than anything else.
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
> 
>

Re: Headings and Headlines

[Timothy]

Christopher Dimech <dimech@gmx.com> writes:

> Headline gave an indication that the heading is contained in a single line.

I feel the need to add that the strongest association with "headline" to
me is newspaper headlines, and I never think of an article having more
than one headline. On the other hand, I don't bat an eye at multiple
headings --- which pushes me towards supporting that as the canonical
term that Org should use.

--
Timothy

Re: Headings and Headlines

[Eric S Fraga]

Just for completeness, definitions of both terms from WordNet:

  heading
      n 1: a line of text serving to indicate what the passage below
           it is about; "the heading seemed to have little to do with
           the text" [syn: {heading}, {header}, {head}]
  headline
      n 1: the heading or caption of a newspaper article [syn:
           {headline}, {newspaper headline}]

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Headings and Headlines

[Marco Wahl]

André A. Gomes <andremegafone@gmail.com> writes:

> The project's documentation refers to headings and headlines as
> synonyms.  Relying on a single definition would be beneficial.

Agreed.  E.g. no more thinking waste about the question if it is
headline or heading?

> If I had to choose between the two, I'd go with heading.

+1

> If the community finds this valuable, I could prepare a patch.

+1

Re: Headings and Headlines

[Kaushal Modi]

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

On Fri, Jul 23, 2021 at 10:07 AM Marco Wahl <marcowahlsoft@gmail.com> wrote:

> André A. Gomes <andremegafone@gmail.com> writes:
>
> > The project's documentation refers to headings and headlines as
> > synonyms.  Relying on a single definition would be beneficial.
>
> Agreed.  E.g. no more thinking waste about the question if it is
> headline or heading?
>

+1

> If I had to choose between the two, I'd go with heading.
>
> +1
>

+1

> If the community finds this valuable, I could prepare a patch.
>
> +1
>

+1

@André

> There's a problem though.  Function names would have to be changed,
> which would have to wait for version 10 otherwise we'd ruin backwards
> compatibility.

It doesn't have to break things drastically. When such changes are made,
you would define function aliases using `define-obsolete-function-alias'.
And then that obsoletion warning is removed after a few years.

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

Re: Headings and Headlines

[Timothy]

André A. Gomes <andremegafone@gmail.com> writes:

> If the community finds this valuable, I could prepare a patch.

I am certainly of the mind that this would be a worthwhile change :)

--
Timothy

Re: Headings and Headlines

[André A. Gomes]

Timothy <tecosaur@gmail.com> writes:

> I am certainly of the mind that this would be a worthwhile change :)

There's a problem though.  Function names would have to be changed,
which would have to wait for version 10 otherwise we'd ruin backwards
compatibility.

I think there's little sense in changing the wording in the
documentation alone.

More feedback from the maintainers is welcome.


--
André A. Gomes
"Free Thought, Free World"

Re: Headings and Headlines

[Timothy]

André A. Gomes <andremegafone@gmail.com> writes:

>> I am certainly of the mind that this would be a worthwhile change :)
>
> There's a problem though.  Function names would have to be changed,
> which would have to wait for version 10 otherwise we'd ruin backwards
> compatibility.

I see 61 functions with "headline" and 49 with "heading".
So, a near even split. I think it would be a good idea to consolidate this.

We can always use `define-obsolete-function-alias' and give a few years
for people to shift over.

> I think there's little sense in changing the wording in the
> documentation alone.

Agreed, we should be consistent across the board.

--
Timothy

Re: Headings and Headlines

[Tim Cross]

André A. Gomes <andremegafone@gmail.com> writes:

> Hi,
>
> The project's documentation refers to headings and headlines as
> synonyms.  Relying on a single definition would be beneficial.  If I had
> to choose between the two, I'd go with heading.
>
> If the community finds this valuable, I could prepare a patch.
>

I think heading is better than headline - to me headline is a line at
the top of the buffer (like a newpaper headline). Note that in addition
to changes in the manual, it will probably be necessary to make changes
to variable and function names in the code. This may require marking
some old names as obsolete and creating aliases to allow a transition to
the new names and avoid breakage etc. 

Re: Headings and Headlines

[Tom Gillespie]

I enthusiastically support changing the documentation to use heading.
I use heading in my formal grammar because I have found there are more
ways that it can be modified and remain grammatically correct when
used in english sentences. The internal implementation in elisp still
refers to headlines, but changing the docs would be a good first step.
Best!
Tom

Re: Headings and Headlines

[Matt Price]

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

I don't really have a strong preference for either but I would love to
remove the cognitive load of wondering whether the name is heading or
header!

On Sat., Jul. 24, 2021, 12:04 a.m. Tom Gillespie, <tgbugs@gmail.com> wrote:

> I enthusiastically support changing the documentation to use heading.
> I use heading in my formal grammar because I have found there are more
> ways that it can be modified and remain grammatically correct when
> used in english sentences. The internal implementation in elisp still
> refers to headlines, but changing the docs would be a good first step.
> Best!
> Tom
>
>

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

Re: Headings and Headlines

[Charles Millar]

On 7/23/21 10:06 PM, Tim Cross wrote:
> 
> André A. Gomes <andremegafone@gmail.com> writes:
> 
>> Hi,
>>
>> The project's documentation refers to headings and headlines as
>> synonyms.  Relying on a single definition would be beneficial.  If I had
>> to choose between the two, I'd go with heading.
>>
>> If the community finds this valuable, I could prepare a patch.
>>
> 
> I think heading is better than headline - to me headline is a line at
> the top of the buffer (like a newpaper headline). Note that in addition
> to changes in the manual, it will probably be necessary to make changes
> to variable and function names in the code. This may require marking
> some old names as obsolete and creating aliases to allow a transition to
> the new names and avoid breakage etc.
> 

Since org requires outline.el, org.el line 4793, why not follow and 
mirror outline.el conventions?

It appears that outline.el uses
`
	"header" for some early set-up(?) functions and

	"heading" for what appears to provide the outline itself.

Furthermore, "headline" shows up only in comments, and only four or five 
times, at that.

After all, org is an, "Outline-based notes management and organize."


Best,

Charlie Millar

Re: Headings and Headlines

[Timothy]

André A. Gomes <andremegafone@gmail.com> writes:

> If the community finds this valuable, I could prepare a patch.

I think at this point the community view is pretty clearly in favour of
consolidating "headlines" to "headings".

I think at this stage a patch would be warranted. Should you still be
happy to make one that would be great, otherwise I might try whipping
one up.

--
Timothy

[RFC] Re: Headings and Headlines

[Ihor Radchenko]

André A. Gomes <andremegafone@gmail.com> writes:

> The project's documentation refers to headings and headlines as
> synonyms.  Relying on a single definition would be beneficial.  If I had
> to choose between the two, I'd go with heading.

I've been looking into changing all the instances of "headline" to
"heading" and I ran into a serious issue: We use `headline' _symbol_ in
multiple places in the code.

Most importantly, org-element.el uses element type `headline' to parse
headings. We cannot easily change this symbol for backwards
compatibility reasons.

I'm afraid that a complete switch to use "heading" everywhere consistently
is not possible without backwards-incompatible change. I know for sure
that changing `headline' element to `heading' element type will break
important packages like org-roam. And there is no good way to work
around this. We cannot make symbol aliases in Elisp in scenarios like
(memq (org-element-type ...) '(headline inlinetask)).

I came to the conclusion that it will, in fact, be easier to change all
things to use "headline" -- all the instances of "heading" in Org code
are in function names, variable names, and docstrings. All can be
changed using obsolete aliases.

On the other hand, overwhelming feedback in this thread is the
opposite -- change "headline" to "heading".

Maybe others have better ideas how to deal with `headline' symbol issue?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [RFC] Re: Headings and Headlines

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

> I came to the conclusion that it will, in fact, be easier to change
> all things to use "headline" -- [...]

And by "easier" you mean "possible", right?  :)

> On the other hand, overwhelming feedback in this thread is the
> opposite -- change "headline" to "heading".

If Emacs Lisp cannot create aliases for symbols, well then it does not
matter what we all like.  Ha-ha!  Still, better to use a "less pretty"
(but precise) term than to have inconsistent naming across APIs.

P.S. We should also harmonize `evaluate' and `execute'; I can never tell
which one to look for when completing.

Rudy
-- 
"It is no paradox to say that in our most theoretical moods we may be
nearest to our most practical applications."
-- Alfred North Whitehead, 1861-1947

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [RFC] Re: Headings and Headlines

[Ihor Radchenko]

Rudolf Adamkovič <salutis@me.com> writes:

> P.S. We should also harmonize `evaluate' and `execute'; I can never tell
> which one to look for when completing.

Please open a separate thread. I am not sure which one is better.
For "execute" vs. "evaluate" we just need to rename function/variable
names and replace in text/docstrings.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [RFC] Re: Headings and Headlines

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> André A. Gomes <andremegafone@gmail.com> writes:
>
>> The project's documentation refers to headings and headlines as
>> synonyms.  Relying on a single definition would be beneficial.  If I had
>> to choose between the two, I'd go with heading.
>
> I've been looking into changing all the instances of "headline" to
> "heading" and I ran into a serious issue: We use `headline' _symbol_ in
> multiple places in the code.
>
> Most importantly, org-element.el uses element type `headline' to parse
> headings. We cannot easily change this symbol for backwards
> compatibility reasons.
>
> I'm afraid that a complete switch to use "heading" everywhere consistently
> is not possible without backwards-incompatible change. I know for sure
> that changing `headline' element to `heading' element type will break
> important packages like org-roam. And there is no good way to work
> around this. We cannot make symbol aliases in Elisp in scenarios like
> (memq (org-element-type ...) '(headline inlinetask)).
>
> I came to the conclusion that it will, in fact, be easier to change all
> things to use "headline" -- all the instances of "heading" in Org code
> are in function names, variable names, and docstrings. All can be
> changed using obsolete aliases.
>
> On the other hand, overwhelming feedback in this thread is the
> opposite -- change "headline" to "heading".
>
> Maybe others have better ideas how to deal with `headline' symbol issue?

I think consistency is the highest priority. Most people preferred
heading, but that was based on the assumption adopting one or the other
was of roughly equal complexity.

Given we cannot change headline to heading without introducing backwards
and external compatibility issues, I would favour just changing to
headline and documenting what deadline defines/means.

Re: [RFC] Re: Headings and Headlines

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> I came to the conclusion that it will, in fact, be easier to change all
> things to use "headline"

FWIW, I'm fine with such a change.  I'm not a native english speaker,
but a "headline" sounds like it's a one-line heading, so it's okay.

-- 
 Bastien

Re: [RFC] Re: Headings and Headlines

[Vikas Rawal]

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

On Sat, 19 Nov 2022 at 19:17, Bastien Guerry <bzg@gnu.org> wrote:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
> > I came to the conclusion that it will, in fact, be easier to change all
> > things to use "headline"
>
> FWIW, I'm fine with such a change.  I'm not a native english speaker,
> but a "headline" sounds like it's a one-line heading, so it's okay.
>
>
I think, from a linguistic perspective, "heading" and "subheading" are more
appropriate than "headline" and "subheadline".

Vikas

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

Re: [RFC] Re: Headings and Headlines

[Timothy]

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

Hi Vikas,

> I think, from a linguistic perspective, “heading” and “subheading” are more
> appropriate than “headline” and “subheadline”.

Unfortunately I’m completely with you (and previous comments here). The meaning
of “headline” is closer to “title” than “heading”. A document can have multiple
headings but only a single headline (which is specifically the line at the top,
e.g. “Newspaper headline”).

As Ihor points out though, from a compat perspective, a change to “heading” may
be intractable. This gives me rather mixed feelings, as I’m of a similar mind
regarding the org-element headline->heading change being too problematic, but
settling on the less accurate term seems quite undesirable too, and doesn’t sit
well with me.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

Re: [RFC] Re: Headings and Headlines

[Bastien Guerry]

Timothy <orgmode@tec.tecosaur.net> writes:

> Unfortunately I’m completely with you (and previous comments here). The meaning
> of “headline” is closer to “title” than “heading”. A document can have multiple
> headings but only a single headline (which is specifically the line at the top,
> e.g. “Newspaper headline”).

Ah, thanks a lot for this very clear explanation!

-- 
 Bastien

Re: [RFC] Re: Headings and Headlines

[Bastien]

Ihor Radchenko <yantar92@posteo.net> writes:

> I know for sure
> that changing `headline' element to `heading' element type will break
> important packages like org-roam. And there is no good way to work
> around this. We cannot make symbol aliases in Elisp in scenarios like
> (memq (org-element-type ...) '(headline inlinetask)).

We cannot make symbol aliases in Elisp but maybe we can support both
symbols for a transitory period during which we warn third-part devs
about replacing the deprecated 'headline symbol?

> I came to the conclusion that it will, in fact, be easier to change all
> things to use "headline" -- all the instances of "heading" in Org code
> are in function names, variable names, and docstrings. All can be
> changed using obsolete aliases.

Given Vikas and Tim feedback, I would rather move forward by changing
"headline" to "heading" *where it does not break anything* then see if
the proposed scenario above is workable.

In this case, I believe it's better to be partially correct (heading
where possible) than to be consistently wrong (headline everywhere) :)

WDYT?

-- 
 Bastien

Re: [RFC] Re: Headings and Headlines

[Ihor Radchenko]

Bastien <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> I know for sure
>> that changing `headline' element to `heading' element type will break
>> important packages like org-roam. And there is no good way to work
>> around this. We cannot make symbol aliases in Elisp in scenarios like
>> (memq (org-element-type ...) '(headline inlinetask)).
>
> We cannot make symbol aliases in Elisp but maybe we can support both
> symbols for a transitory period during which we warn third-part devs
> about replacing the deprecated 'headline symbol?

The best idea I can come up with is the following:

1. We replace headline -> heading where it is safe
2. We introduce a new constant: org-element-heading-type, defaulting to
   'headline
3. We use the new constant instead of 'headline element type symbol
4. We announce loudly that 'headline will be deprecated in favour of the
   new constant
5. Few years later, we change the org-element-heading-type value to
   'heading

>> I came to the conclusion that it will, in fact, be easier to change all
>> things to use "headline" -- all the instances of "heading" in Org code
>> are in function names, variable names, and docstrings. All can be
>> changed using obsolete aliases.
>
> Given Vikas and Tim feedback, I would rather move forward by changing
> "headline" to "heading" *where it does not break anything* then see if
> the proposed scenario above is workable.
>
> In this case, I believe it's better to be partially correct (heading
> where possible) than to be consistently wrong (headline everywhere) :)
>
> WDYT?

I tried, but it will be confusing when we talk about Org elements.
Phrases like "Headline element" now make sense as they correspond to the
element type. Changing to "Heading element" while keeping the actual
element as (headline ...) sounds extremely confusing.

That said, we may do what I proposed above and then use
"`org-element-heading-type' element". Somewhat cumbersome, but at least
less confusing.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [RFC] Re: Headings and Headlines

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Ihor Radchenko <yantar92@posteo.net> writes:
>>
>>> I know for sure
>>> that changing `headline' element to `heading' element type will break
>>> important packages like org-roam. And there is no good way to work
>>> around this. We cannot make symbol aliases in Elisp in scenarios like
>>> (memq (org-element-type ...) '(headline inlinetask)).
>>
>> We cannot make symbol aliases in Elisp but maybe we can support both
>> symbols for a transitory period during which we warn third-part devs
>> about replacing the deprecated 'headline symbol?
>
> The best idea I can come up with is the following:
>
> 1. We replace headline -> heading where it is safe
> 2. We introduce a new constant: org-element-heading-type, defaulting to
>    'headline
> 3. We use the new constant instead of 'headline element type symbol
> 4. We announce loudly that 'headline will be deprecated in favour of the
>    new constant
> 5. Few years later, we change the org-element-heading-type value to
>    'heading
>
>>> I came to the conclusion that it will, in fact, be easier to change all
>>> things to use "headline" -- all the instances of "heading" in Org code
>>> are in function names, variable names, and docstrings. All can be
>>> changed using obsolete aliases.
>>
>> Given Vikas and Tim feedback, I would rather move forward by changing
>> "headline" to "heading" *where it does not break anything* then see if
>> the proposed scenario above is workable.
>>
>> In this case, I believe it's better to be partially correct (heading
>> where possible) than to be consistently wrong (headline everywhere) :)
>>
>> WDYT?
>
> I tried, but it will be confusing when we talk about Org elements.
> Phrases like "Headline element" now make sense as they correspond to the
> element type. Changing to "Heading element" while keeping the actual
> element as (headline ...) sounds extremely confusing.
>
> That said, we may do what I proposed above and then use
> "`org-element-heading-type' element". Somewhat cumbersome, but at least
> less confusing.

I think we are needlessly complicating this. We are talking about the
use of a term in an internal code base. While I would agree heading is
more correct, I don't think it is such a big issue to use headline if
that make the transition to a consistent usage easier. When it comes to
code, I think consistency trumps correctness.

If agreement is not possible, my second vote would be for the status
quo. Leave it as it is and focus on more important issues that have a
real impact on users. 

Re: [RFC] Re: Headings and Headlines

[Vikas Rawal]

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

>
>
>
> I think we are needlessly complicating this. We are talking about the
> use of a term in an internal code base. While I would agree heading is
> more correct, I don't think it is such a big issue to use headline if
> that make the transition to a consistent usage easier. When it comes to
> code, I think consistency trumps correctness.
>
>
I agree. I think the original post was about inconsistency in the
documentation. We should just correct the documentation, use the word
heading consistently throughout, and mention at a prominent place that the
headline symbol is used in the code to parse headings. There is nothing
wrong with that.

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

Re: [RFC] Re: Headings and Headlines

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> I think we are needlessly complicating this. We are talking about the
> use of a term in an internal code base. While I would agree heading is
> more correct, I don't think it is such a big issue to use headline if
> that make the transition to a consistent usage easier. When it comes to
> code, I think consistency trumps correctness.

Changing documentation means changing function symbols.
Changing function symbols means changing the code.
Changing the code should not reduce code readability, which is of
paramount importance to keep new contributions coming.

That's why I also consider code consistency important.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [RFC] Re: Headings and Headlines

[Bastien]

Ihor Radchenko <yantar92@posteo.net> writes:

> The best idea I can come up with is the following:
>
> 1. We replace headline -> heading where it is safe

Yes, let's do this.

> 2. We introduce a new constant: org-element-heading-type, defaulting to
>    'headline
> 3. We use the new constant instead of 'headline element type symbol
> 4. We announce loudly that 'headline will be deprecated in favour of the
>    new constant
> 5. Few years later, we change the org-element-heading-type value to
>    'heading

I think this is okay too, though `org-element-heading-type' might not
be explicit enough: what about `org-element-heading-type-symbol'?

-- 
 Bastien

Re: [RFC] Re: Headings and Headlines

[Ihor Radchenko]

Bastien <bzg@gnu.org> writes:

>> 2. We introduce a new constant: org-element-heading-type, defaulting to
>>    'headline
>> 3. We use the new constant instead of 'headline element type symbol
>> 4. We announce loudly that 'headline will be deprecated in favour of the
>>    new constant
>> 5. Few years later, we change the org-element-heading-type value to
>>    'heading
>
> I think this is okay too, though `org-element-heading-type' might not
> be explicit enough: what about `org-element-heading-type-symbol'?

Agree. I was leaning towards having "symbol" in the name as well after
sleeping with the idea.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [RFC] Re: Headings and Headlines

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

> Bastien <bzg@gnu.org> writes:
>
>>> 2. We introduce a new constant: org-element-heading-type, defaulting to
>>>    'headline
>>> 3. We use the new constant instead of 'headline element type symbol
>>> 4. We announce loudly that 'headline will be deprecated in favour of the
>>>    new constant
>>> 5. Few years later, we change the org-element-heading-type value to
>>>    'heading
>>
>> I think this is okay too, though `org-element-heading-type' might not
>> be explicit enough: what about `org-element-heading-type-symbol'?
>
> Agree. I was leaning towards having "symbol" in the name as well after
> sleeping with the idea.

I looked into this further and I do not think that it is a good idea to
make this change in the coming release. Renaming some things is very too
easy to get wrong and cause failures.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [RFC] Re: Headings and Headlines

[Bastien]

Ihor Radchenko <yantar92@posteo.net> writes:

> I looked into this further and I do not think that it is a good idea to
> make this change in the coming release. Renaming some things is very too
> easy to get wrong and cause failures.

Yes, there is absolutely no rush for this.

-- 
 Bastien