Ihor Radchenko 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
Ihor Radchenko writes:
> Bastien 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
Bastien 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, w
Ihor Radchenko 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 eleme
Tim Cross 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
>
>
>
> 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
>
Ihor Radchenko writes:
> Bastien writes:
>
>> Ihor Radchenko 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
Bastien writes:
> Ihor Radchenko 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-elem
Timothy 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
Ihor Radchenko 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 i
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
On Sat, 19 Nov 2022 at 19:17, Bastien Guerry wrote:
> Ihor Radchenko 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
Ihor Radchenko 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
Ihor Radchenko writes:
> André A. Gomes 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 instan
Rudolf Adamkovič 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 i
Ihor Radchenko 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
André A. Gomes 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
17 matches
Mail list logo