From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: please read: bug when marking tasks done Date: Sat, 12 Jan 2019 12:37:49 -0700 Message-ID: References: <87d0paprs6.fsf@gnu.org> <87wonhcpnj.fsf@nicolasgoaziou.fr> <871s5o8pgf.fsf@gnu.org> <87muobcur7.fsf@nicolasgoaziou.fr> <87woneykuc.fsf@gnu.org> <87y37tzbrd.fsf@nicolasgoaziou.fr> <87muo88up0.fsf@gnu.org> <87y37qxgn8.fsf@nicolasgoaziou.fr> <87pnt2neeg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:34011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giP9S-0007un-8b for emacs-orgmode@gnu.org; Sat, 12 Jan 2019 14:41:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1giP6P-0007DA-Iz for emacs-orgmode@gnu.org; Sat, 12 Jan 2019 14:37:54 -0500 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]:34870) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1giP6P-0007CQ-BL for emacs-orgmode@gnu.org; Sat, 12 Jan 2019 14:37:53 -0500 Received: by mail-lj1-x22d.google.com with SMTP id x85-v6so15749528ljb.2 for ; Sat, 12 Jan 2019 11:37:52 -0800 (PST) In-Reply-To: <87pnt2neeg.fsf@gnu.org> 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: cesar mena Cc: Leo Gaspard , emacs-orgmode manual> Text in the code and verbatim string is not processed for Org mode specific syntax, it is exported verbatim. i assumed that meant /during export/. it is in the markup section. thus, someplace in manual, perhaps say that verbatim and code have more effects than just export. On 1/12/19, cesar mena wrote: > hello, > > Nicolas Goaziou writes: > >>>> Now, we might make its contents by marking them as verbatim, for >>>> example. E.g., >>>> >>>> - Rescheduled from =3D[2019-02-05 Tue .1m]=3D on [2018-09-29 Sat 18:= 50] >>> >>> that's not a bad idea, but what about the other way round? >>> >>> that is, inactive timestamps with repeaters do not update unless they >>> are >>> marked as you suggest. this way current workflows are not affected and >>> inactive timestamps can be made to update if requested. >> >> The other way around is not possible because =3D...=3D means "verbatim". >> This would be contradictory. > > i see. i didn't know =3D...=3D meant verbatim. so in light of this new > knowledge :) your solution makes a lot of sense. i was originally > opposed to it because it means current documents will have to change to > add =3D...=3D but in the end it seems the simplest. > >> The main question is: what to do with an "inactive time stamp with >> repeater". >> >> The original report, that lead to the incriminated commit, emphasized >> the "repeater" part, arguing a repeater should induce the time stamp is >> meant to be repeated, notwithstanding its nature. >> >> You are emphasizing the "inactive" part of it, arguing that anything >> inactive should not change dynamically. >> >> Both arguments can be heard. I agree yours is more conservative. Yet, >> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the >> OP. > > i'm ok going with the verbatim syntax - rescheduled lines will now look > like (w/o the double quotes?): > > - Rescheduled from =3D[2019-02-05 Tue .1m]=3D on [2018-09-29 Sat 18:50] > >> I'm trying to keep Org as simple as possible, but different users have >> different use cases, and, in some annoying situations like this one, >> these use cases conflict. > > we are ever grateful. > > best, > -cm > > > --=20 The Kafka Pandemic: The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time. "You=E2=80=99ve really gotta quit this and get moving, because this is murd= er by neglect." --- .