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
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> Let me know if there are any objections.
>
> None on my side, thanks for this.
Applied onto master.
https://git.sr.ht/~bzg/worg/commit/8dd5762e28876fce7193f96eed65356698e917f0
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more
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
Rudolf Adamkovič writes:
>> * Aneuploid
>>
>> An [[organism]] with a [[chromosomal abnormality]] regarding the
>> number of [[chromosome]]s. Includes [[monosomic]] and [[trisomic]]
>> individuals.
>
> the target headlines must appear in lowercase, such as
>
> * chromosomal abnormality
>
> instea
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> See the attached patch allowing the above syntax in #+LINK keywords.
>
> I finally got to test the patch (against the current `main' at commit
> 0b124d796) and it works perfectly. Thank you, also, for the inclusion
> of the automated test w
Rudolf Adamkovič writes:
> alain.coch...@unistra.fr writes:
>
>> So I was wondering if there could exist some (semi-)automatic way
>> which would ensure that future maintainers will not inadvertently
>> re-introduce "sub-tree" occurrences, or the like. Perhaps some
>> "accepted terminology" list
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> > (string-collate-lessp "a" "B" "C" t) ; => nil
>> Actually you wrote
>>> [FYI: If I replace nil with t, the procedure returns nil too.]
>> From my point of view it is a reason to file an Emacs bug because I get
>>
>> (string-collate-less
>
>
>
> 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
Please see attached which has the following code which reproduces the issue:
#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
head -c 6 /dev/urandom | uuencode -m -
done |
tee /dev/null
#+end_src
On 11/18/22 02:45, Ihor Radchenko wrote:
Daniel Ortmann wri
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:
> See the attached patch allowing the above syntax in #+LINK keywords.
I finally got to test the patch (against the current `main' at commit
0b124d796) and it works perfectly. Thank you, also, for the inclusion
of the automated test which makes it possible for me (and us
Ihor Radchenko writes:
> Is the current news entry is sufficient?
The ORG-NEWS entry in the patch looks good, thanks.
> Or should we do something in
> addition to announce backwards-incompatible change?
I suggest to make this change visible on update.orgmode.org by sending
an announcement to
Philip Kaludercic writes:
> I am sorry, I know too little about Org and use it too superficially to
> be of much use here.
No problem, and thanks for the super quick feedback!
--
Bastien
Ihor Radchenko writes:
> Let me know if there are any objections.
None on my side, thanks for this.
--
Bastien
Bastien writes:
> Thanks Simon for bringing this up!
>
> Our first need is to have someone volunteering for maintaining our
> current test infrastructure - Christian is helping with this right
> now but cannot afford to become the maintainer right now.
>
> Philip, is this something you would cons
Thanks Simon for bringing this up!
Our first need is to have someone volunteering for maintaining our
current test infrastructure - Christian is helping with this right
now but cannot afford to become the maintainer right now.
Philip, is this something you would consider?
If so, that'd be very h
alain.coch...@unistra.fr writes:
> So I was wondering if there could exist some (semi-)automatic way
> which would ensure that future maintainers will not inadvertently
> re-introduce "sub-tree" occurrences, or the like. Perhaps some
> "accepted terminology" list that would be checked upon?
We c
Hello everyone!
Given a fuzzy link [[word]], Org by default searches for a headline "*
word". If no such headline exists, Org asks the user if they wish to
create one. Then, the user can also set
`org-link-search-must-match-exact-headline'
to nil, in which case, Org will search the buffer for
Hi,
Ihor Radchenko writes:
> Bastien, ob-asymptote is still a part of org-contrib [1].
> Should we just go ahead and change the maintainer now?
>
> [1] https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/ob-asymptote.el
Yes, done. Thanks Jarmo for taking over the maintenance!
Feel free
26 matches
Mail list logo
