Re: [RFC] Re: Headings and Headlines

[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, we change the org-element-heading-type value to
>>'heading
>
> I think this is okay too, though `org-element-heading-type' might not
> be explicit enough: what about `org-element-heading-type-symbol'?

Agree. I was leaning towards having "symbol" in the name as well after
sleeping with the idea.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Re: [STYLE] :version tags in defcustom definitions

[Ihor Radchenko]

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 about Org mode at .
Support Org development at ,
or support my work at 

Re: [RFC] Re: Headings and Headlines

[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 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 think this is okay too, though `org-element-heading-type' might not
be explicit enough: what about `org-element-heading-type-symbol'?

-- 
 Bastien

Re: [RFC] Re: Headings and Headlines

[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 it comes to
> code, I think consistency trumps correctness.

Changing documentation means changing function symbols.
Changing function symbols means changing the code.
Changing the code should not reduce code readability, which is of
paramount importance to keep new contributions coming.

That's why I also consider code consistency important.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Make fuzzy links practical

[Ihor Radchenko]

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
>
> instead in the common form
>
> * Chromosomal abnormality
>
> Based on my research, it seems that Org has changed how fuzzy links
> match headlines, case sensitively or insensitively, multiple times.

Can you recall the relevant commits/ML threads?

> To make fuzzy links more practical, we have more options, including:
>
> 1. case-fold headlines by default, optimizing for the common use case
> 2. add `'case-fold' to `org-link-search-must-match-exact-headline'
> 3. obey `case-fold-search' option set by the user
>
> What do you folks think?

Sounds reasonable.
But we need to study why case sensitivity has been flipped in the past.
Also, I am wondering how all this work on export.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Re: Link-words with spaces, allowed or not?

[Ihor Radchenko]

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 which makes it possible for me (and us all) to
> rely on this functionality working in the future!
>
> Can we install the patch to main?

Thanks for testing!
Applied onto main now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b2c805f3c
Fixed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 2 'echo' bash instructions produce a table

[Ihor Radchenko]

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 that would be checked upon?
>
> We could perhaps start with a simple `grep' in `Makefile' that executes
> on `make test'.

Generally, we document such things in doc/Documentation_Standards.org
Auto-checking with Makefile could work. Patches welcome ;)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: test-org-table/sort-lines: Failing test on macOS

[Ihor Radchenko]

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-lessp "a" "B" "C" t) ; => t
>
> I submitted the bug report to Emacs.
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59275


According to the discussion on debbugs, it looks like we can use
`compare-strings' instead. It will be independent of the system locale
and always follow Unicode rules.

However, I am not sure if ignoring locale is something we really want.
WDYT?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [RFC] Re: Headings and Headlines

[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
> code, I think consistency trumps correctness.
>
>
I agree. I think the original post was about inconsistency in the
documentation. We should just correct the documentation, use the word
heading consistently throughout, and mention at a prominent place that the
headline symbol is used in the code to parse headings. There is nothing
wrong with that.

Re: [RFC] Re: Headings and Headlines

[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 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. 

Re: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortman

[Daniel Ortmann]

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  writes:


I have several small sh source blocks with ':results none'. The source
is executed for effect and the last line of the source is:
... | tee /target/path/to/file.csv

⛔ Error (org-babel): Error reading results: (user-error "Region is
longer than ‘org-table-convert-region-max-lines’ (999) lines; not
converting")

I expected that :results none would simply drop the output rather than
complaining about it.

Even though it says "error", the results seem to be correct.

This is because blocks with :results none may still be used as input for
other source blocks as reference or noweb reference. So, the results are
computed, but not inserted or otherwise indicated.

Could you please provide a reproducer so that we fix the issue with
table conversion?



reproduce.org
Description: Lotus Organizer

Re: [RFC] Re: Headings and Headlines

[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 (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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [RFC] Re: Headings and Headlines

[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 headline”).

Ah, thanks a lot for this very clear explanation!

-- 
 Bastien

Re: [RFC] Re: Headings and Headlines

[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 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?

> 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?

-- 
 Bastien

Re: [RFC] Re: Headings and Headlines

[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
headings but only a single headline (which is specifically the line at the top,
e.g. “Newspaper headline”).

As Ihor points out though, from a compat perspective, a change to “heading” may
be intractable. This gives me rather mixed feelings, as I’m of a similar mind
regarding the org-element headline->heading change being too problematic, but
settling on the less accurate term seems quite undesirable too, and doesn’t sit
well with me.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [RFC] Re: Headings and Headlines

[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 one-line heading, so it's okay.
>
>
I think, from a linguistic perspective, "heading" and "subheading" are more
appropriate than "headline" and "subheadline".

Vikas

Re: [RFC] Re: Headings and Headlines

[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: [PATCH] Re: Link-words with spaces, allowed or not?

[Rudolf Adamkovič]

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 all) to
rely on this functionality working in the future!

Can we install the patch to main?

Rudy
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
-- Edsger Wybe Dijkstra, 1930-2002

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [PATCH] Re: Update Org to MathJax 3

[Bastien Guerry]

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 the list using X-Woof-Change: 9.6 as a header.

-- 
 Bastien

Re: About org-mode-tests and CI

[Bastien]

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

Re: [PATCH] Re: [STYLE] :version tags in defcustom definitions

[Bastien Guerry]

Ihor Radchenko  writes:

> Let me know if there are any objections.

None on my side, thanks for this.

-- 
 Bastien

Re: About org-mode-tests and CI

[Philip Kaludercic]

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 consider?

I am sorry, I know too little about Org and use it too superficially to
be of much use here.

> If so, that'd be very helpful. Let me know your SourceHut username
> and I'll give you access to https://git.sr.ht/~bzg/org-mode-tests/
>
> I am a paid user on SourceHut and I'm happy pulling org-mode-tests
> from the orgmode.org server to build from the latest repo manifests.
>
> Once we solve this maintenance issue, we might consider evolving
> the tests so that they use Guix instead of Debian if it provides a
> real benefit for our needs.
>
> In the meantime, this test infrastructure has already proven very
> useful IMHO.
>
> Thanks,

Re: About org-mode-tests and CI

[Bastien]

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 helpful. Let me know your SourceHut username
and I'll give you access to https://git.sr.ht/~bzg/org-mode-tests/

I am a paid user on SourceHut and I'm happy pulling org-mode-tests
from the orgmode.org server to build from the latest repo manifests.

Once we solve this maintenance issue, we might consider evolving
the tests so that they use Guix instead of Debian if it provides a
real benefit for our needs.

In the meantime, this test infrastructure has already proven very
useful IMHO.

Thanks,

-- 
 Bastien

Re: 2 'echo' bash instructions produce a table

[Rudolf Adamkovič]

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 could perhaps start with a simple `grep' in `Makefile' that executes
on `make test'.

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Make fuzzy links practical

[Rudolf Adamkovič]

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 a case-folded
"word", such as "word" or "Word".

I find this *almost* practical because, in the Org world, we normally
write headlines in either sentence case or title case, with the first
word capitalized.  But currently, if I have the text

> * 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

instead in the common form

* Chromosomal abnormality

Based on my research, it seems that Org has changed how fuzzy links
match headlines, case sensitively or insensitively, multiple times.

To make fuzzy links more practical, we have more options, including:

1. case-fold headlines by default, optimizing for the common use case
2. add `'case-fold' to `org-link-search-must-match-exact-headline'
3. obey `case-fold-search' option set by the user

What do you folks think?

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Volunteering to maintain ob-asymptote.el within Org

[Bastien]

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 to package ob-asymptote.el as a GNU ELPA package so that it
gets more users and let me know when this is done so that I can remove
it from org-contrib.

-- 
 Bastien