emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Bastien <bzg@gnu.org>, "André A. Gomes" <andremegafone@gmail.com>,
	Timothy <orgmode@tec.tecosaur.net>,
	emacs-orgmode@gnu.org
Subject: Re: [RFC] Re: Headings and Headlines
Date: Sun, 20 Nov 2022 10:04:31 +1100	[thread overview]
Message-ID: <86v8namtjd.fsf@gmail.com> (raw)
In-Reply-To: <87sfifkk5w.fsf@localhost>


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. 



  reply	other threads:[~2022-11-19 23:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 13:32 Headings and Headlines André A. Gomes
2021-07-23 13:56 ` Eric S Fraga
2021-07-23 15:43   ` Christopher Dimech
2021-07-23 15:47     ` Timothy
2021-07-23 15:55       ` Eric S Fraga
2021-07-23 14:04 ` Marco Wahl
2021-07-23 15:03   ` Kaushal Modi
2021-07-23 14:34 ` Timothy
2021-07-23 14:56   ` André A. Gomes
2021-07-23 15:39     ` Timothy
2021-07-24  2:06 ` Tim Cross
2021-07-24  4:04   ` Tom Gillespie
2021-07-24 11:49     ` Matt Price
2021-07-24 18:56   ` Charles Millar
2021-07-24 19:23 ` Timothy
2022-11-13  6:59 ` [RFC] " Ihor Radchenko
2022-11-13 21:10   ` Rudolf Adamkovič
2022-11-14  4:36     ` Ihor Radchenko
2022-11-16 22:16   ` Tim Cross
2022-11-19 13:46   ` Bastien Guerry
2022-11-19 14:34     ` Vikas Rawal
2022-11-19 15:03       ` Timothy
2022-11-19 15:54         ` Bastien Guerry
2022-11-19 15:54   ` Bastien
2022-11-19 16:01     ` Ihor Radchenko
2022-11-19 23:04       ` Tim Cross [this message]
2022-11-20  0:56         ` Vikas Rawal
2022-11-20  5:45         ` Ihor Radchenko
2022-11-20  5:46       ` Bastien
2022-11-20  5:53         ` Ihor Radchenko
2022-11-27  3:33           ` Ihor Radchenko
2022-11-27 10:32             ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86v8namtjd.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=andremegafone@gmail.com \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=orgmode@tec.tecosaur.net \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).