[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.
- [RFC] Re: Headings and Headlines, Ihor Radchenko, 2022/11/13
- Re: [RFC] Re: Headings and Headlines, Bastien, 2022/11/19
- Re: [RFC] Re: Headings and Headlines, Ihor Radchenko, 2022/11/19
- Re: [RFC] Re: Headings and Headlines, Bastien, 2022/11/20
- Re: [RFC] Re: Headings and Headlines, Ihor Radchenko, 2022/11/20
- Re: [RFC] Re: Headings and Headlines, Ihor Radchenko, 2022/11/26
- Re: [RFC] Re: Headings and Headlines, Bastien, 2022/11/27