[DISCUSSION] Re-design of inlinetasks

[DISCUSSION] Re-design of inlinetasks

[Maske]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Hi

I am sorry, I don't know the appropriate terminology.


Could be used

*************** END

or a different special string, to end any headline scope? Like an "end 
parenthesis" for the headline just above it.

Maybe in this way, all headlines would be the same: if the special 
string appears, the headline scope ends there (inlinetask). If no 
special string, the scope would end before the next headline (or at the 
end of the document).





[-- Attachment #2: Type: text/html, Size: 869 bytes --]

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Maske <maske1foro@gmail.com> writes:

> I am sorry, I don't know the appropriate terminology.
>
>
> Could be used
>
> *************** END

> or a different special string, to end any headline scope? Like an "end 
> parenthesis" for the headline just above it.
> ...
> Maybe in this way, all headlines would be the same: if the special 
> string appears, the headline scope ends there (inlinetask). If no 
> special string, the scope would end before the next headline (or at the 
> end of the document).

This is what we already do. Inlinetasks have two forms:

*********************** Single-line inlinetask

or

*********************** Multi-line inlinetask
With some contents inside
*********************** END

There are 3 problems with this, however:

1. Because inlinetasks are currently optional, a number of people rely
   on ******************* being __always__ a heading. So, we are unable
   to integrate inlinetasks into Org syntax properly.

2. The syntax clash is hard to maintain in the code, leading to subtle
   bugs that are hard to notice and fix.

3. We require no less than 15 stars to define inlinetask, which looks
   ugly.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Ihor Radchenko writes on Sun  3 Sep 2023 07:58:

 > 3. We require no less than 15 stars to define inlinetask, which
 >    looks ugly.

With org-indent-mode, only 2 stars are shown (which I don't find
ugly).  Hence an idea: how about an additional
org-indent-mode-just-for-inlinetasks?, for those who want to keep the
default indentation for regular headlines.

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Alain.Cochard@unistra.fr writes:

> Ihor Radchenko writes on Sun  3 Sep 2023 07:58:
>
>  > 3. We require no less than 15 stars to define inlinetask, which
>  >    looks ugly.
>
> With org-indent-mode, only 2 stars are shown (which I don't find
> ugly).  Hence an idea: how about an additional
> org-indent-mode-just-for-inlinetasks?, for those who want to keep the
> default indentation for regular headlines.

We also do not want things to look ugly in plain text (Org mode is plain
text markup at the end). That's why I listed this point.

But maintainability and compatibility reasons are much more important
practically.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Hi, Adams


In an org block:

- You can't use directly the org-mode keybinding.

- Visually, by default, it is different from the other headlines.

- When exporting, by default, it doesn't seem appropriate for reading.

- When inserting, by default, it is not as easy as inlinetasks are.


I will share a use example I proposed in gptel issues forum.  It seemed 
to me useful for inserting a chatgpt response with Properties, in the 
middle of the text:

https://github.com/karthink/gptel/issues/103#issuecomment-1685196575

*************** OpenAI. (2023). /ChatGPT: I apologize for any confusion/ 
(Ago 20 version). In Conquest of Egypt
:PROPERTIES:
:GPTEL_MODEL: gpt-3.5-turbo
:GPTEL_TOPIC: Conquest of Egypt
:GPTEL_SYSTEM: I want you to act as a historian. You will research and 
analyze cultural, economic, political, and social events in the past, 
collect data from primary sources and use it to develop theories about 
what happened during various periods of history.
:END:
I apologize for any confusion, ...
*************** END


Best regards

[-- Attachment #2: Type: text/html, Size: 2228 bytes --]

org-ctags land grab

[Nick Dokos]

`org-ctags' unilaterally sets the hook `org-open-link-functions' to a
bunch of org-ctags functions and enables itself by default. That has
the unfortunate consequence of invalidating the documentation for
internal CUSTOM_ID links - see

https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode

It is also confusing. To quote the unfortunate victim:

  Now, when I click on the link, or C-c C-o, I get a dialog to "visit
  tags table"... ???

I proposed a work-around, but it seems to me that `org-ctags'
functionality should be opt-in and there should be a way to turn it
off. In addition, it needs a better way to interpolate itself into the
link ecosystem: breaking internal link functionality is rather
obnoxious IMO.

WDYT?

-- 
Nick

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

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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 <yantar92@posteo.net> 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 <bzg@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> 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?

[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 <bzg@gnu.org> wrote:
> Ihor Radchenko <yantar92@posteo.net> 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?

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

[Bastien Guerry]

"Fraga, Eric" <e.fraga@ucl.ac.uk> 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]

Bastien Guerry <bzg@gnu.org> writes:

> "Fraga, Eric" <e.fraga@ucl.ac.uk> 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
<paragraph 1>

<paragraph 2>

<...>

************************* TODO Consider explaining more about X
<paragraph N>

<...>

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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> 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
> <paragraph 1>
>
> <paragraph 2>
>
> <...>
>
> ************************* TODO Consider explaining more about X
> <paragraph N>
>
> <...>
>
> 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 <paragraph N> 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 <bzg@gnu.org> writes:

>> ************************* TODO Consider explaining more about X
>> <paragraph N>
>>
>> <...>
>>
>> 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 <paragraph N> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> 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 <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> 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

<paragraph 1>

<paragraph 2>
<...>
<paragraph N>
<...>
<multiple sreens of text>
<...>

*** TODO Task for paragraph N

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

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

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

And what about this?

   ** Section X
   
   <paragraph 1>
   
   <paragraph 2>
   <...>
   
   *** TODO Task for paragraph N
   
   <paragraph N>
   <...>
   <multiple sreens of text>
   <...>
   
-- 
 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 <bzg@gnu.org> writes:

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

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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> 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 <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> 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?

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> 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

[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 <bzg@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

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

I think inlinetasks may also have a use for those sections that are not
"nested". In typography they are usually called "anonymous sections" and
they are separated by some symbol (asterisks, dinkus[1], etc.). They
behave like a true section, except that they are not headed by titles or
level numbers. I think Org's support for these types of sections would
be useful and novel, since there is (as far as I know) nothing similar
in other lightweight markup languages. Anonymous sections can be useful
not only in print or PDF texts but also on web pages.

https://en.wikipedia.org/wiki/Dinkus

Best regards,

Juan Manuel 

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I think inlinetasks may also have a use for those sections that are not
> "nested". In typography they are usually called "anonymous sections" and
> they are separated by some symbol (asterisks, dinkus[1], etc.).

This is a very interesting idea. Thanks for sharing!

> ... They
> behave like a true section, except that they are not headed by titles or
> level numbers.

May they contain sub-sections?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

>> ... They
>> behave like a true section, except that they are not headed by titles or
>> level numbers.
>
> May they contain sub-sections?

I think that would not be expected, since an anonymous section is just a
break in the text that has neither a title nor a section number. There
are many possible scenarios. Let's imagine, for example, that an author
is working on a section of an article. And at the end of various
subsections he/she wants to make some text breaks that, for whatever
reason, don't deserve either a title or a subsubsection number.
Anonymous breaks using asterisks or other symbols is usually the applied
remedy. The advantage of enclosing the content of the anonymous section
in an inlinetask is that we have a 'true' section with content (over
which you have control). That would not happen if the author explicitly
added a break symbol and continue writing.

Anonymous breaks are also widely used in essay or narrative texts. An
essay text, published as a blog entry or as an article, can be perfectly
structured into anonymous sections:

contents 1

***

contents 2

***

etc

See:

https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering

https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks


-- 
Juan Manuel Macías

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>>
>> May they contain sub-sections?
>
> I think that would not be expected, since an anonymous section is just a
> break in the text that has neither a title nor a section number.
> ... Anonymous breaks using asterisks or other symbols is usually the applied
> remedy. The advantage of enclosing the content of the anonymous section
> in an inlinetask is that we have a 'true' section with content (over
> which you have control). That would not happen if the author explicitly
> added a break symbol and continue writing.

Do you mean section in LaTeX sense or in Org sense?

> Anonymous breaks are also widely used in essay or narrative texts. An
> essay text, published as a blog entry or as an article, can be perfectly
> structured into anonymous sections:
> ...
> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>
> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks

This one I know. But it can work fine with normal headings, because such
texts are nothing but a sequence of "scenes" - nothing "inline" when we
have one scene, interrupted by other, then coming back to the first one.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:

>> I think that would not be expected, since an anonymous section is just a
>> break in the text that has neither a title nor a section number.
>> ... Anonymous breaks using asterisks or other symbols is usually the applied
>> remedy. The advantage of enclosing the content of the anonymous section
>> in an inlinetask is that we have a 'true' section with content (over
>> which you have control). That would not happen if the author explicitly
>> added a break symbol and continue writing.
>
> Do you mean section in LaTeX sense or in Org sense?

In Org sense, I think. If an author adds an 'anonymous' break (through
some customary symbol) and continues writing, the content that follows
belongs (for Org) to the current section. By using an inlenitask, you
can have control over the inlinetask content, for any purpose, for
example with some export filter, etc.

On the other hand, for my own writing I usually use this:

#+begin_src emacs-lisp
  (defun my-org-latex-format-inlinetask-default-function
      (todo _todo-type priority title tags contents _info)
    (if (string-match-p "anonsec" title)
	(concat
	 "\n\\begin{anonsection}\n"
	 (org-string-nw-p contents)
	 "\n\\end{anonsection}\n")
      (org-string-nw-p contents)))

(defun mi-org-odt-format-inlinetask-default-function
    (todo todo-type  priority name tags contents)
  (if (string-match-p "anonsec" name)
      (concat
       contents
       "<text:p text:style-name=\"OrgCenter\">* * *</text:p>")))
#+end_src

And for LaTeX I have defined this:

#+begin_src latex
\newcommand\dinkus{\mbox{\textasteriskcentered\space\textasteriskcentered\space\textasteriskcentered}}
\newcommand\anonsectionmark{\dinkus}

%% require the needspace package
\newcommand\anonsectionbreak{%
  \nopagebreak[4]
  \bigskip%
  {\centering
  \anonsectionmark\par}
  \Needspace*{2\bigskipamount}
  \bigskip}

\newenvironment{anonsection}{%
\anonsectionbreak%
}
{%
\par}
#+end_src


>> Anonymous breaks are also widely used in essay or narrative texts. An
>> essay text, published as a blog entry or as an article, can be perfectly
>> structured into anonymous sections:
>> ...
>> https://en.wikipedia.org/wiki/Section_(typography)#Section_form_and_numbering
>>
>> https://en.wikipedia.org/wiki/Section_(typography)#Flourished_section_breaks
>
> This one I know. But it can work fine with normal headings, because such
> texts are nothing but a sequence of "scenes" - nothing "inline" when we
> have one scene, interrupted by other, then coming back to the first one.

Actually, I think any anonymous text break or sectioning can be
accomplished using Org headings and some trickery to ignore the heading on
export, but I think inlinetasks lends itself quite well to this
constructions and others I've seen discussed in this thread. In general,
for any 'piece' (section = something that is sectioned) of text that
needs to be separated in some way from the main text, without a
hierarchy of levels, inlinetasks are a great, versatile and simple tool
(IMHO).

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> Do you mean section in LaTeX sense or in Org sense?
>
> In Org sense, I think. If an author adds an 'anonymous' break (through
> some customary symbol) and continues writing, the content that follows
> belongs (for Org) to the current section. By using an inlenitask, you
> can have control over the inlinetask content, for any purpose, for
> example with some export filter, etc.
>
> On the other hand, for my own writing I usually use this:
>
> #+begin_src emacs-lisp
>   (defun my-org-latex-format-inlinetask-default-function
>       (todo _todo-type priority title tags contents _info)
>     (if (string-match-p "anonsec" title)
> 	(concat
> 	 "\n\\begin{anonsection}\n"
> 	 (org-string-nw-p contents)
> 	 "\n\\end{anonsection}\n")
>       (org-string-nw-p contents)))

Why not simply

#+begin_anonsection
...
#+end_anonsection

?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Why not simply
>
> #+begin_anonsection
> ...
> #+end_anonsection
>
> ?

Because with an inlinetask I can have something like this:

*************** TODO anonsec :tag:
                Content that has neither a title nor a section number.
*************** END

and a construction that for the purposes of parceling out the text
behaves like a section. The problem is the LaTeX side. Since there is no
support for anonymous sections in LaTeX (I seem to remember that some
special class like Koma had some command to introduce anonymous breaks,
but I only use the standard classes), I had to define an environment. It
is not inconvenient, since after all what appears in LaTeX is the
typographical result. For the Org side I can use TODO keywords, tags,
deadlines, etc.


-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> Why not simply
>>
>> #+begin_anonsection
>> ...
>> #+end_anonsection
>>
>> ?
> ... The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.

In other words, it is not the section itself, but other
headline/inlinetask features, like todo keywords, tags, planning. Right?

Custom blocks can be exported to anything (not necessarily
\begin{foo}...), similar to how you did custom export for inlinetasks.
There was also an idea to make custom block export more customizeable,
similar to link. Like what
https://github.com/alhassy/org-special-block-extras does.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> In other words, it is not the section itself, but other
> headline/inlinetask features, like todo keywords, tags, planning. Right?

No, it is the section itself (or the concept of "section", with its toys
in Org, of course) that is important to me in this case. I am not
emphasizing so much how or in which way an element can be exported, but
what (semantic) role that element plays in the logical structure of an
Org document. To get a little philosophical, the Org document (where I
work and write) would be the idea, and the export to any format a
possible concrete realization. I mean, I find it comfortable and
productive to view an Org document as agnostic of any format. This use
of inlinetasks that I'm discussing here occurred to me a long time ago
because if I stop to think about an untitled, detached section of the
level hierarchy, this Org element is a perfect candidate. It is true
that you can use a special block, or another element (org is very
versatile, and supports role swapping between elements), but if I have
to think of a logical candidate, inlinetasks are the closest to that
concept. If inlinetasks didn't exist, I'd probably use special blocks
for that purpose. When I'm writing inside Org I'm not thinking about the
export (at least not simultaneously), that is, about the format; I think
more of the structure of the document, as something abstract.


-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com
 

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Ihor Radchenko writes:
>
>> In other words, it is not the section itself, but other
>> headline/inlinetask features, like todo keywords, tags, planning. Right?
>
> No, it is the section itself (or the concept of "section", with its toys
> in Org, of course) that is important to me in this case...

So, this is a vote in favour of having a separate syntax element.
Although, the name "inlinetask" is actually awkward in such use case.
Something like inlinesection would fit better. Or inlineheading.

And what about drawers? Don't they fit the idea of "detached" element?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Although, the name "inlinetask" is actually awkward in such use case.
> Something like inlinesection would fit better. Or inlineheading.

Completely agree. I like inlinesection and inlineheading equally.

> And what about drawers? Don't they fit the idea of "detached" element?

But drawers would not serve as a "detached section"... Although they are
certainly very versatile. I usually use drawers to export as small
"containers". And when I don't export them, they are very useful for
temporarily saving all kinds of "things". In Spanish we have the term
"cajón de sastre" (lit.: "a tailor drawer") to refer to something where
you can store everything :-)

As for the inlinetask (or whatever they may be called in the future),
the fact that they are a kind of hybrid between a section (unrelated to
the level hierarchy) and a drawer seems very interesting to me. Apart
from the scenario of the anonymous sections that I mentioned before, I
can think of a few more. For example, something like this:

*************** WORKING Complete this :noexport:
		DEADLINE: <2023-08-27 dom>
                Content 
*************** END

And the combination of org-store-link with org-transclusion can also be
interesting.

Or, for example this other example, which is not possible now, but with
some modification in org-mime-org-subtree-htmlize I think it is:

*************** TODO Email this 
		DEADLINE: <2023-08-27 dom>
		:PROPERTIES:
		:mail_to:  mail address
		:mail_subject: mail subject
		:END:
                Content
*************** END

Well, it's some scattered ideas. In general I think that "inlinesection/-heading"
is an element that could be very productive in certain cases, since it
allows to "locally" suspend the (necessary) rigidity of the tree hierarchy.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> And what about drawers? Don't they fit the idea of "detached" element?
>
> But drawers would not serve as a "detached section"... Although they are
> certainly very versatile. I usually use drawers to export as small
> "containers". And when I don't export them, they are very useful for
> temporarily saving all kinds of "things". In Spanish we have the term
> "cajón de sastre" (lit.: "a tailor drawer") to refer to something where
> you can store everything :-)

I am not sure here. It looks like having a new special block type

#+begin_inlinesection
...
#+end_inlinesection

would be sufficient. Given that we cannot nest inlinesections anyway.

Or special drawer
:inlinesection:
...
:end:

Although, drawers will be less powerful because, unlike special blocks,
you cannot have a different drawer type inside. For special blocks, a
different special block is perfectly fine.

I do not see any clear benefit of having a dedicated, separate markup
for inlinesection, apart from philosophical.

> As for the inlinetask (or whatever they may be called in the future),
> the fact that they are a kind of hybrid between a section (unrelated to
> the level hierarchy) and a drawer seems very interesting to me. Apart
> from the scenario of the anonymous sections that I mentioned before, I
> can think of a few more. For example, something like this:
>
> *************** WORKING Complete this :noexport:
> 		DEADLINE: <2023-08-27 dom>
>                 Content 
> *************** END
>
> And the combination of org-store-link with org-transclusion can also be
> interesting.
>
> Or, for example this other example, which is not possible now, but with
> some modification in org-mime-org-subtree-htmlize I think it is:
>
> *************** TODO Email this 
> 		DEADLINE: <2023-08-27 dom>
> 		:PROPERTIES:
> 		:mail_to:  mail address
> 		:mail_subject: mail subject
> 		:END:
>                 Content
> *************** END

We can get the same functionality if we allow arbitrary properties and
tags assigned to non-headline elements.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Sat, Aug 26, 2023 at 05:31:46PM +0000, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>
> *************** TODO anonsec :tag:
>                 Content that has neither a title nor a section number.
> *************** END
>
> and a construction that for the purposes of parceling out the text
> behaves like a section. The problem is the LaTeX side. Since there is no
> support for anonymous sections in LaTeX (I seem to remember that some
> special class like Koma had some command to introduce anonymous breaks,
> but I only use the standard classes), I had to define an environment. It
> is not inconvenient, since after all what appears in LaTeX is the
> typographical result. For the Org side I can use TODO keywords, tags,
> deadlines, etc.

Why not just put the TODO heading in a code block with type org?

Then you get all the toys, ignored by the main file.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
> Why not just put the TODO heading in a code block with type org?
>
> Then you get all the toys, ignored by the main file.

If inline tasks are supposed to be Org enabled headings, but NOT
treated like headings in the current file, why not put them in a src block?

Doesn't this allow the same functionality without any new syntax
elements, or silly long *'s?

======================================================================

* Things

** TODO stuff

[2023-08-07 Mon 20:06]

#+begin_src org
  ,*** DONE This is not a heading
  CLOSED: [2023-08-29 Tue 14:57]

  stuff things
#+end_src

** DONE stuff2
CLOSED: [2023-08-07 Mon 20:06]

[2023-08-07 Mon 20:07]
this


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Russell Adams writes on Tue 29 Aug 2023 15:00:
 > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
 > > Why not just put the TODO heading in a code block with type org?
 > >
 > > Then you get all the toys, ignored by the main file.
 > 
 > If inline tasks are supposed to be Org enabled headings, but NOT
 > treated like headings in the current file, why not put them in a src block?
 > 
 > Doesn't this allow the same functionality without any new syntax
 > elements, or silly long *'s?

Are regular Org tags allowed in this scenario?  If not, I'd be
miserable.

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 01:49:26PM +0200, Alain.Cochard@unistra.fr wrote:
> Russell Adams writes on Tue 29 Aug 2023 15:00:
>  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
>  > > Why not just put the TODO heading in a code block with type org?
>  > >
>  > > Then you get all the toys, ignored by the main file.
>  >
>  > If inline tasks are supposed to be Org enabled headings, but NOT
>  > treated like headings in the current file, why not put them in a src block?
>  >
>  > Doesn't this allow the same functionality without any new syntax
>  > elements, or silly long *'s?
>
> Are regular Org tags allowed in this scenario?  If not, I'd be
> miserable.

It's a source block of type Org. That means *everything* that works in
Org works inside that block. You might open it with C-c C-' to open it
in an indirect buffer to enable everything.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Russell Adams writes on Wed 30 Aug 2023 14:36:
 > On Wed, Aug 30, 2023 at 01:49:26PM +0200, Alain.Cochard@unistra.fr wrote:
 > > Russell Adams writes on Tue 29 Aug 2023 15:00:
 > >  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
 > >  > > Why not just put the TODO heading in a code block with type org?
 > >  > >
 > >  > > Then you get all the toys, ignored by the main file.
 > >  >
 > >  > If inline tasks are supposed to be Org enabled headings, but
 > >  > NOT treated like headings in the current file, why not put
 > >  > them in a src block?
 > >  >
 > >  > Doesn't this allow the same functionality without any new syntax
 > >  > elements, or silly long *'s?
 > >
 > > Are regular Org tags allowed in this scenario?  If not, I'd be
 > > miserable.
 > 
 > It's a source block of type Org. That means *everything* that works in
 > Org works inside that block. You might open it with C-c C-' to open it
 > in an indirect buffer to enable everything.

Sorry, that's not enough for me to understand.  What would be the
equivalent of:

   * head :foo:
   *************** inlt :bar:
   *************** END

where the 'bar' tag could be used in exactly the same way as the 'foo'
tag.

Thanks.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.cochard@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France     | [ slot available for rent ]

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 04:06:51PM +0200, Alain.Cochard@unistra.fr wrote:
> Russell Adams writes on Wed 30 Aug 2023 14:36:
>  > On Wed, Aug 30, 2023 at 01:49:26PM +0200, Alain.Cochard@unistra.fr wrote:
>  > > Russell Adams writes on Tue 29 Aug 2023 15:00:
>  > >  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
>  > >  > > Why not just put the TODO heading in a code block with type org?
>  > >  > >
>  > >  > > Then you get all the toys, ignored by the main file.
>  > >  >
>  > >  > If inline tasks are supposed to be Org enabled headings, but
>  > >  > NOT treated like headings in the current file, why not put
>  > >  > them in a src block?
>  > >  >
>  > >  > Doesn't this allow the same functionality without any new syntax
>  > >  > elements, or silly long *'s?
>  > >
>  > > Are regular Org tags allowed in this scenario?  If not, I'd be
>  > > miserable.
>  >
>  > It's a source block of type Org. That means *everything* that works in
>  > Org works inside that block. You might open it with C-c C-' to open it
>  > in an indirect buffer to enable everything.
>
> Sorry, that's not enough for me to understand.  What would be the
> equivalent of:
>
>    * head :foo:
>    *************** inlt :bar:
>    *************** END
>
> where the 'bar' tag could be used in exactly the same way as the 'foo'
> tag.

Please give some examples of "bar used in exactly the same way as
foo".

Off the top of my head, I can only think that some agenda views and
collapsing to sparse tree may not recognize :bar: because it's inside
a source block.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain.Cochard]

Russell Adams writes on Wed 30 Aug 2023 16:31:

 > > What would be the equivalent of:
 > >
 > >    * head :foo:
 > >    *************** inlt :bar:
 > >    *************** END
 > >
 > > where the 'bar' tag could be used in exactly the same way as the 'foo'
 > > tag.

 > Please give some examples of "bar used in exactly the same way as
 > foo".

M-x org-agenda m bar

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.cochard@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France     | [ slot available for rent ]

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 04:39:50PM +0200, Alain.Cochard@unistra.fr wrote:
> Russell Adams writes on Wed 30 Aug 2023 16:31:
>
>  > > What would be the equivalent of:
>  > >
>  > >    * head :foo:
>  > >    *************** inlt :bar:
>  > >    *************** END
>  > >
>  > > where the 'bar' tag could be used in exactly the same way as the 'foo'
>  > > tag.
>
>  > Please give some examples of "bar used in exactly the same way as
>  > foo".
>
> M-x org-agenda m bar

Is bar used across many headings with inline tasks? Then it may not.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 05:08:40PM +0200, Russell Adams wrote:
> On Wed, Aug 30, 2023 at 04:39:50PM +0200, Alain.Cochard@unistra.fr wrote:
> > Russell Adams writes on Wed 30 Aug 2023 16:31:
> >
> >  > > What would be the equivalent of:
> >  > >
> >  > >    * head :foo:
> >  > >    *************** inlt :bar:
> >  > >    *************** END
> >  > >
> >  > > where the 'bar' tag could be used in exactly the same way as the 'foo'
> >  > > tag.
> >
> >  > Please give some examples of "bar used in exactly the same way as
> >  > foo".
> >
> > M-x org-agenda m bar
>
> Is bar used across many headings with inline tasks? Then it may not.

That said, I think the question is would any code for interpreting
embedded org source blocks be cleaner than the existing inline task code.


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Russell Adams <RLAdams@adamsinfoserv.com> writes:

> That said, I think the question is would any code for interpreting
> embedded org source blocks be cleaner than the existing inline task code.

I disagree. Src blocks are usually excluded from agendas and other
normal Org interactions - they are normally considered verbatim text
from the point of view of Org parser.

Special treatment of org src blocks would still introduce extra special
handling and on top of that interfere with the existing uses of org src
blocks, where the inner Org structure is not expected to have any effect.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>