Re: [DISCUSSION] Re-design of inlinetasks

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

[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

[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

[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

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

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>

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>

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