From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: org version numbers in file - WAS: Tangling takes long - profiling and calling R Date: Thu, 18 Jun 2015 15:50:03 +0200 Message-ID: <877fr16s8k.fsf@selenimh.access.network> References: <87ioaobvl1.fsf@selenimh.access.network> <87a8vzc1u8.fsf@selenimh.access.network> <87381r9vk3.fsf@selenimh.access.network> <87egl977u3.fsf@selenimh.access.network> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5aBR-0002TP-0U for emacs-orgmode@gnu.org; Thu, 18 Jun 2015 09:48:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5aBP-0006aU-NQ for emacs-orgmode@gnu.org; Thu, 18 Jun 2015 09:48:44 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:33248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5aBP-0006Vn-HX for emacs-orgmode@gnu.org; Thu, 18 Jun 2015 09:48:43 -0400 In-Reply-To: (Rainer M. Krug's message of "Thu, 18 Jun 2015 15:25:57 +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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rainer M Krug Cc: "emacs-orgmode@gnu.org" , Rainer M Krug Rainer M Krug writes: > Nicolas Goaziou writes: > >> Rainer M Krug writes: >> >>> Yes - that's true. But who of the longer org users reads the manual of >>> features they use regularly? >> >> Ah well. I turned 3 `mapcar' calls into a single one. It should, >> hopefully improve speed in your case (could you confirm it). > > Hm - it takes actually longer (as far as I can see), but the mapcar > calls in the function now take 24% each (compared to 20 before). Considering the basic change I made, I fail to see how it could take longer. In the worst case, it should be equivalent. Could you provide another report, with an uncompiled Org? >> Also, I suggest to signal the deprecation in ORG-NEWS (old timers read >> it, right?) and remove this part of code during 8.4 development. > > I guess they might skim over it... Then, it's their responsibility. > What about putting a warning in the function in tangling (and other > places where this construct is evaluated) that this construct will not > be be allowed in the next major release? This is not the usual way to deprecate features. Breaking changes are written in ORG-NEWS, I don't see why this one would make an exception. > I know - unfortunately. But as far as I understand, it will be in the > next major release? Hopefully, yes. > True - but as far as deprecation of org constructs concerned, checks > could be explicitly put into the org-lint library - for some features > there are even conversion functions available - and linting could be > more robust in regards to deprecation checks? Not really. For example, even if we want to check for deprecated Babel header properties, there's no way to tell if ":cache: yes" is an obsolete way to use them or user's own properties. > In the spirit of reproducibility, I would at least suggest to introduce > a function which inserts an argument > > #+ORG_FILE_VERSION: TheActualOrgVersionProbablyWithGitHash > > if it does not exist, and if it exist, updates it to the actual > version? I see no objection to this. We could extend `org-version' to do this, e.g., change its signature to (org-version &optional full medium) where MEDIUM can be `insert', `message' or `keyword'. In the latter case, it would create or update any such keyword in the current document. Of course, we can provide a brand new function, instead. Do you want to provide a patch for that? > This should be incorporated into the default header sets. What are the default header sets? You mean export template? I don't think this is needed as long as we don't use this keyword. Regards,