Re: [RFC] Re: Headings and Headlines

2022-11-27 Thread Bastien
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

Re: [RFC] Re: Headings and Headlines

2022-11-26 Thread Ihor Radchenko
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Ihor Radchenko
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,

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Ihor Radchenko
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Vikas Rawal
> > > > 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 >

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Tim Cross
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Ihor Radchenko
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien Guerry
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Timothy
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Vikas Rawal
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

Re: [RFC] Re: Headings and Headlines

2022-11-19 Thread Bastien Guerry
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

Re: [RFC] Re: Headings and Headlines

2022-11-16 Thread Tim Cross
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

Re: [RFC] Re: Headings and Headlines

2022-11-14 Thread Ihor Radchenko
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

Re: [RFC] Re: Headings and Headlines

2022-11-13 Thread Rudolf Adamkovič
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".

[RFC] Re: Headings and Headlines

2022-11-12 Thread Ihor Radchenko
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