emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Re: Headings and Headlines


From: Tim Cross
Subject: Re: [RFC] Re: Headings and Headlines
Date: Sun, 20 Nov 2022 10:04:31 +1100
User-agent: mu4e 1.9.2; emacs 29.0.50

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 via email to

[Prev in Thread] Current Thread [Next in Thread]