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

[Russell Adams <RLAdams@adamsinfoserv.com>]

On Thu, Aug 24, 2023 at 01:41:39PM +0000, Ihor Radchenko wrote:
> Russell Adams <RLAdams@adamsinfoserv.com> 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 Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/