From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: More clocktable breakage Date: Sat, 06 May 2017 10:10:02 +0200 Message-ID: <87pofmflt1.fsf@nicolasgoaziou.fr> References: <877f39nr05.fsf@Rainer.invalid> <87d1d0p2qx.fsf@nicolasgoaziou.fr> <87tw5bumck.fsf@Rainer.invalid> <87shkt4tuf.fsf@Rainer.invalid> <8737ct1xyr.fsf@nicolasgoaziou.fr> <87fugt4npu.fsf@Rainer.invalid> <87pofxzctf.fsf@nicolasgoaziou.fr> <87wpa4fjio.fsf@Rainer.invalid> <878tmixsvo.fsf@nicolasgoaziou.fr> <87tw556kxo.fsf@Rainer.invalid> <87vapjgq93.fsf@nicolasgoaziou.fr> <87r307tb9k.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d6un1-0003IJ-4z for emacs-orgmode@gnu.org; Sat, 06 May 2017 04:10:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d6un0-00051H-0W for emacs-orgmode@gnu.org; Sat, 06 May 2017 04:10:07 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:46568) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d6umz-00051C-QV for emacs-orgmode@gnu.org; Sat, 06 May 2017 04:10:05 -0400 In-Reply-To: <87r307tb9k.fsf@Rainer.invalid> (Achim Gratz's message of "Tue, 02 May 2017 19:32:39 +0200") 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: Achim Gratz Cc: emacs-orgmode@gnu.org Hello, Achim Gratz writes: > No, I meant context of application, rather than context in the > syntactical sense. Org-element-* deals with syntax, nothing else. > Whether you need strict syntactical interpretation or something else > gets decided someplace else. OK. Then we agree here. > Whatever it sounds like, what you want in the clocktables example and > the properties example (and elsewhere) is something that looks, walks > and talks like a timestamp if you'd put it into the proper context. In > each of these places the text that looks like timestamp but isn't > (org-element says so) will be fed into some machinery that emerges with > a result that is indistinguishable from what you'd get if that text > would have been a proper timestamp and then uses that result to do > whatever it wants to do with it (i.e. most certainly not build up an > agenda, although it could do that as well). It uses a bit of Org syntax > in the improper context to achieve this (and this requires precisely to > ignore that context or at least check with something more loose than > org-element). I also agree, but it seems to contradict what you write below. > In a comment that timestamp-looking text doesn't have any function, so > it's in a different category, I must insist. As I said, I can see > somebody wanting to have this text be editable like any other timestamp > also, but it's really the other uses where it's used meta-syntactically > that I'd like to focus on. Here, I don't follow you anymore. A timestamp in a comment is "something that looks, walks and talks like a timestamp if you'd put it into the proper context", too. So there's no difference with properties or the clock table. > One of the differences to text in comments (or generally quoted > material) is that there is an expectation that this sort of timestamp > is correct, since they are intended to be input to further processing. True, but if that timestamps isn't correct, it doesn't "look, walk and talk" like a timestamp anymore, so this doesn't apply to the above. Anyway, I think we're digressing. We're talking about design, yet, to tell the truth, I don't even know anymore what the original, concrete, problem is really about. As I asked 5 weeks ago (!), could you provide an ECM demonstrating the issue so that I can fix it, in the light of our discussion? Regards, -- Nicolas Goaziou