Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

On Saturday, 26 Aug 2023 at 12:30, Ihor Radchenko wrote:
> That will indeed work. But then the todo will not appear in agenda.

Indeed.  Luckily, for me, I don't tend to want the actions within my
long documents to be listed in my agenda. Essentially, I have global
todo items (which appear in my agenda) and document (aka project)
specific ones which I only care about when working on that document
(project).  But...

> I think that a combination of drawers/special blocks + ability to
> assign todos/tags to paragraphs/tables/drawers/etc may give people
> what they usually need when using inlinetasks.

Yes, this capability would give the flexibility people want or need.

-- 
: Eric S Fraga, with org release_9.6.6-412-g2f7b35 in Emacs 30.0.50

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

"Fraga, Eric"  writes:

>> My personal use case is when using Org for authoring long texts.
>> I often leave inline tasks around the specific paragraph I need to
>> revise in future:
>
> For completeness, I will add that I do the same but using drawers at the
> point where I want to note a task, where the drawer is ~:todo:~.  I then
> have some special formatting for LaTeX export that converts such drawers
> into footnotes with a note in the margin.

That will indeed work. But then the todo will not appear in agenda.

I think that a combination of drawers/special blocks + ability to assign
todos/tags to paragraphs/tables/drawers/etc may give people what they
usually need when using inlinetasks.
 

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

On Wednesday, 23 Aug 2023 at 09:33, Ihor Radchenko wrote:
>> "Fraga, Eric"  writes:
>>
>>> I'll chime in regarding inlinetasks: I used to use these *a lot*
>>> but I
>>> found that drawers do what I needed in almost all cases very
>>> effectively (for my use cases).
>
> My personal use case is when using Org for authoring long texts.
> I often leave inline tasks around the specific paragraph I need to
> revise in future:

For completeness, I will add that I do the same but using drawers at the
point where I want to note a task, where the drawer is ~:todo:~.  I then
have some special formatting for LaTeX export that converts such drawers
into footnotes with a note in the margin.

-- 
: Eric S Fraga, with org release_9.6.6-412-g2f7b35 in Emacs 30.0.50

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> another idea, at the cost of 3 dumb messages in a row  there are
> annotation packages.  i wonder if integration of those is relevant.

Somewhat. The problem is when we want to associate inlinetask with
something more granular than a paragraph.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> i was also wondering if links and/or some type of transclusion could
> also obviate inline tasks.  the formerly-inline task would contain a
> link to a target above the paragraph.  c-c c-c on that location would
> take you back to the task.

I though about links to target paragraph. But that would require adding
#+name to paragraph in question or creating a long fuzzy search link -
very inconvenient when editing Org as plain text file. I'd prefer some
other approach, if possible.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

spookygos...@gmail.com writes:

> Bastien Guerry  writes:
>> …
>> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
>> a heading would fit 90% of what is expected from inline tasks in the
>> example you gave.
>> …
> There is functionality for a `:noexport:'  tag already built in. Do you 
> intend `:noheadingexport:'  to apply only to the top level of the tree it is 
> applied to? If so, that would probably not play nicely with tag inheritance.

Tag inheritance is not a problem. We can always add special tags to 
`org-tags-exclude-from-inheritance'.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

>> > I think Markdown has different levels?
>>
>> Do you mean # title vs. ## title?
>
> https://www.markdownguide.org/basic-syntax
>
> look at the alternate syntax where they under line with different symbols.

Ah. That thing. It will move Org towards more complex syntax. I am not
in favour.

> We have a solid heading syntax, with one or more asterisks followed by
> keywords and heading metadata. Given we're talking about adding more
> flags in the metadata, I'm just asking if we should consider
> alternatives to just asterisks to help indicate differences.
>
> An inline task exempt from folding should be eye catching to
> differentiate it from other headings. Perhaps something other than
> asterisks is appropriate?

Bastien voiced against adding yet more syntax elements. So, let's try to
find some way that will not involve completely new syntax element and
instead stick closer to the existing syntax.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

to...@tuxteam.de writes:

> Back to the case in question: Someone proposed intercalating a
> subsection instead of using an inline task, which would work
> if there were a way of "closing" that subsection; otherwise the
> idea messes with the document structure.

I see. This has been discussed previously. The main problem is that such
sections cannot be exported to latex/odt easily. So, we will complicate
export substantially.

And it will not be too different from the current approach. Even worse,
actually:

1. Similar to now, we will need to modify the parser, skipping some of
   the headings, that must no longer be considered proper headings, but
   rather "continuations"

2. We will have to allow nested proper headings inside sections, which
   will break logic all over the Org codebase.

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

[DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

[Ihor Radchenko]

Bastien Guerry  writes:

> I suggest removing the support for inline tasks *as they are designed
> today*, yes.

What I have in mind is slightly different: Keep inlinetasks for now and
implement a better alternative, which we can hopefully come up with in
this discussion. Later, promote the alternative, slowly deprecating the
current inlinetask implementation. Eventually, remove inlinetask code
from Org in favour of the new alternative.

> ...  I suggest reassessing the real problem we are trying to
> solve here, and see if we can come up with an approach that does not
> complexify Org's core syntax too much.

> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
> a heading would fit 90% of what is expected from inline tasks in the
> example you gave.

>...  Again, if the core feature is
> to prevent some headings from being exported, then other approaches
> can be explored.

May you elaborate? Is it something similar to :ignore: tag from ox-extra
contributed package?

If so, it is not what the use-cases I have in mind are about:

1. Inlinetasks should be exported as "boxes" - something similar to
   margin or inline notes
   - Can be used as a memo TODO in draft publication printout
   - As Samuel suggested, inlinetasks could be a basis of review
 comments - like what GDocs/Office provides in margin "chat"

2. When folding, I expect inlinetasks to behave like drawers/blocks -
   not hiding the continuation text below.

>> Yup. That's why I think that we need to make inlinetasks have distinct
>> syntax.
>
> I'm reluctant to supercharge Org's core syntax for this feature.
> I may be wrong, but I'd love to see if inline tasks are widely used,
> and if so, for what specific purpose.

I understand and tend to agree that it would be best to avoid extending
Org syntax too much.

Generally, the two points I listed above can be accomplished if we use
ordinary headings with a special tag. However, I am also not fully sold
on such idea. It would be nice if inlinetasks would not require adding
many stars in front, even in deeply nested subtrees.

What about another popular request - people often want to turn plain
lists into a kind of headings? We might introduce a new list type

 ** TODO this is a list, serving just like inlinetask :tag1:tag2:
:PROPERTIES:
<...>
:END:
 *1. DONE numbered list

The idea is that one just needs two stars " **" to create such list -
very convenient and in line with the proper heading syntax.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

>> Is there any hurry to delete things? If we still keep a new syntax open
>> for discussion, I see no reason to remove anything.
>
> Certainly no hurry. Just expressing my opinion. You know the code much
> better than I, I'm just trying to defend maintainer time from extra
> work.

I am personally interested to maintain inlinetasks.

> Maybe start a new email thread for a RFC regarding a potential
> replacement inline task syntax that would be cleaner for the code,
> parser, and easier to maintain?

Yup. We are too far away from the subject now. I will start a new thread
in a reply to Bastien.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

> Do we have a concrete summary of individual features that inline tasks
> have?
>
> I'm hearing exempt from folding, and support for drawers/heading
> items.
>
> What else?

Well. Everything normal headings have, except things that cannot be done
the same way due to inlinetasks being surrounded by non-headline
elements.

In particular, export cannot be made the same - "inline" sections are
meaningless in most export backends, like latex or odt. Instead,
inlinetasks are exported as a kind of minipage/box.

Also, folding of inlinetasks is handled like folding of drawers/blocks -
separately from subtree cycling.

Similar story for M-/ - handled like drawers/blocks.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[spookygostee]

Bastien Guerry  writes:
> …
> E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
> a heading would fit 90% of what is expected from inline tasks in the
> example you gave.
> …
There is functionality for a `:noexport:'  tag already built in. Do you intend 
`:noheadingexport:'  to apply only to the top level of the tree it is applied 
to? If so, that would probably not play nicely with tag inheritance.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[spookygostee]

Russell Adams  writes:

> On Thu, Aug 24, 2023 at 01:44:03PM +, Ihor Radchenko wrote:
>> Russell Adams  writes:
>>
>> >> What do you mean?
>> >
>> > I think Markdown has different levels?
>>
>> Do you mean # title vs. ## title?
>
> 
>
> look at the alternate syntax where they under line with different symbols.
>
>> > Has there ever been a reason to diversify the heading syntax to allow
>> > levels or changes in visibility?
>> >
>> > ** TODO
>> >
>> > `=' TODO Inline item under todo
>> >
>> > — DONE something else?
>> >
>> > ### TODO invis to all except interactive editing
>>
>> That’s even more features. I feel confused about what you are trying to
>> convey.
>
> It is, but it’s just brainstorming along the lines of needing an
> inline task syntax.
>
> We have a solid heading syntax, with one or more asterisks followed by
> keywords and heading metadata. Given we’re talking about adding more
> flags in the metadata, I’m just asking if we should consider
> alternatives to just asterisks to help indicate differences.
>
> An inline task exempt from folding should be eye catching to
> differentiate it from other headings. Perhaps something other than
> asterisks is appropriate?
>
> ——
> Russell Adamsrlad...@adamsinfoserv.com
> 

As someone who only uses orgmode, I personally find the logical distinction 
between inline and normal headings not compelling enough to justify adding new 
syntax besides asterisks. Frequently I hear orgmode’s extremely simple syntax 
lauded in comparison to something like markdown. Just some thoughts.

–shortcut

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

another idea, at the cost of 3 dumb messages in a row  there are
annotation packages.  i wonder if integration of those is relevant.

On 8/24/23, Samuel Wales  wrote:
> [p.s.  not saying this will satisfy ardent users, just bringing up the
> idea in case it is of use.]
>
>
> On 8/24/23, Samuel Wales  wrote:
>> iiuc bastien brought up the use of a no export this heading tag as an
>> alternative to inline tasks.  we have much or all of this capability
>> in faq.
>>
>> i was thinking the same thing.  perhaps many use cases could have
>> inline tasks as siblings below the document heading, and undesired
>> headers could be just not exported.
>>
>> i was also wondering if links and/or some type of transclusion could
>> also obviate inline tasks.  the formerly-inline task would contain a
>> link to a target above the paragraph.  c-c c-c on that location would
>> take you back to the task.
>>
>>
>> On 8/24/23, Max Nikulin  wrote:
>>> On 24/08/2023 19:21, Ihor Radchenko wrote:
 As I described, I often want inlinetasks to be exported and to be
 displayed in my agenda/sparse tree views
>>>
>>> It sounds like that if agenda had hooks allowing to gather either
>>> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
>>> custom blocks then ** END would not be necessary.
>>>
>>>
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

[p.s.  not saying this will satisfy ardent users, just bringing up the
idea in case it is of use.]


On 8/24/23, Samuel Wales  wrote:
> iiuc bastien brought up the use of a no export this heading tag as an
> alternative to inline tasks.  we have much or all of this capability
> in faq.
>
> i was thinking the same thing.  perhaps many use cases could have
> inline tasks as siblings below the document heading, and undesired
> headers could be just not exported.
>
> i was also wondering if links and/or some type of transclusion could
> also obviate inline tasks.  the formerly-inline task would contain a
> link to a target above the paragraph.  c-c c-c on that location would
> take you back to the task.
>
>
> On 8/24/23, Max Nikulin  wrote:
>> On 24/08/2023 19:21, Ihor Radchenko wrote:
>>> As I described, I often want inlinetasks to be exported and to be
>>> displayed in my agenda/sparse tree views
>>
>> It sounds like that if agenda had hooks allowing to gather either
>> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
>> custom blocks then ** END would not be necessary.
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

iiuc bastien brought up the use of a no export this heading tag as an
alternative to inline tasks.  we have much or all of this capability
in faq.

i was thinking the same thing.  perhaps many use cases could have
inline tasks as siblings below the document heading, and undesired
headers could be just not exported.

i was also wondering if links and/or some type of transclusion could
also obviate inline tasks.  the formerly-inline task would contain a
link to a target above the paragraph.  c-c c-c on that location would
take you back to the task.


On 8/24/23, Max Nikulin  wrote:
> On 24/08/2023 19:21, Ihor Radchenko wrote:
>> As I described, I often want inlinetasks to be exported and to be
>> displayed in my agenda/sparse tree views
>
> It sounds like that if agenda had hooks allowing to gather either
> :inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask
> custom blocks then ** END would not be necessary.
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

On 24/08/2023 19:21, Ihor Radchenko wrote:

As I described, I often want inlinetasks to be exported and to be
displayed in my agenda/sparse tree views


It sounds like that if agenda had hooks allowing to gather either 
:inlinetask:...:end: drawers or #+begin_inlinetask...#+end_inlinetask 
custom blocks then ** END would not be necessary.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote:
> > Regressions are not the end of the world. Org does too much and grew
> > very fast, which is not sustainable.
>
> But they should not be taken lightly either.
> https://bzg.fr/en/the-software-maintainers-pledge/

I wouldn't recommend taking them lightly, but I think "never" is too
strong a word.

Org's grown so much and so fast, and has limited maintainer time. If
the choice is between keeping Org up to date in Emacs and working,
versus a problem feature, then it's appropriate to remove problems for
the health of the core.

Let's not remove on a whim.


--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> org-inlinetask.el cannot exist outside Org core without all the extra
> support for inlinetasks across Org codebase.

I'm aware of this.

> So, what you are suggesting will completely remove inlinetasks
> feature.

I suggest removing the support for inline tasks *as they are designed
today*, yes.  I suggest reassessing the real problem we are trying to
solve here, and see if we can come up with an approach that does not
complexify Org's core syntax too much.

E.g. perhaps allowing a :noheadingexport: tag to prevent the export of
a heading would fit 90% of what is expected from inline tasks in the
example you gave.

> Yup. That's why I think that we need to make inlinetasks have distinct
> syntax.

I'm reluctant to supercharge Org's core syntax for this feature.
I may be wrong, but I'd love to see if inline tasks are widely used,
and if so, for what specific purpose.  Again, if the core feature is
to prevent some headings from being exported, then other approaches
can be explored.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:44:03PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
>
> >> What do you mean?
> >
> > I think Markdown has different levels?
>
> Do you mean # title vs. ## title?

https://www.markdownguide.org/basic-syntax

look at the alternate syntax where they under line with different symbols.

> > Has there ever been a reason to diversify the heading syntax to allow
> > levels or changes in visibility?
> >
> > ** TODO
> >
> > === TODO Inline item under todo
> >
> > --- DONE something else?
> >
> > ### TODO invis to all except interactive editing
>
> That's even more features. I feel confused about what you are trying to
> convey.

It is, but it's just brainstorming along the lines of needing an
inline task syntax.

We have a solid heading syntax, with one or more asterisks followed by
keywords and heading metadata. Given we're talking about adding more
flags in the metadata, I'm just asking if we should consider
alternatives to just asterisks to help indicate differences.

An inline task exempt from folding should be eye catching to
differentiate it from other headings. Perhaps something other than
asterisks is appropriate?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[tomas]

On Thu, Aug 24, 2023 at 01:29:22PM +, Ihor Radchenko wrote:
>  writes:
> 
> >>
> >><...>
> >
> > Ah... it would be nice if Org could "go up one level",
> > wouldn't it?
> 
> What do you mean?

Not proposing to change anything, Org is what it is. Org's "sections"
are somewhat stepchildren, since the primary structure is the heading.

As a consequence, you "close" a section by "opening" a new one; if
you start a subsection, you can't end it "going back" to the enclosing
section: express this in Org:

  
this is some text in the main section
More text


(FWIW I cop out of this by declaring that a section name of - means
"going up" like so:

  * Main Section
this is some text in the main section
More text
  ** A Subsection
 Some text therein
  * -
Now we are "back" in the main section

(Note that here, the "-" gets one star, i.e. the level we are going
back to: this way, most things work as they should; and it is not
too hard to hack exporters to do the right thing :)

Back to the case in question: Someone proposed intercalating a
subsection instead of using an inline task, which would work
if there were a way of "closing" that subsection; otherwise the
idea messes with the document structure.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:41:39PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
>
> >> * [#inline] Inlinetask
> >> * [#inline] END
> >
> > I think the multiline aspect is where the concept breaks down.
> >
> > "I want a special invisible heading inside the content of a heading,
> > that also supports optional multiline contents". Sounds horrible to code.
>
> It is not. The horrible part is that we rely on some things working
> magically without special account for inlinetask existance. Otherwise,
> it is just a matter of extra cond.

So then, refinement?

> > Given limited maintainer time, culling bad features is a fact of life.
>
> _I_ actively use inlinetasks. And it is not a bad feature by itself. The
> current syntax is bad, yes. And the current state with inlinetasks being
> optional feature.
>
> > My recommendation is cut it out, until someone with more time can make
> > a rational and compelling case for a clean syntax that isn't a huge
> > special case or write a separate module.
>
> Is there any hurry to delete things? If we still keep a new syntax open
> for discussion, I see no reason to remove anything.

Certainly no hurry. Just expressing my opinion. You know the code much
better than I, I'm just trying to defend maintainer time from extra
work.

Maybe start a new email thread for a RFC regarding a potential
replacement inline task syntax that would be cleaner for the code,
parser, and easier to maintain?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

>> It will. And it will also break some of my workflows :(
>
> I think that's unfortunate, but perhaps it would improve the health of
> the codebase?

Removing most features would improve health of the codebase. Like
getting rid of agenda with its horrible code. But it does not mean that
we should do it.

>> > Could we normalize the code if some of the features were enabled in a
>> > cookie/flag on a heading?
>>
>> We would need to put more special cases. Which has pros and cons,
>> actually. The downside is more special cases. The upside is that most of
>> inlinetask bugs are originating from the same code handling both
>> inlinetasks and headings without accounting for their differences.
>
> It sounds like the code would be cleaner in a single place using a cookie.

The cleanest would be something that does not match `org-outline-regexp-bol'.
Then, we will avoid all the possible confusion between tasks and inlinetasks.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

>> What do you mean?
>
> I think Markdown has different levels?

Do you mean # title vs. ## title?

> Has there ever been a reason to diversify the heading syntax to allow
> levels or changes in visibility?
>
> ** TODO
>
> === TODO Inline item under todo
>
> --- DONE something else?
>
> ### TODO invis to all except interactive editing

That's even more features. I feel confused about what you are trying to
convey.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:36:39PM +, Ihor Radchenko wrote:
> > And that's part of the confusion: inline tasks _look like_ normal
> > tasks while behaving differently.
>
> Yup. That's why I think that we need to make inlinetasks have distinct
> syntax.

Do we have a concrete summary of individual features that inline tasks
have?

I'm hearing exempt from folding, and support for drawers/heading
items.

What else?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

>> * [#inline] Inlinetask
>> * [#inline] END
>
> I think the multiline aspect is where the concept breaks down.
>
> "I want a special invisible heading inside the content of a heading,
> that also supports optional multiline contents". Sounds horrible to code.

It is not. The horrible part is that we rely on some things working
magically without special account for inlinetask existance. Otherwise,
it is just a matter of extra cond.

>> Because it will be feature regression.
>> And it will not be possible with a custom plugin without significant
>> changes in how all the headline editing commands, agenda, sparse trees,
>> etc work - they all assume very specific heading syntax.
>
> Regressions are not the end of the world. Org does too much and grew
> very fast, which is not sustainable.

But they should not be taken lightly either.
https://bzg.fr/en/the-software-maintainers-pledge/

> Given limited maintainer time, culling bad features is a fact of life.

_I_ actively use inlinetasks. And it is not a bad feature by itself. The
current syntax is bad, yes. And the current state with inlinetasks being
optional feature.

> My recommendation is cut it out, until someone with more time can make
> a rational and compelling case for a clean syntax that isn't a huge
> special case or write a separate module.

Is there any hurry to delete things? If we still keep a new syntax open
for discussion, I see no reason to remove anything.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:33:01PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
>
> > I hear "we have a bunch of extra complex code for an ill defined
> > special case". Org's designed around headings, and this special case
> > was a hack to abuse the threshold for heading detection to support a
> > nonstandard heading.
>
> It was a hack to reduce the amount of special cases in the existing
> code.
>
> > Sometimes there are features we just can't support.
> >
> > Would removing inline tasks in core clean up anything?
>
> It will. And it will also break some of my workflows :(

I think that's unfortunate, but perhaps it would improve the health of
the codebase?

> > Could we normalize the code if some of the features were enabled in a
> > cookie/flag on a heading?
>
> We would need to put more special cases. Which has pros and cons,
> actually. The downside is more special cases. The upside is that most of
> inlinetask bugs are originating from the same code handling both
> inlinetasks and headings without accounting for their differences.

It sounds like the code would be cleaner in a single place using a cookie.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:29:22PM +, Ihor Radchenko wrote:
>  writes:
>
> >>
> >><...>
> >
> > Ah... it would be nice if Org could "go up one level",
> > wouldn't it?
>
> What do you mean?

I think Markdown has different levels?

It is interesting to think that Org has only one kind of heading:

** ...

Has there ever been a reason to diversify the heading syntax to allow
levels or changes in visibility?

** TODO

=== TODO Inline item under todo

--- DONE something else?

### TODO invis to all except interactive editing




--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

>> I do not think that it would be possible. In order to support
>> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
>> modify the internals. I see no way around that.
>
> Maybe we are miscommunicating: my suggestion is to _remove_
> lisp/org-inlinetask.el from Org's core.

org-inlinetask.el cannot exist outside Org core without all the extra
support for inlinetasks across Org codebase.

So, what you are suggesting will completely remove inlinetasks feature.

>> Too many aspects of Org are designed for one specific heading syntax.
>> Even modifying inlinetask *... syntax will likely require adding
>> more special support where things "magically" work for now because
>> inlinetasks often look the same as headings.
>
> And that's part of the confusion: inline tasks _look like_ normal
> tasks while behaving differently.

Yup. That's why I think that we need to make inlinetasks have distinct
syntax.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

> I hear "we have a bunch of extra complex code for an ill defined
> special case". Org's designed around headings, and this special case
> was a hack to abuse the threshold for heading detection to support a
> nonstandard heading.

It was a hack to reduce the amount of special cases in the existing
code.

> Sometimes there are features we just can't support.
>
> Would removing inline tasks in core clean up anything?

It will. And it will also break some of my workflows :(

> Could we normalize the code if some of the features were enabled in a
> cookie/flag on a heading?

We would need to put more special cases. Which has pros and cons,
actually. The downside is more special cases. The upside is that most of
inlinetask bugs are originating from the same code handling both
inlinetasks and headings without accounting for their differences.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

 writes:

>>
>><...>
>
> Ah... it would be nice if Org could "go up one level",
> wouldn't it?

What do you mean?

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[tomas]

On Thu, Aug 24, 2023 at 02:36:31PM +0200, Bastien Guerry wrote:
> Ihor Radchenko  writes:
> 
> > ** Section X
> >
> > 
> >
> > 
> > <...>
> > 
> > <...>
> > 
> > <...>
> >
> > *** TODO Task for paragraph N
> >
> > Then, if I jump to the TODO, for example, from agenda view, I still need
> > to somehow find  location, which is awkward when the
> > section has multiple screens of text.
> 
> And what about this?
> 
>** Section X
>
>
>
>
><...>
>
>*** TODO Task for paragraph N
>
>
><...>
>
><...>

Ah... it would be nice if Org could "go up one level",
wouldn't it?

;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 01:04:10PM +, Ihor Radchenko wrote:
> Russell Adams  writes:
> We might. Adding gazillion of stars is not conceptually different from
> adding a spacial cookie.

True. Just cleaner.

> The only extra thing required is some way to mark inlinetask ending,
> because we must be able to continue the containing section below
> inlinetask:
>
> * [#inline] Inlinetask
> * [#inline] END

I think the multiline aspect is where the concept breaks down.

"I want a special invisible heading inside the content of a heading,
that also supports optional multiline contents". Sounds horrible to code.

> > Shouldn't this be excluded from core and supplied by someone's custom
> > plugin if they want this ability? Org-mode should focus on the
> > headings and their data, and if you need to hack in some extra syntax
> > perhaps Org doesn't need to concern itself.
>
> Because it will be feature regression.
> And it will not be possible with a custom plugin without significant
> changes in how all the headline editing commands, agenda, sparse trees,
> etc work - they all assume very specific heading syntax.

Regressions are not the end of the world. Org does too much and grew
very fast, which is not sustainable.

There were other mails in this thread that agreed this might be an ill
conceived feature hack.

Given limited maintainer time, culling bad features is a fact of life.

My recommendation is cut it out, until someone with more time can make
a rational and compelling case for a clean syntax that isn't a huge
special case or write a separate module.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

>> I see.  So not only inline tasks are ugly syntactic-wise, but they
>> also have a specific behavior when exporting.  All this pleas for an
>> external module, not for something we support in Org's core IMHO.
>
> I do not think that it would be possible. In order to support
> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
> modify the internals. I see no way around that.

Maybe we are miscommunicating: my suggestion is to _remove_
lisp/org-inlinetask.el from Org's core.

> Too many aspects of Org are designed for one specific heading syntax.
> Even modifying inlinetask *... syntax will likely require adding
> more special support where things "magically" work for now because
> inlinetasks often look the same as headings.

And that's part of the confusion: inline tasks _look like_ normal
tasks while behaving differently.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 12:56:01PM +, Ihor Radchenko wrote:
> Bastien Guerry  writes:
>
> > Ihor Radchenko  writes:
> >
> >> This will break export and folding.
> >> Also, I often simply archive inlinetasks once they are done. The above
> >> will archive too much.
> >
> > I see.  So not only inline tasks are ugly syntactic-wise, but they
> > also have a specific behavior when exporting.  All this pleas for an
> > external module, not for something we support in Org's core IMHO.
>
> I do not think that it would be possible. In order to support
> inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
> modify the internals. I see no way around that.
>
> Too many aspects of Org are designed for one specific heading syntax.
> Even modifying inlinetask *... syntax will likely require adding
> more special support where things "magically" work for now because
> inlinetasks often look the same as headings.

I hear "we have a bunch of extra complex code for an ill defined
special case". Org's designed around headings, and this special case
was a hack to abuse the threshold for heading detection to support a
nonstandard heading.

Sometimes there are features we just can't support.

Would removing inline tasks in core clean up anything?

Could we normalize the code if some of the features were enabled in a
cookie/flag on a heading?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

> So just to be clear, we want a method to make a heading with all the
> features of headings, but that isn't a heading or treated like a
> heading?

> Isn't the key feature that the inline task is a heading except it is
> exempt from the folding logic (ie: sparse tree)?

> Why can't we do this with a flag or cookie in a heading? We already
> have priority cookies.

We might. Adding gazillion of stars is not conceptually different from
adding a spacial cookie.

The only extra thing required is some way to mark inlinetask ending,
because we must be able to continue the containing section below
inlinetask:

* [#inline] Inlinetask
* [#inline] END

> Shouldn't this be excluded from core and supplied by someone's custom
> plugin if they want this ability? Org-mode should focus on the
> headings and their data, and if you need to hack in some extra syntax
> perhaps Org doesn't need to concern itself.

Because it will be feature regression.
And it will not be possible with a custom plugin without significant
changes in how all the headline editing commands, agenda, sparse trees,
etc work - they all assume very specific heading syntax.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> This will break export and folding.
>> Also, I often simply archive inlinetasks once they are done. The above
>> will archive too much.
>
> I see.  So not only inline tasks are ugly syntactic-wise, but they
> also have a specific behavior when exporting.  All this pleas for an
> external module, not for something we support in Org's core IMHO.

I do not think that it would be possible. In order to support
inlinetasks in agenda/sparse trees/todo setting/tag setting, we need to
modify the internals. I see no way around that.

Too many aspects of Org are designed for one specific heading syntax.
Even modifying inlinetask *... syntax will likely require adding
more special support where things "magically" work for now because
inlinetasks often look the same as headings.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 12:40:50PM +, Ihor Radchenko wrote:
> Bastien Guerry  writes:
> This will break export and folding.
> Also, I often simply archive inlinetasks once they are done. The above
> will archive too much.

So just to be clear, we want a method to make a heading with all the
features of headings, but that isn't a heading or treated like a
heading?

Isn't the key feature that the inline task is a heading except it is
exempt from the folding logic (ie: sparse tree)?

Why can't we do this with a flag or cookie in a heading? We already
have priority cookies.

If the inline task also doesn't impact the tree structure of the
parent heading, that's an even taller order. That's where plain lists
are OK, they just lack the extra functionality of a heading (ie: drawers).

I don't see any solution that isn't really hacky.

Shouldn't this be excluded from core and supplied by someone's custom
plugin if they want this ability? Org-mode should focus on the
headings and their data, and if you need to hack in some extra syntax
perhaps Org doesn't need to concern itself.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> This will break export and folding.
> Also, I often simply archive inlinetasks once they are done. The above
> will archive too much.

I see.  So not only inline tasks are ugly syntactic-wise, but they
also have a specific behavior when exporting.  All this pleas for an
external module, not for something we support in Org's core IMHO.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

>> Then, if I jump to the TODO, for example, from agenda view, I still need
>> to somehow find  location, which is awkward when the
>> section has multiple screens of text.
>
> And what about this?
>
>** Section X
>
>
>
>
><...>
>
>*** TODO Task for paragraph N
>
>
><...>
>
><...>

This will break export and folding.
Also, I often simply archive inlinetasks once they are done. The above
will archive too much.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> ** Section X
>
> 
>
> 
> <...>
> 
> <...>
> 
> <...>
>
> *** TODO Task for paragraph N
>
> Then, if I jump to the TODO, for example, from agenda view, I still need
> to somehow find  location, which is awkward when the
> section has multiple screens of text.

And what about this?

   ** Section X
   
   
   
   
   <...>
   
   *** TODO Task for paragraph N
   
   
   <...>
   
   <...>
   
-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

> * Item
>
> Wubba lubba ding dong.
>
> # TODO fix this to pig latin
>
> Arff!!
>
> * Other stuff
>
>
> Doesn't this really come down to a use case for having headings which
> are excluded from operations like comments are?

Nope. As I described, I often want inlinetasks to be exported and to be
displayed in my agenda/sparse tree views:

1. On export, I will see

1 Item
══

  Wubba lubba ding dong.

  ━━
  TODO fix this to pig latin
  ━━
  Arff!!


2 Other staff
═

2. I can also use the inlinetask normally, scheduling it, adding notes
   to it, etc

> Could we treat #'s as inline headings? Not sure how that'd handle
> drawers.

#'s are excluded from export unconditionally. Also, more complex
 inlinetasks may contain normal Org markup and elements, which make no
 sense in comments.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> The benefit is that I do not need to search for that "paragraph N" when
>> I want to work on the task. I simply jump to the task location and can
>> immediately see the paragraph it refers to.
>
> But this would be the same with a non-inlined task, right?

No. For non-inlined task, I'd have to put the task somewhere far away
from the paragraph text:

** Section X




<...>

<...>

<...>

*** TODO Task for paragraph N

Then, if I jump to the TODO, for example, from agenda view, I still need
to somehow find  location, which is awkward when the
section has multiple screens of text.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Thu, Aug 24, 2023 at 11:44:29AM +, Ihor Radchenko wrote:
> Bastien Guerry  writes:
>
> >> * TODO Consider explaining more about X
> >> 
> >>
> >> <...>
> >>
> >> Then, I can easily review the manuscript status using sparse tree or
> >> agenda view.
> >
> > I see -- but what is the real benefit of inline tasks here over normal
> > tasks?  I understand that  should not be considered as
> > the details for a task, but rather its "target", but inline task does
> > not seem to add much here.
>
> The benefit is that I do not need to search for that "paragraph N" when
> I want to work on the task. I simply jump to the task location and can
> immediately see the paragraph it refers to.
>
> Also, pdf export of such inlinetask will nicely mark the TODO item in
> the manuscript draft, so that I can print things, and still see what
> should be done in that particular location of the manuscript.

Interesting. I often will use comments when I need to update things in
a document to be exported.

* Item

Wubba lubba ding dong.

# TODO fix this to pig latin

Arff!!

* Other stuff


Doesn't this really come down to a use case for having headings which
are excluded from operations like comments are?

Could we treat #'s as inline headings? Not sure how that'd handle
drawers.



--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> The benefit is that I do not need to search for that "paragraph N" when
> I want to work on the task. I simply jump to the task location and can
> immediately see the paragraph it refers to.

But this would be the same with a non-inlined task, right?

> Also, pdf export of such inlinetask will nicely mark the TODO item in
> the manuscript draft, so that I can print things, and still see what
> should be done in that particular location of the manuscript.

Yes, I see.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

>> * TODO Consider explaining more about X
>> 
>>
>> <...>
>>
>> Then, I can easily review the manuscript status using sparse tree or
>> agenda view.
>
> I see -- but what is the real benefit of inline tasks here over normal
> tasks?  I understand that  should not be considered as
> the details for a task, but rather its "target", but inline task does
> not seem to add much here.

The benefit is that I do not need to search for that "paragraph N" when
I want to work on the task. I simply jump to the task location and can
immediately see the paragraph it refers to.

Also, pdf export of such inlinetask will nicely mark the TODO item in
the manuscript draft, so that I can print things, and still see what
should be done in that particular location of the manuscript.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> My personal use case is when using Org for authoring long texts.
> I often leave inline tasks around the specific paragraph I need to
> revise in future:
>
> * Section XX
> 
>
> 
>
> <...>
>
> * TODO Consider explaining more about X
> 
>
> <...>
>
> Then, I can easily review the manuscript status using sparse tree or
> agenda view.

I see -- but what is the real benefit of inline tasks here over normal
tasks?  I understand that  should not be considered as
the details for a task, but rather its "target", but inline task does
not seem to add much here.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

> "Fraga, Eric"  writes:
>
>> I'll chime in regarding inlinetasks: I used to use these *a lot* but I
>> found that drawers do what I needed in almost all cases very
>> effectively (for my use cases).
>
> It resonates with my experience too and I suspect (and kinda hope)
> many inlinetasks users will feel the same once they use drawers.

My personal use case is when using Org for authoring long texts.
I often leave inline tasks around the specific paragraph I need to
revise in future:

* Section XX




<...>

* TODO Consider explaining more about X


<...>

Then, I can easily review the manuscript status using sparse tree or
agenda view.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Mon, Aug 14, 2023 at 01:19:07PM +, Fraga, Eric wrote:
> I'll chime in regarding inlinetasks: I used to use these *a lot* but I
> found that drawers do what I needed in almost all cases very
> effectively (for my use cases).

Can you give an example?

I always hear the meeting notes with a short tasklist example. That
plain list checkboxes aren't enough, the extra metadata is desired.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

"Fraga, Eric"  writes:

> I'll chime in regarding inlinetasks: I used to use these *a lot* but I
> found that drawers do what I needed in almost all cases very
> effectively (for my use cases).

It resonates with my experience too and I suspect (and kinda hope)
many inlinetasks users will feel the same once they use drawers.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Tom Gillespie  writes:

>> Any other ideas? I'd be happy to see some brain-storming.
>
> Maybe a #+keyword[options]: that doubles as a dynamic block or
> something like that?
> #+inline_task[options]: TODO some tiny task
> #+inline_task[options]: TODO some small task
> DEADLINE: <2023-11-11>
> :PROPERTIES:
> :SOMETHING: or other
> :END:
> #+inline_task_end:

I am not sure if I like [options]. If we support property drawer, why
would we need additional options? I'd rather stick closer to the heading
syntax (but without that 15x... madness).

I also _slightly_ do not like #+... syntax because I expect some
interference with fontification code for "meta lines".

> Migration path should be straight forward, the exact implementation of
> the behavior might need
> a bit of work, and I'm not sure that the scheduling line will work in
> that context, it is too fart
> outside the usual behavior for keywords. However it might be possible
> to move the deadline into [options]
> the syntax would be a bit different than regular scheduling lines, but
> it would at least be consistent
> with keyword syntax.

It would actually be a headache to move planning into options.
A number of places in Org hard-code planning line regexp and will have
to be modified significantly to accommodate [options]. In particular, I
have org-agenda in mind (the place I rarely dare to touch)

> The other question is whether you actually need an #+inline_task_end:
> or whether there is another way.

Another idea might be similar to footnote definitions that mark their
end with double blank line. But I do not like footnote definition syntax
because it makes it impossible to have something like

[fn:1] Footnote definition containing src block
#+begin_src elisp
"This has


two newlines and not an src block anymore because
footnote definition ending takes precedence"
#+end_src

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Tom Gillespie]

> Any other ideas? I'd be happy to see some brain-storming.

Maybe a #+keyword[options]: that doubles as a dynamic block or
something like that?
#+inline_task[options]: TODO some tiny task
#+inline_task[options]: TODO some small task
DEADLINE: <2023-11-11>
:PROPERTIES:
:SOMETHING: or other
:END:
#+inline_task_end:

Migration path should be straight forward, the exact implementation of
the behavior might need
a bit of work, and I'm not sure that the scheduling line will work in
that context, it is too fart
outside the usual behavior for keywords. However it might be possible
to move the deadline into [options]
the syntax would be a bit different than regular scheduling lines, but
it would at least be consistent
with keyword syntax.

The other question is whether you actually need an #+inline_task_end:
or whether there is another way.

The idea could use a few more iterations.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Russell Adams  writes:

> Couldn't we use something like headings using ++'s instead of **'s as
> folded by default?

I am afraid that +++ may actually occur in real Org documents (e.g.
copy-paste from diff files).

Any other ideas? I'd be happy to see some brain-storming.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Russell Adams]

On Tue, Aug 15, 2023 at 03:10:59PM +0100, Timothy wrote:
> They are a syntactic abomination.
>
> If there is any chance of making inlinetasks an extra that is
> outside core Org/the Org spec, I think that would be for the
> best. Having a 15+ level headlines sometimes transform into a
> completely different syntactic element is ... really not nice.

I've never used inline for exactly this reason, 15x*'s seems like
trying to use an overflow to hide data.

Couldn't we use something like headings using ++'s instead of **'s as
folded by default?

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Timothy]

Hi All,

On Sat, Aug 12, 2023, at 1:46 PM, Bastien Guerry wrote:

> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
>> And it is not clear how to fix this. We did not make inlinetasks into
>> standard Org syntax in the past and now it is in the weird state when we
>> have (featurep 'org-inlinetask) sprinkled across the code just to
>> accommodate for this conditional syntax.
>
> Yes, this is ugly.

As I've done the V2 rewrite of org-syntax and written a non-elisp Org parser 
from scratch, I feel like I'm in a decent position to comment on inline tasks.

They are a syntactic abomination.

If there is any chance of making inlinetasks an extra that is outside core 
Org/the Org spec, I think that would be for the best. Having a 15+ level 
headlines sometimes transform into a completely different syntactic element is 
... really not nice.

All the best,
Timothy.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Fraga, Eric]

I'll chime in regarding inlinetasks: I used to use these *a lot* but I
found that drawers do what I needed in almost all cases very
effectively (for my use cases).

I have no strong feelings therefore with respect to either of the
aspects being discussed.
-- 
: Eric S Fraga, with org release_9.6.7-635-gf9e083 in Emacs 30.0.50

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> regexp components docstring in bugfix still say reload or restart.
> biut mayube that is obsolete.

`org-emphasis-regexp-components'? It is no longer a defcustom - you are
not supposed to change it.

> i found possible examples in appt and ediff bot those are not org.  so
> perhaps this is a case where the problem no longer exists?  8if so,
> then never mind that comment about guideline for not requiring setting
> before org where possible.
>
> perhaps these are unavoidable.

> bugfix .el
> g set *.el|g before|g load
> org-fold-core.el:Important: This variable must be set before loading Org."

It is `org-fold-core-style' - must be set before opening file because it
switches between two implementations of folding.
You usually don't need to touch it.

> org-keys.el:Needs to be set before Org is loaded.

`org-mouse-1-follows-link' simply triggers adding/not adding one binding
to `org-mouse-map'. Actually, `org-tab-follows-link' is the same.

These variables are mostly used to avoid forcing users put

(org-defkey org-mouse-map [follow-link] 'mouse-face)
or (org-defkey org-mouse-map (kbd "TAB") #'org-open-at-point)
into their config.

We may alternatively use custom :set function for these variables. That
will not require a restart.

> org-list.el:This variable needs to be set before org.el is loaded.  If you
> org-list.el:This variable needs to be set before org.el is loaded.  If you

`org-plain-list-ordered-item-terminator' and `org-list-allow-alphabetical'
configure Org parser. We should probably remove these variables
eventually. To standardize Org syntax.

> org-persist.el:This variable must be set before loading org-persist library.")

`org-persist--disable-when-emacs-Q' is an internal variable used for debugging.

> org.el:This variable needs to be set before org.el is loaded.  If you

This is `org-export-backends' that literally controls Org loading.
Technically, you don't need to re-load Org here if you set it via
customize interface.

> org.el:This variable needs to be set before org.el is loaded, and you need to

`org-enforce-todo-checkbox-dependencies'. Again, no need to reload Org
if you use customize interface. In both this and previous cases,
docstring explains about customize.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Tom Gillespie]

> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
> > And it is not clear how to fix this. We did not make inlinetasks into
> > standard Org syntax in the past and now it is in the weird state when we
> > have (featurep 'org-inlinetask) sprinkled across the code just to
> > accommodate for this conditional syntax.
>
> Yes, this is ugly.
>
> > Inlinetasks are too similar in syntax with headlines, so it is
> > impossible to make the change backwards-compatible.

Chiming in here to say that inline tasks make it exceptionally annoying
to specify a sane grammar for org because they require putting a special
case in the headline tokenizer, and/or making it possible to toggle the
behavior of the tokenizer.

As such I strongly support removing them from any official status in
the name of simplifying the syntax (among other things).

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

unable to do much of a search atm.  but i recall 3-4 org vars that
used to say so in their docstrings but didn't seem to need to be to me
at the time.  perhaps they have been fixed or i was mistaken.

regexp components docstring in bugfix still say reload or restart.
biut mayube that is obsolete.

i found possible examples in appt and ediff bot those are not org.  so
perhaps this is a case where the problem no longer exists?  8if so,
then never mind that comment about guideline for not requiring setting
before org where possible.

perhaps these are unavoidable.

bugfix .el
g set *.el|g before|g load
org-fold-core.el:Important: This variable must be set before loading Org."
org-keys.el:Needs to be set before Org is loaded.
org-list.el:This variable needs to be set before org.el is loaded.  If you
org-list.el:This variable needs to be set before org.el is loaded.  If you
org-persist.el:This variable must be set before loading org-persist library.")
org.el:This variable needs to be set before org.el is loaded.  If you
org.el:This variable needs to be set before org.el is loaded, and you need to


On 8/13/23, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> 3.
>>
>> istr loading org-id is or was what enables org-ids?  i'd rather have
>> org-id work by default.  OR maybe require activating.
>
> org-id is mostly fine, except that it (1) adds a new link type. (2) adds
> a hook that saves ids before exiting Emacs.
> In general, it is not too different in its design to other link type
> providers. The only difference is better support in other Org core
> libraries, but it only plays when a user customized org-id to take
> preference over other built-in link types - not a problem for users who
> do not use org-id.
>
>> 4.
>>
>> idk if related, but some settings in org must be done before loading.
>> i'd want a guideline in which, where possible, settings can be done
>> after loading.  this is because the user might need to go through
>> contortions in .emacs.  a user can do with-eval-after-load, but
>> with-eval-before-load sounds radically grotesque.
>
> Please, list the settings you have in mind. Some things, like
> configuring Org syntax, must be loaded before Org because we have no
> other way around.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Samuel Wales  writes:

> 3.
>
> istr loading org-id is or was what enables org-ids?  i'd rather have
> org-id work by default.  OR maybe require activating.

org-id is mostly fine, except that it (1) adds a new link type. (2) adds
a hook that saves ids before exiting Emacs.
In general, it is not too different in its design to other link type
providers. The only difference is better support in other Org core
libraries, but it only plays when a user customized org-id to take
preference over other built-in link types - not a problem for users who
do not use org-id.

> 4.
>
> idk if related, but some settings in org must be done before loading.
> i'd want a guideline in which, where possible, settings can be done
> after loading.  this is because the user might need to go through
> contortions in .emacs.  a user can do with-eval-after-load, but
> with-eval-before-load sounds radically grotesque.

Please, list the settings you have in mind. Some things, like
configuring Org syntax, must be loaded before Org because we have no
other way around.

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

[DISCUSSION] The future of org-mouse.el and org-inlinetask.el (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?)

[Ihor Radchenko]

Bastien Guerry  writes:

> Also, I'm not sure org-mouse.el has its place in Org's core nowadays.

org-mouse implements mouse bindings + context menus.
Context menu support is something that major modes generally expect to
provide:

24.2.1 Major Mode Conventions
   • Consider adding mode-specific context menus for the mode, to be
 used if and when users activate the ‘context-menu-mode’ (*note
 (emacs)Menu Mouse Clicks::).  To this end, define a mode-specific
 function which builds one or more menus depending on the location
 of the ‘mouse-3’ click in the buffer, and then add that function to
 the buffer-local value of ‘context-menu-functions’.

And better mouse support is getting more important in a view of recent
native Android port of Emacs, where "mouse" is the main mode of
interaction.

I'd say that we should not remove org-mouse.el, but instead load it by
default. Maybe even fully integrating org-mouse.el into other libraries
like org-keys.el and org.el.

>> It changes the very notion of that is a headline - the syntax definition
>> is altered. Very deeply nested headlines may become inlinetasks upon
>> loading org-inlinetask, touching all aspects of Org, not just editing.
>
> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.

org-inlinetask, if removed, is bound to break unless we maintain
inlinetask support in the core. And it will be a feature regression for
a number of users (for me, at least - I am a big user of inlinetasks
myself).

However, the current way inlinetasks are implemented is definitely not
great. The clash between headings and inlinetask syntax is getting too
much on the way.

May we re-consider inlinetask syntax and come up with an alternative
syntax that does not clash with headings? This will make things a lot
easier to maintain and allow us to gradually deprecate the existing
 syntax.

For example, we can define inlinetasks as

*> TODO inlinetask
***> TODO inlinetask
...

*> TODO inlinetask
Inlinetask contents
*> END

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Samuel Wales]

may i post a few notes?

i've had tehse previously.

1.

i rely on org-mouse for accessibility, as i often cannot use keyboard
at all, so there is a personal stake in having it be part of org so
that it is fully integrated.  of course i have no problem with having
to enable it instead of only load it.

it has /minor/ limbo status in that, for example, you can't set a
specific todo kw with the mouse, but that does not disturb me as much
as code rot.  see below.

2.

i don't use org-inlinetask enough to have a personal stake [in my case
i could make them siblings], but it seemed to me that it was never
sufficiently integrated into org, or had bugs, at least before parsers
became common.

if anybody does have a strong personal stake in them, like i do in 1.,
it might be desirable to make inline tasks, even breakingly, part of
org, merely to make sure that they fully integrate and test, as
opposed to limbo or code rot.

i would apply that principle to org-mouse, which being smallish and
about bindings is probably not too disruptive to be part of org.  i
defer the measurement of the disruptiveness of inline tasks to the
experts/stakeholders.

3.

istr loading org-id is or was what enables org-ids?  i'd rather have
org-id work by default.  OR maybe require activating.

4.

idk if related, but some settings in org must be done before loading.
i'd want a guideline in which, where possible, settings can be done
after loading.  this is because the user might need to go through
contortions in .emacs.  a user can do with-eval-after-load, but
with-eval-before-load sounds radically grotesque.


On 8/12/23, Bastien Guerry  wrote:
> Ihor Radchenko  writes:
>
>> Yes, org-mouse modifies the behavior of certain key bindings. Not
>> directly, but by advising `org-open-at-point'.
>
> IIRC Emacs core libraries should not advise functions.
> This is something we should fix.
>
> Also, I'm not sure org-mouse.el has its place in Org's core nowadays.
>
>> It changes the very notion of that is a headline - the syntax definition
>> is altered. Very deeply nested headlines may become inlinetasks upon
>> loading org-inlinetask, touching all aspects of Org, not just editing.
>
> Same here, I'd be tempted to deny Org citizenship to inline tasks: it
> always felt like a nice hack for a niche use-case, but a hack anyway.
>
> If it modifies Org syntax in surprising ways, this is another argument
> for removing org-inlinetask.el from Org's core.  Remember: this is not
> to say that inline tasks are forbidden, it's just a message for users
> that inline tasks are something not maintained by Org's core team.
>
>> And it is not clear how to fix this. We did not make inlinetasks into
>> standard Org syntax in the past and now it is in the weird state when we
>> have (featurep 'org-inlinetask) sprinkled across the code just to
>> accommodate for this conditional syntax.
>
> Yes, this is ugly.
>
>> Inlinetasks are too similar in syntax with headlines, so it is
>> impossible to make the change backwards-compatible.
>>
 With the current state of affairs, it is often enough to
 (require 'org-library) to get things work. If we get rid of all the
 possible side effects, users will have to adapt their configurations
 and we will thus violate "I won't force you to update your
 configuration."
>>>
>>> Defining new functions is a desirable "side-effect" of all Elisp
>>> library, I don't think we should worry abou this.
>>
>> Defining new functions by itself is not a big deal. But there are parts
>> of Org that alter their behavior depending on whether a feature is
>> loaded (like org-inlinetask) or depending whether certain function
>> symbol is defined (babel). Similarly, loading new link types re-defines
>> Org syntax in all the documents, affecting editing of everything that
>> looks like the loaded link type (org-ctags).
>
> I feel like the stakes are not the same for features like org-mouse.el
> and org-inlinetask.el and for core features like Babel libs and links.
> For the former, a decision should be made relatively to the usefulness
> of the feature; for the latter, loading libs (with side-effects on the
> syntax) is required by the design of the core feature at hand (Babel
> and links).
>
> I'd focus on solving the problem with org-mouse and org-inlinetasks
> first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ?
>
> --
>  Bastien Guerry
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> Yes, org-mouse modifies the behavior of certain key bindings. Not
> directly, but by advising `org-open-at-point'.

IIRC Emacs core libraries should not advise functions.
This is something we should fix.

Also, I'm not sure org-mouse.el has its place in Org's core nowadays.

> It changes the very notion of that is a headline - the syntax definition
> is altered. Very deeply nested headlines may become inlinetasks upon
> loading org-inlinetask, touching all aspects of Org, not just editing.

Same here, I'd be tempted to deny Org citizenship to inline tasks: it
always felt like a nice hack for a niche use-case, but a hack anyway.

If it modifies Org syntax in surprising ways, this is another argument
for removing org-inlinetask.el from Org's core.  Remember: this is not
to say that inline tasks are forbidden, it's just a message for users
that inline tasks are something not maintained by Org's core team.

> And it is not clear how to fix this. We did not make inlinetasks into
> standard Org syntax in the past and now it is in the weird state when we
> have (featurep 'org-inlinetask) sprinkled across the code just to
> accommodate for this conditional syntax.

Yes, this is ugly.

> Inlinetasks are too similar in syntax with headlines, so it is
> impossible to make the change backwards-compatible.
>
>>> With the current state of affairs, it is often enough to
>>> (require 'org-library) to get things work. If we get rid of all the
>>> possible side effects, users will have to adapt their configurations
>>> and we will thus violate "I won't force you to update your
>>> configuration."
>>
>> Defining new functions is a desirable "side-effect" of all Elisp
>> library, I don't think we should worry abou this.
>
> Defining new functions by itself is not a big deal. But there are parts
> of Org that alter their behavior depending on whether a feature is
> loaded (like org-inlinetask) or depending whether certain function
> symbol is defined (babel). Similarly, loading new link types re-defines
> Org syntax in all the documents, affecting editing of everything that
> looks like the loaded link type (org-ctags).

I feel like the stakes are not the same for features like org-mouse.el
and org-inlinetask.el and for core features like Babel libs and links.
For the former, a decision should be made relatively to the usefulness
of the feature; for the latter, loading libs (with side-effects on the
syntax) is required by the design of the core feature at hand (Babel
and links).

I'd focus on solving the problem with org-mouse and org-inlinetasks
first. Let's make a poll for org-mouse.el then for org-inlinetasks.el ?

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

>> Finally, we have org-mouse.el discussed here, which modifies key
>> bindings and org-inlinetask.el, which modifies how Org treats headlines
>> in Org files, modifying syntax.
>
> org-mouse.el should not modify default Org _editing_ key bindings.
> Is it really the case?  If so, can we fix this?

Yes, org-mouse modifies the behavior of certain key bindings. Not
directly, but by advising `org-open-at-point'.
Also, org-mouse adds new key bindings, potentially overriding custom
user bindings for mouse keys.

> Does org-inlinetask.el modifies the way non-inline headlines are
> edited?
> ... If so, can we fix this?  IIRC org-inlinetask.el only adds
> editing function for inline tasks, it is an extension, not a
> modification of the default Org editing behavior, but the limit
> can be thin here.

It changes the very notion of that is a headline - the syntax definition
is altered. Very deeply nested headlines may become inlinetasks upon
loading org-inlinetask, touching all aspects of Org, not just editing.

And it is not clear how to fix this. We did not make inlinetasks into
standard Org syntax in the past and now it is in the weird state when we
have (featurep 'org-inlinetask) sprinkled across the code just to
accommodate for this conditional syntax.

Inlinetasks are too similar in syntax with headlines, so it is
impossible to make the change backwards-compatible.

>> With the current state of affairs, it is often enough to
>> (require 'org-library) to get things work. If we get rid of all the
>> possible side effects, users will have to adapt their configurations
>> and we will thus violate "I won't force you to update your
>> configuration."
>
> Defining new functions is a desirable "side-effect" of all Elisp
> library, I don't think we should worry abou this.

Defining new functions by itself is not a big deal. But there are parts
of Org that alter their behavior depending on whether a feature is
loaded (like org-inlinetask) or depending whether certain function
symbol is defined (babel). Similarly, loading new link types re-defines
Org syntax in all the documents, affecting editing of everything that
looks like the loaded link type (org-ctags).

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Nick Dokos  writes:

> I would also recommend that the library *not* call its enable function
> in general and leave it to the user to do so explicitly, but that may
> be more controversial for "backward compatibility" reasons (with which
> I disagree in these particular cases: I view them as bugs that need to
> be fixed).

I think that we all agree on this point.
The main question is where to draw a line between intrusive and
non-intrusive side effects.

For example, before loading ob-emacs-lisp

#+begin_src elisp
 (+ 1 1)
#+end_src

will not be syntax-highlighted, while after loading it will.
Is it intrusive? Somewhat. But maybe not bad enough to justify enable
function.

Similarly, loading ob-lilypond will alter how file containing lilypond
fragments is tangled.

Or loading ox-foo.el may alter export menu.

We have plenty of examples with varying degrees of side effects in Org.
And it is not fully clear to me which side effects are worth eliminating
and which are not.

Yet another option could be forcing certain side effects even without
loading. For example,
  (add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))
that sets up tangling of lilypond fragments can be changed to

;;;#autoload
(add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))

That way, we will consistently get the same tangle configuration even
before ob-lilypond is loaded.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Nick Dokos]

Max Nikulin  writes:

> On 08/08/2023 20:29, Bastien Guerry wrote:
>> The definition of a new function is not a side-effect
>> that affects Emacs editing behavior, so Babel and export libs are
>> OK.
>
> Function definition is not side effect when load library is
> requested. However it is a side effect of hitting TAB in Emacs help
> prompt. Completion of a variable or a function should not modify Org
> behavior. Loading of a file is not explicitly requested by the user in
> this case.
>
> I would disregard however function definitions, however changes in key
> bindings and recognized plain text links may be surprising to users
> who just tries to read help.
>
>

A big +1 from me: that's exactly what I was trying to say a few months
ago wrt org-ctags, although I said it badly. Defining functions that
are not used is not much of a problem IMO, but changing behavior behind
the user's back is most definitely a problem. IOW, it's not about
side-effects in general, it's about *specific kinds* of side-effects:
ones that are immediately visible (and confusing) to the user - things
behaving differently from a minute ago even though the only thing the
user did in-between is something as innocuous as asking for help.

One small step forward is to require libraries to have explicit
enable/disable functions[fn:1].  Even if I somehow enable a library by
mistake or misadventure, I should be able to disable it (at least in
the sense described above) without having to restart. Not every
library will need that and it's not even close to a complete solution,
but there is at least the possibility of building something better
(though more complicated) on top of it. If the library could be
organized as a minor mode, it most definitely should be so organized:
enabling/disabling would then be an automatic "requirement satisfied".

I would also recommend that the library *not* call its enable function
in general and leave it to the user to do so explicitly, but that may
be more controversial for "backward compatibility" reasons (with which
I disagree in these particular cases: I view them as bugs that need to
be fixed). And the library should document what changes it unleashes
on the environment (again in the restricted sense discussed above):
changes to "foreign" keymaps/menus/syntax tables/hooks probably
qualify for this kind of documentation, function definitions and
internal-to-the-library changes do not, plus there is probably a swath
of stuff in-between with more ambiguous requirements - all I can say
is start with the obvious things and add as necessary.

[fn:1] E.g. `org-ctags' has `org-ctags-enable' but no `org-ctags-disable', so
my "solution" is to do something like this in my init file:

;;; undo org-ctags obnoxiousness
(with-eval-after-load 'org-ctags (setq org-open-link-functions nil))

It doesn't undo everything but it gets the obnoxious bits out of my
way (at least until *I* decide to call `org-ctags-enable').

My 2-cents/pence/centimes...
-- 
Nick

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

On 08/08/2023 20:29, Bastien Guerry wrote:

The definition of a new function is not a side-effect
that affects Emacs editing behavior, so Babel and export libs are
OK.


Function definition is not side effect when load library is requested. 
However it is a side effect of hitting TAB in Emacs help prompt. 
Completion of a variable or a function should not modify Org behavior. 
Loading of a file is not explicitly requested by the user in this case.


I would disregard however function definitions, however changes in key 
bindings and recognized plain text links may be surprising to users who 
just tries to read help.

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Thanks a lot for the detailed clarification.

The Elisp coding convention explicitely targets Emacs "editing
behavior".  The definition of a new function is not a side-effect 
that affects Emacs editing behavior, so Babel and export libs are
OK.

Ihor Radchenko  writes:

> Finally, we have org-mouse.el discussed here, which modifies key
> bindings and org-inlinetask.el, which modifies how Org treats headlines
> in Org files, modifying syntax.

org-mouse.el should not modify default Org _editing_ key bindings.
Is it really the case?  If so, can we fix this?

Does org-inlinetask.el modifies the way non-inline headlines are
edited?  If so, can we fix this?  IIRC org-inlinetask.el only adds
editing function for inline tasks, it is an extension, not a
modification of the default Org editing behavior, but the limit
can be thin here.

> With the current state of affairs, it is often enough to
> (require 'org-library) to get things work. If we get rid of all the
> possible side effects, users will have to adapt their configurations
> and we will thus violate "I won't force you to update your
> configuration."
>
> Of course, we can change babel implementation to use explicit registry
> like for export backends and force users to call explicit activation
> commands in addition to (require 'library). But I am not sure if we are
> not crossing the line with such an approach: "I won't use software
> correctness as an excuse.".

Defining new functions is a desirable "side-effect" of all Elisp
library, I don't think we should worry abou this.

-- 
 Bastien Guerry

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Bastien Guerry  writes:

>> This is convincing.
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding
> convention first.  When the breaking change is a side-effect of fixing
> a bug, it is unavoidable.

The situation is a bit more complex.
Strictly speaking, loading Elisp library _always_ has side effects of
defining new functions. And, for example, Org babel's behavior is
modified when ob-foo.el is loaded because `fboundp' on
'org-babel-execute:foo returns non-nil.

A bit different approach is used for ol-foo.el, where more significant
side effect is triggered by top-level calls to
`org-link-set-parameters'. Similarly, ox-foo.el uses
`org-export-define-derived-backend' or `org-export-define-backend'.

Finally, we have org-mouse.el discussed here, which modifies key
bindings and org-inlinetask.el, which modifies how Org treats headlines
in Org files, modifying syntax.

With the current state of affairs, it is often enough to
(require 'org-library) to get things work. If we get rid of all the
possible side effects, users will have to adapt their configurations
and we will thus violate "I won't force you to update your
configuration."

Of course, we can change babel implementation to use explicit registry
like for export backends and force users to call explicit activation
commands in addition to (require 'library). But I am not sure if we are
not crossing the line with such an approach: "I won't use software
correctness as an excuse.".

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Bastien Guerry]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>>> including built-in Emacs libraries are loaded with side effects.
>>
>> It is still violation of conventions:
>>
>> (info "(elisp) Coding Conventions")
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>>> D.1 Emacs Lisp Coding Conventions
>>> 
>>> Simply loading a package should not change Emacs’s editing behavior.
>>> Include a command or commands to enable and disable the feature, or to
>>> invoke it.
>>> 
>>> This convention is mandatory for any file that includes custom
>>> definitions. If fixing such a file to follow this convention requires an
>>> incompatible change, go ahead and make the incompatible change; don’t
>>> postpone it.
>
> This is convincing.
> I am then CCing Bastien, as, despite the Elisp convention, following it
> will break https://bzg.fr/en/the-software-maintainers-pledge/

FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding
convention first.  When the breaking change is a side-effect of fixing
a bug, it is unavoidable.

-- 
 Bastien

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Ihor Radchenko]

Max Nikulin  writes:

> On 26/03/2023 00:45, Ihor Radchenko wrote:
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> I hope, it may be mitigated to some degree, e.g. loading of 
> `org-modules' and `org-babel-load-languages' may include their 
> activation. Perhaps `org-require-package' should activate the loaded 
> package as well.

We often promise in the manual that simple `require' is sufficient.
Not everybody is using `org-modules' mechanism.

Also, `org-require-package' is unrelated. It is specifically designed to
handle third-party packages where we have no control about side effects.

> If it is possible to avoid user prompt in org-ctags then migration may 
> be done in 2 steps separated by a year: add new require helper and do 
> not activate by default. Unsure if it is possible to add some warnings 
> on first step that activate function is not called.

There is no point discussing how to introduce the breaking change.
Making the transition longer will not make it non-breaking.
We first need to decide if we want to go ahead at all.

>> (defun enable-feature (feature  filename noerror)
>>"Load and enable FEATURE.
>> FILENAME and NOERROR arguments are the same as in `require'."
>>(when (require feature filename noerror)
>>  (let ((enabler-cmd (intern (format "%s-enable-function" feature
>>(and (fboundp enabler-cmd) (funcall enabler-cmd)
>
> I would prefer activating on first call only, subsequent calls should be 
> no op.

Sure. I just wanted to point out that it is an easy part to implement
such functionality.

>> (defun disable-feature (feature)
>
> I had a hope that existing `unload-feature' is enough.

`unload-feature' serves different purpose, no?
I am not sure if mixing the two will be welcome by Emacs devs, if we
really want to pursue inclusion this into Emacs.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

>> This is convincing.
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> Isn’t the problem that the behavior changed — so that org-ctags gets
> loaded in Emacs 30 but not in Emacs 28 is already an incompatible
> change?

It is a secondary problem.
In earlier Emacs you would get the same side effects if, for example,
you try C-h f org-ctags- .
`help-enable-autoload' is there since Emacs 24.

The root cause of this and similar reported issues (like with org-mouse,
see https://orgmode.org/list/87iliie0j1.fsf@localhost) is optional Org
modules having side effects when loaded.

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

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>>> including built-in Emacs libraries are loaded with side effects.
>>
>> It is still violation of conventions:
>>
>> (info "(elisp) Coding Conventions")
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>>> D.1 Emacs Lisp Coding Conventions
>>> 
>>> Simply loading a package should not change Emacs’s editing behavior.
>>> Include a command or commands to enable and disable the feature, or to
>>> invoke it.
>>> 
>>> This convention is mandatory for any file that includes custom
>>> definitions. If fixing such a file to follow this convention requires an
>>> incompatible change, go ahead and make the incompatible change; don’t
>>> postpone it.
>
> This is convincing.
> I am then CCing Bastien, as, despite the Elisp convention, following it
> will break https://bzg.fr/en/the-software-maintainers-pledge/

Isn’t the problem that the behavior changed — so that org-ctags gets
loaded in Emacs 30 but not in Emacs 28 is already an incompatible
change?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

On 26/03/2023 00:45, Ihor Radchenko wrote:

I am then CCing Bastien, as, despite the Elisp convention, following it
will break https://bzg.fr/en/the-software-maintainers-pledge/


I hope, it may be mitigated to some degree, e.g. loading of 
`org-modules' and `org-babel-load-languages' may include their 
activation. Perhaps `org-require-package' should activate the loaded 
package as well.


If it is possible to avoid user prompt in org-ctags then migration may 
be done in 2 steps separated by a year: add new require helper and do 
not activate by default. Unsure if it is possible to add some warnings 
on first step that activate function is not called.



(defun enable-feature (feature  filename noerror)
   "Load and enable FEATURE.
FILENAME and NOERROR arguments are the same as in `require'."
   (when (require feature filename noerror)
 (let ((enabler-cmd (intern (format "%s-enable-function" feature
   (and (fboundp enabler-cmd) (funcall enabler-cmd)


I would prefer activating on first call only, subsequent calls should be 
no op.



(defun disable-feature (feature)


I had a hope that existing `unload-feature' is enough.

My idea was something like `org-require' that is (require feature) and 
(feature-activate) or (feature-activate-function) *once*.

[POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab)

[Ihor Radchenko]

Max Nikulin  writes:

>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>> including built-in Emacs libraries are loaded with side effects.
>
> It is still violation of conventions:
>
> (info "(elisp) Coding Conventions")
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>> D.1 Emacs Lisp Coding Conventions
>> 
>> Simply loading a package should not change Emacs’s editing behavior.
>> Include a command or commands to enable and disable the feature, or to
>> invoke it.
>> 
>> This convention is mandatory for any file that includes custom
>> definitions. If fixing such a file to follow this convention requires an
>> incompatible change, go ahead and make the incompatible change; don’t
>> postpone it.

This is convincing.
I am then CCing Bastien, as, despite the Elisp convention, following it
will break https://bzg.fr/en/the-software-maintainers-pledge/

>> Note that we discussed loading side effects in
>> https://list.orgmode.org/orgmode/tn4ql0$bu2$1...@ciao.gmane.io/
>
> I have not responded to that thread. My opinion is that besides 
> functions that just loads files and packages there should be 
> counterparts that loads and activates libraries. A proof of concept may 
> be implemented for Org and in the case of success it may be proposed for 
> inclusion into Emacs core.

Maybe. We can do something similar to `unload-feature'. However, it will
still require users to adapt.

Tentative implementation:

(defun enable-feature (feature  filename noerror)
  "Load and enable FEATURE.
FILENAME and NOERROR arguments are the same as in `require'."
  (when (require feature filename noerror)
(let ((enabler-cmd (intern (format "%s-enable-function" feature
  (and (fboundp enabler-cmd) (funcall enabler-cmd)

(defun disable-feature (feature)
  "Disable FEATURE."
  (let ((disabler-cmd (intern (format "%s-disable-function" feature
(and (fboundp disabler-cmd) (funcall disabler-cmd

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