From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: More clocktable breakage Date: Fri, 28 Apr 2017 00:49:00 +0200 Message-ID: <87pofxzctf.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3sDj-0000IB-GY for emacs-orgmode@gnu.org; Thu, 27 Apr 2017 18:49:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d3sDg-0002GK-CL for emacs-orgmode@gnu.org; Thu, 27 Apr 2017 18:49:07 -0400 Received: from relay7-d.mail.gandi.net ([2001:4b98:c:538::200]:54625) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d3sDg-0002F9-5f for emacs-orgmode@gnu.org; Thu, 27 Apr 2017 18:49:04 -0400 In-Reply-To: <87fugt4npu.fsf@Rainer.invalid> (Achim Gratz's message of "Thu, 27 Apr 2017 22:09:17 +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 Achim Gratz writes: > and org-at-block-p only matches in the first line of a dynamic block, [...] > N.B.: The regex used in org-at-block-p is overbroad since it matches the > whole block, I think it should use org-at-dblock-start-re instead. This old and buggy function has nothing to do with the problem at hand. Also, even if it used org-at-dblock-start-re, it would still be buggy (is it closed? is it in an example block?). > Anyway, when you changed the scope of that function you'd need to check > all users of the API and fix them where necessary. Really? I thought it would magically happen... somehow. Silly me. > The main users of that predicate were and still are the org-shift* > family of commands and they do expect a looser recognition than what > you implemented based on the docstring. Maybe that's true in other > places also, I haven't checked. The main user of that predicate is the agenda, now. > It's also obvious that the test coverage of this is bad. Patch welcome. > So that looser recognition would need to be factored out again or you > revert this predicate and apply the stricter check where it matters > (the agenda functions, most likely). Another idea is to add an optional argument to `org-at-timestamp-p' to allow "sloppy" matching (or strict matching, it doesn't really matter) and skip checks when it is required. So all functions requiring this predicate can make use of it, as long as they call it properly. WDYT? > Also, again, I think that function is buggy even without these issues as > the only code I can find in org-element-context that deals with > timestamps is conditional on being on a planning line and if that's true > we should never get there. I don't think there is a bug there. Do you have an ECM? Regards,