From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Alternatives to inlinetasks? [was: Problems created by inlinetasks in agenda views] Date: Wed, 25 Apr 2018 07:43:05 +0200 Message-ID: References: <23248.48530.817172.917300@frac.u-strasbg.fr> <87in8ricbd.fsf@nicolasgoaziou.fr> <23261.58554.814734.521862@frac.u-strasbg.fr> <87sh7m0zsd.fsf@gmail.com> <871sf5pr4t.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1955b2f515d6056aa5bfab" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBDDF-0001Tm-Cy for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 01:43:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fBDDE-0002OY-0W for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 01:43:29 -0400 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:37619) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fBDDD-0002OK-Nk for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 01:43:27 -0400 Received: by mail-wm0-x22d.google.com with SMTP id l16so4508753wmh.2 for ; Tue, 24 Apr 2018 22:43:27 -0700 (PDT) In-Reply-To: <871sf5pr4t.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: org-mode list , Alain.Cochard@unistra.fr --94eb2c1955b2f515d6056aa5bfab Content-Type: text/plain; charset="UTF-8" Hi Nicolas, On Mon, Apr 23, 2018 at 11:08 PM, Nicolas Goaziou wrote: > Hello, > > Carsten Dominik writes: > > > I would be interested to discuss a better solution. It would be nice is > > list items could be TODO's, but I though long and har about this back > when, > > and over allo those years, I could not think of anything that could be > > implemented with reasonable effort. > > I think we have to make inline tasks more limited, yet still useful. > > One major technical drawback stems from the fact that they allow > contents. > > > *************** Foo > ... > *************** END > > > It means that they allow, e.g., properties (it hurts inheritance), or > clocks that do not belong to the containing headline but to the inline > task itself... It would be a major pain if we had to handle this > seriously, as a core feature. > Yes, I agree with this. It is there in oder to allow fully functional TODO entries, with scheduling and logging. But indeed, it does not play correctly with things like inheritance and clocking. > > Now, if we allow them to have no contents, it becomes much more > manageable. It means we can still have TODO, tags, priority, but no > clock, no properties, no log... > > It would also mean we would disallow SCHEDULED and DEADLINE keywords, > but we can make an exception for those, and allow a planning line right > after an inline task. > > So, basically, there would be two forms of inline tasks: > > *************** Foo > > and > > *************** Foo > SCHEDULED: <...> DEADLINE: <...> > Now we know why these are not properties :) > > With this simplification, we could manage them, probably without too > much hassle. > Not a bad compromise. It is also somewhat backward compatible, because ***** END would end up being just another inline-task-like headline, and older files would not stop working. > If you want to associate the task some contents, you can attach, e.g., > some drawer below. It is not part of the inline task syntax, yet it > could work well in practice: > > > *************** TODO Foo > :task: > This is because the... > :end: > > However, there is another important drawback: they look like headlines. > That breaks a fundamental assumption in Org: any line that doesn't start > with an asterisk (I'm oversimplifying here) "belongs" to the first line > starting with one above. This is simply not true with inline task, so we > use the `org-with-limited-levels'. It kind of works, except in parts of > Org that forgot to use it (lots of fun ahead). > Yes, inline task is an incomplete implementation, basically a hack. > > We could go further and get away from the starred syntax and the column > 0. E.g., > > !! TODO Foo :bar:baz: > > The advantage is that they would integrate better with the rest of the > document: > > - Grocery list > - Apples > - Bread > !! REMINDER ... > > However, it would be a /lot/ more work to implement the feature shared > with regular headlines (TODO switching, tags inheritance)... but, at > least, they would look better. > What would look even better is - Grocery list - Apples - TODO Bread SCHEDULED: .... But I have always thought that this would be nightmarish to implement, because the assumption that all of these special entries are nodes is sooo deep in the code... So I would say: either we keep it as the hack, or use the limitation you mention and get rid of the END line. But I am not sure it is really with the trouble to replace a bad hack with a slightly better hack. Carsten > > Regards, > > -- > Nicolas Goaziou > > --94eb2c1955b2f515d6056aa5bfab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nicolas,


On Mon, Apr 23, 2018 at 11:08 PM, Nico= las Goaziou <mail@nicolasgoaziou.fr> wrote:
Hello,

Carsten Dominik <dom= inik@uva.nl> writes:

> I would be interested to discuss a better solution.=C2=A0 It would be = nice is
> list items could be TODO's, but I though long and har about this b= ack when,
> and over allo those years, I could not think of anything that could be=
> implemented with reasonable effort.

I think we have to make inline tasks more limited, yet still useful.=

One major technical drawback stems from the fact that they allow
contents.


=C2=A0 *************** Foo
=C2=A0 ...
=C2=A0 *************** END

=C2=A0

It means that they allow, e.g., properties (it hurts inheritance), or
clocks that do not belong to the containing headline but to the inline
task itself... It would be a major pain if we had to handle this
seriously, as a core feature.

Yes,=C2=A0= I agree with this.=C2=A0 It is there in oder to allow fully functional
TODO entries, with scheduling and logging.=C2=A0 But indeed, it does
=
n= ot play correctly with things like inheritance and clocking.
=C2=A0

Now, if we allow them to have no contents, it becomes much more
manageable. It means we can still have TODO, tags, priority, but no
clock, no properties, no log...

It would also mean we would disallow SCHEDULED and DEADLINE keywords,
but we can make an exception for those, and allow a planning line right
after an inline task.

So, basically, there would be two forms of inline tasks:

=C2=A0 *************** Foo

and

=C2=A0 *************** Foo
=C2=A0 SCHEDULED: <...> DEADLINE: <...>
Now we know why these are not properties :)
=C2=A0

With this simplification, we could manage them, probably without too
much hassle.

Not a bad compromise.=C2= =A0 It is also somewhat backward compatible,
because ***** END wo= uld end up being just another inline-task-like headline,
and olde= r files would not stop working.
=C2=A0
If you want to associate the task some contents, you can attach, e.g.,
some drawer below. It is not part of the inline task syntax, yet it
could work well in practice:


=C2=A0 *************** TODO Foo
=C2=A0 :task:
=C2=A0 This is because the...
=C2=A0 :end:

However, there is another important drawback: they look like headlines.
That breaks a fundamental assumption in Org: any line that doesn't star= t
with an asterisk (I'm oversimplifying here) "belongs" to the = first line
starting with one above. This is simply not true with inline task, so we use the `org-with-limited-levels'. It kind of works, except in parts of=
Org that forgot to use it (lots of fun ahead).

Yes, inline task is an incomplete implementation, basically a hack.=
=C2=A0

We could go further and get away from the starred syntax and the column
0. E.g.,

=C2=A0 !! TODO Foo=C2=A0 =C2=A0 =C2=A0:bar:baz:

The advantage is that they would integrate better with the rest of the
document:

=C2=A0 - Grocery list
=C2=A0 =C2=A0 - Apples
=C2=A0 =C2=A0 - Bread
=C2=A0 =C2=A0 =C2=A0 !! REMINDER ...

However, it would be a /lot/ more work to implement the feature shared
with regular headlines (TODO switching, tags inheritance)... but, at
least, they would look better.

What wou= ld look even better is=C2=A0

=C2=A0 - Grocery= list
=C2=A0 =C2=A0 - Apples
=C2=A0 =C2=A0 - TODO Bread=
=C2=A0 =C2=A0 =C2=A0 SCHEDULED: ....

<= div>But I have always thought that this would be nightmarish to implement,<= /div>
because the assumption that all of these special entries are node= s is
sooo deep in the code...

So I would= say:

either we keep it as the hack, or use the li= mitation you
mention and get rid of the END line.=C2=A0 But I am = not sure it is really
with the trouble to replace a bad hack with= a slightly better hack.

Carsten


=C2=A0

Regards,
<= br> --
Nicolas Goaziou


--94eb2c1955b2f515d6056aa5bfab--