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,
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
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
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
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
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
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
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".
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 "headlin
André A. Gomes writes:
> If the community finds this valuable, I could prepare a patch.
I think at this point the community view is pretty clearly in favour of
consolidating "headlines" to "headings".
I think at this stage a patch would be warranted. Should you sti
On 7/23/21 10:06 PM, Tim Cross wrote:
André A. Gomes writes:
Hi,
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.
If the community finds this valuable, I
I don't really have a strong preference for either but I would love to
remove the cognitive load of wondering whether the name is heading or
header!
On Sat., Jul. 24, 2021, 12:04 a.m. Tom Gillespie, wrote:
> I enthusiastically support changing the documentation to use heading.
> I use heading
I enthusiastically support changing the documentation to use heading.
I use heading in my formal grammar because I have found there are more
ways that it can be modified and remain grammatically correct when
used in english sentences. The internal implementation in elisp still
refers to headlines,
André A. Gomes writes:
> Hi,
>
> 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.
>
> If the community finds this valuable, I could
Just for completeness, definitions of both terms from WordNet:
heading
n 1: a line of text serving to indicate what the passage below
it is about; "the heading seemed to have little to do with
the text" [syn: {heading}, {header}, {head}]
headline
n 1: the
Christopher Dimech writes:
> Headline gave an indication that the heading is contained in a single line.
I feel the need to add that the strongest association with "headline" to
me is newspaper headlines, and I never think of an article having more
than one headline. On the other hand, I
Headline gave an indication that the heading is contained in a single line.
> Sent: Saturday, July 24, 2021 at 1:56 AM
> From: "Eric S Fraga"
> To: "André A. Gomes"
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Headings and Headlines
>
> I agree that c
André A. Gomes writes:
>> I am certainly of the mind that this would be a worthwhile change :)
>
> There's a problem though. Function names would have to be changed,
> which would have to wait for version 10 otherwise we'd ruin backwards
> compatibility.
I see 61 functions with "headline"
On Fri, Jul 23, 2021 at 10:07 AM Marco Wahl wrote:
> André A. Gomes writes:
>
> > The project's documentation refers to headings and headlines as
> > synonyms. Relying on a single definition would be beneficial.
>
> Agreed. E.g. no more thinking waste about the ques
Timothy writes:
> I am certainly of the mind that this would be a worthwhile change :)
There's a problem though. Function names would have to be changed,
which would have to wait for version 10 otherwise we'd ruin backwards
compatibility.
I think there's little sense in changing the wording
André A. Gomes writes:
> If the community finds this valuable, I could prepare a patch.
I am certainly of the mind that this would be a worthwhile change :)
--
Timothy
André A. Gomes writes:
> The project's documentation refers to headings and headlines as
> synonyms. Relying on a single definition would be beneficial.
Agreed. E.g. no more thinking waste about the question if it is
headline or heading?
> If I had to choose between the tw
I agree that consistency would be good and I also think heading is a
better choice than headline. The former's definition fits what it means
in org; the latter's is more equivalent to a title than anything else.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-598-g604bfd
: Latest paper
Hi,
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.
If the community finds this valuable, I could prepare a patch.
Thank you.
--
André A. Gomes
"
32 matches
Mail list logo
