From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id QJoQAxI6x2AtawEAgWs5BA (envelope-from ) for ; Mon, 14 Jun 2021 13:14:26 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 6KLCORE6x2BnZQAAB5/wlQ (envelope-from ) for ; Mon, 14 Jun 2021 11:14:25 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 790202CCAF for ; Mon, 14 Jun 2021 13:14:25 +0200 (CEST) Received: from localhost ([::1]:47514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lskXw-0006r8-9u for larch@yhetil.org; Mon, 14 Jun 2021 07:14:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lskXZ-0006pu-RC for emacs-orgmode@gnu.org; Mon, 14 Jun 2021 07:14:01 -0400 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:42730) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lskVd-0001nk-AT for emacs-orgmode@gnu.org; Mon, 14 Jun 2021 07:14:01 -0400 Received: by mail-lj1-x22c.google.com with SMTP id r16so19604767ljk.9 for ; Mon, 14 Jun 2021 04:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wKe5/AlgFpWpKtPA26uqMLDAeqpfH67azVgu56aU8gE=; b=orLJz0+AgvJii/Yq4TWvWLCxGM4234bZLCPByY8QJ6HZcXS3BLc0VunXJSY6G1e9GA 6sp8tsP5HqIFvFIjcHz1nZcRebDYAZt8F2MytCcCF3BW4v1Rqo/YGFUsIymVg2jPWZ/9 Fv7Zps6yhDgozNmnHuvqbes03sc8GlPMMXk4IH2sfQJ/XVvJKIS9P9LpGiS6VksB6vWP z0edo4sJsbiE6Qw95SB+bjfHpdg49dw+NMmMrpxHTnAFLW1yS2xN+nXrq/OzpPkmYgqH /HWKRJV0pNUyfnQowrwRSTsrBS5/+XXe+Y7S7GPtO9WDb7IvvL6axf7cDwnfXojG2VWS Jo3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wKe5/AlgFpWpKtPA26uqMLDAeqpfH67azVgu56aU8gE=; b=peg+yAtTm2x8pS+m423G5ERTiNJUDTfglwCACfLc+IPhRLcdBFAHKALnquhsEIztDA YG69iJlttSyu4GlqhansEa68bR5cSU/EScsuUNm5aZm/TkdenYfRGhRbIqFPBbYEgsrc HuWjteKIR3C+ypmJwVt0pwPNTGWS+Zo585VFIsowBodyqEepPQ0Y4Jua7LmgA/wb0+km /KWAM1Gg5oplu2AtSESYHuOCNa6eKmbPU4Tje+kjDiY8euMCJLL+VFAurpQeQmSWyBHl QI/ps3IKcC/44Ptbhle43bRDGAoR20xSavbyPZRDpGLuMAVbNMa5fe6IP8p+MqKFNA/+ W/2A== X-Gm-Message-State: AOAM533Q1kCtcii/PKgWlvnmTMRMr5VxKT70LDqLIzpAZcFVgNQFcfne CSki+nHNx9+Yd7Ny3VmiYBgzw3GGSvI0tMhUZi7aPZ3g X-Google-Smtp-Source: ABdhPJyQfAypERpawTf0zN9zNTsD98yJeyT/Q4zyzRa6/x1n7RN48pWw4HTvXhKF+RcsrwkqIXvZVj2oDgNAjb75gpk= X-Received: by 2002:a05:651c:150a:: with SMTP id e10mr13590125ljf.215.1623669118757; Mon, 14 Jun 2021 04:11:58 -0700 (PDT) MIME-Version: 1.0 References: <87o8cghzt3.fsf@nicolasgoaziou.fr> In-Reply-To: <87o8cghzt3.fsf@nicolasgoaziou.fr> From: Michael Dauer Date: Mon, 14 Jun 2021 13:11:48 +0200 Message-ID: Subject: Re: BUG: export options properties drawer position and planning dates To: emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="0000000000000e6d3705c4b7ed95" Received-SPF: pass client-ip=2a00:1450:4864:20::22c; envelope-from=mick.dauer@gmail.com; helo=mail-lj1-x22c.google.com X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1623669265; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=wKe5/AlgFpWpKtPA26uqMLDAeqpfH67azVgu56aU8gE=; b=mtBUQAOl5mtwfasmCJPNbstEsqpjDgiE0GPcut42l2Kf05l0p0kv2tuL4gcToS3AUS8K0n yWZJRYeA1RY+ARevQMeDSq1arkxUOW2dWLcoO6/wrs12PLe4wSqFeL1v9bZE8aAGY2VgJQ n2yrPdA4lPcDooTJZrnKPPuQAaqbS6kgs6RBze703/b+a9sIQNq5Rn8VkW+WOZRnjKCVV5 nsvcMshTS/iqNNDGHLicctcdgQXUzT3Tr0jvRkSrunNew+D0qFc3Jji/+99AllcQI9wNdK bf0kX3I4Hl/qw71W7p8Y4+kVe6I16ckMrObulgjzjQMUf7n6rew5FxG/KLAoNw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1623669265; a=rsa-sha256; cv=none; b=JcUDoB2Yii+TIVADbw3vnzzljRb0cyWCweAaJzFknwwXbT7OwVKiPgdRHF9I9IaL4xjHMU mk9gPVOlIc3YQcB7Ui9B7WcVEkBAp5z4K+mOs3qtfSR+djmjDwdAmt3wNswVyYAqEeSGKm h27xljDZKMYNNGsYZWwUVQyX7RVRK3r4rDF3LByeOj3Qm+CY3Fulcijl/Ga90zTGS6X7M8 NNqt+FPL4Bcvf/NxI2aaRJQBUk7oUg4hLsDx4t1tDtyiFsve9jQGBsqACXwTnQ/V3H2XdP QO0RNq0T44gFMquh89ReYEQDtr3x+BPFxAGkmc8kdNspg7o129kD7AISKnFmXQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=orLJz0+A; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -3.12 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=orLJz0+A; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 790202CCAF X-Spam-Score: -3.12 X-Migadu-Scanner: scn0.migadu.com X-TUID: Dm4P5fxhvQmp --0000000000000e6d3705c4b7ed95 Content-Type: text/plain; charset="UTF-8" Hi Nicolas, I would understand that the export would take the export settings of the current heading to control the export of the complete subtree. This would be the case for the second example, where the scheduled date is (correctly) placed above the properties drawer. BUT: 1. The much better logic would be that each node determines e.g. the with-planning by its own (or inherited) properties. 2. This actually works when the scheduled date is (incorrectly) placed below the drawer. It is not just treated as the first paragraph, but omitted when the with-planning property of its node is nil, while normal text would be exported. I did not check the code. I assume that the better logic was actually implemented with the mistake of assuming an incorrect order of planning line and properties drawer. Regards, Michael Am Di., 8. Juni 2021 um 22:22 Uhr schrieb Nicolas Goaziou < mail@nicolasgoaziou.fr>: > Hello, > > Michael Dauer writes: > > > There seems to be a bug in Org mode version 9.4.6 (9.4.6-gcf30f7: > > EXPORT_OPTIONS (at least p for with-planning) is only respected if there > is > > no planning date placed above the properties drawer. > > > >>>> > > * TODO export options > > :PROPERTIES: > > :EXPORT_OPTIONS: p:nil > > :END: > > SCHEDULED: <2021-06-08 Di.> > > ** TODO l1 > > :PROPERTIES: > > :EXPORT_OPTIONS: p:t > > :END: > > SCHEDULED: <2021-06-08 Di.> > > *** TODO l2 > > SCHEDULED: <2021-06-08 Di.> > > **** TODO l3 > > :PROPERTIES: > > :EXPORT_OPTIONS: p:nil > > :END: > > SCHEDULED: <2021-06-08 Di.> > > ***** TODO l4 > > SCHEDULED: <2021-06-08 Di.> > > <<< > > > > produces the somehow expected behavior: > >>>> > > SCHEDULED: <2021-06-08> > > > > > > TODO l1 > > ======= > > > > SCHEDULED: <2021-06-08> > > > > > > TODO l2 > > ~~~~~~~ > > > > TODO l3 > > ------- > > > > SCHEDULED: <2021-06-08> > > > > > > * TODO l4 > > <<< > > > > But it is syntactically incorrect since the planning dates have to be the > > first line below the heading. > > This is correct, because the SCHEDULED lines are exported as paragraphs, > which is what they are. > > > For the following syntactically correct > > snippet the export_options are ignored: > >>>> > > * TODO export options > > SCHEDULED: <2021-06-08 Di.> > > :PROPERTIES: > > :EXPORT_OPTIONS: p:nil > > :END: > > ** TODO l1 > > SCHEDULED: <2021-06-08 Di.> > > :PROPERTIES: > > :EXPORT_OPTIONS: p:t > > :END: > > *** TODO l2 > > SCHEDULED: <2021-06-08 Di.> > > **** TODO l3 > > SCHEDULED: <2021-06-08 Di.> > > :PROPERTIES: > > :EXPORT_OPTIONS: p:nil > > :END: > > ***** TODO l4 > > SCHEDULED: <2021-06-08 Di.> > > <<< > > >>>> > > TODO l1 > > ======= > > > > TODO l2 > > ~~~~~~~ > > > > TODO l3 > > ------- > > > > * TODO l4 > > <<< > > > > Same behavior I see with HTML export. > > Did you use subtree export? Where was the point when you exported it? > > For example, if I use a subtree export in the first section above, I get > no planning line, you if I subtree-export from the second section, i.e., > "l1", all subsequent planning lines appear. > > IOW, I cannot reproduce your issue. > > Regards, > -- > Nicolas Goaziou > --0000000000000e6d3705c4b7ed95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nicolas,

I would understand that the= export would take the export settings of the current heading to control th= e export of the complete subtree. This would be the case for the second exa= mple, where the scheduled date is (correctly) placed above the properties d= rawer.

BUT:
1. The much better logic wou= ld be that each node determines e.g. the with-planning by its own (or inher= ited) properties.
2. This actually works when the scheduled date = is (incorrectly) placed below the drawer. It is not just treated as the fir= st paragraph, but omitted when the with-planning property of its node is ni= l, while normal text would be exported.

I did not = check the code. I assume that the better logic was actually implemented wit= h the mistake of assuming an incorrect order of planning line and propertie= s drawer.

Regards,
Michael
Am Di., = 8. Juni 2021 um 22:22=C2=A0Uhr schrieb Nicolas Goaziou <mail@nicolasgoaziou.fr>:
Hello,

Michael Dauer <mick.dauer@gmail.com> writes:

> There seems to be a bug in Org mode version 9.4.6 (9.4.6-gcf30f7:
> EXPORT_OPTIONS (at least p for with-planning) is only respected if the= re is
> no planning date placed above the properties drawer.
>
>>>>
> * TODO export options
> :PROPERTIES:
> :EXPORT_OPTIONS: p:nil
> :END:
> SCHEDULED: <2021-06-08 Di.>
> ** TODO l1
> :PROPERTIES:
> :EXPORT_OPTIONS: p:t
> :END:
> SCHEDULED: <2021-06-08 Di.>
> *** TODO l2
> SCHEDULED: <2021-06-08 Di.>
> **** TODO l3
> :PROPERTIES:
> :EXPORT_OPTIONS: p:nil
> :END:
> SCHEDULED: <2021-06-08 Di.>
> ***** TODO l4
> SCHEDULED: <2021-06-08 Di.>
> <<<
>
> produces the somehow expected behavior:
>>>>
> SCHEDULED: <2021-06-08>
>
>
> TODO l1
> =3D=3D=3D=3D=3D=3D=3D
>
>=C2=A0 =C2=A0SCHEDULED: <2021-06-08>
>
>
> TODO l2
> ~~~~~~~
>
> TODO l3
> -------
>
>=C2=A0 =C2=A0SCHEDULED: <2021-06-08>
>
>
> * TODO l4
> <<<
>
> But it is syntactically incorrect since the planning dates have to be = the
> first line below the heading.

This is correct, because the SCHEDULED lines are exported as paragraphs, which is what they are.

> For the following syntactically correct
> snippet the export_options are ignored:
>>>>
> * TODO export options
> SCHEDULED: <2021-06-08 Di.>
> :PROPERTIES:
> :EXPORT_OPTIONS: p:nil
> :END:
> ** TODO l1
> SCHEDULED: <2021-06-08 Di.>
> :PROPERTIES:
> :EXPORT_OPTIONS: p:t
> :END:
> *** TODO l2
> SCHEDULED: <2021-06-08 Di.>
> **** TODO l3
> SCHEDULED: <2021-06-08 Di.>
> :PROPERTIES:
> :EXPORT_OPTIONS: p:nil
> :END:
> ***** TODO l4
> SCHEDULED: <2021-06-08 Di.>
> <<<

>>>>
> TODO l1
> =3D=3D=3D=3D=3D=3D=3D
>
> TODO l2
> ~~~~~~~
>
> TODO l3
> -------
>
> * TODO l4
> <<<
>
> Same behavior I see with HTML export.

Did you use subtree export? Where was the point when you exported it?

For example, if I use a subtree export in the first section above, I get no planning line, you if I subtree-export from the second section, i.e., "l1", all subsequent planning lines appear.

IOW, I cannot reproduce your issue.

Regards,
--
Nicolas Goaziou
--0000000000000e6d3705c4b7ed95--