From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: org version numbers in file - WAS: Tangling takes long - profiling and calling R Date: Tue, 23 Jun 2015 11:04:11 +0200 Message-ID: References: <87ioaobvl1.fsf@selenimh.access.network> <87a8vzc1u8.fsf@selenimh.access.network> <87381r9vk3.fsf@selenimh.access.network> <87egl977u3.fsf@selenimh.access.network> <877fr16s8k.fsf@selenimh.access.network> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7K7z-0003vz-TJ for emacs-orgmode@gnu.org; Tue, 23 Jun 2015 05:04:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7K7w-0007Ur-Fo for emacs-orgmode@gnu.org; Tue, 23 Jun 2015 05:04:23 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:36837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7K7w-0007Ue-75 for emacs-orgmode@gnu.org; Tue, 23 Jun 2015 05:04:20 -0400 Received: by wicnd19 with SMTP id nd19so99504219wic.1 for ; Tue, 23 Jun 2015 02:04:19 -0700 (PDT) In-Reply-To: <877fr16s8k.fsf@selenimh.access.network> (Nicolas Goaziou's message of "Thu, 18 Jun 2015 15:50:03 +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" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Nicolas Goaziou writes: > 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. I was surprised as well, but it could be other changes as well. > > Could you provide another report, with an uncompiled Org? Thanks - I'll try to remember - for the moment I am quite busy but will com= e back to your question. > >>> 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. The question is really if one can become more user friendly without to much effort - that's why I suggested to put this check into the linter and to run linter automatically if the file version is older than the org version. I can live with how it is at the moment. > >> 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 from R, that when a function is deprecated and about to be removed from R, it will display a warning message whenever it is used. This is quite user friendly and helps making the changes in the code. This obviously does not work in org in the same way - which is why I suggested to put into the tangling routine. Would it be possible to display the changes / new features / breaking change in a new version official release version upon starting this version the first time, so that nobody can say "I did not read this"? > >> I know - unfortunately. But as far as I understand, it will be in the >> next major release? > > Hopefully, yes. Great. > >> 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. OK - haven't considered the user defined 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.=20 > > 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. > I like this suggestion and that one possibly can specify the medium as a prefix? That way, it would be possible to add it easily. > Of course, we can provide a brand new function, instead. > > Do you want to provide a patch for that? Sorry - I don't think that my elisp skills are sufficient for this. > >> 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. Yes - export templates. I see it as an useful information to debug old non-working org files manually - when you know the org version under which it *was* working, you can look for significant changes since than and fix these. In addition, if it is included, it will be easier to use it later on. Thanks, Rainer > > > Regards, =2D-=20 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,= UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer@krugs.de Skype: RMkrug PGP: 0x0F52F982 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJViSEPAAoJENvXNx4PUvmCv0cIAOjg74vnwyDUJa/P9zscxzPH WB6tr/z3JpAqO/fZpl0vnDEEKDVknRxJa0nUxrULPt6of0cV6dQQRHoBsDzFpqoO bi1Wd+Xm1DIJX6xSoB7jXIq8CEnbxKvnJKgKb083lyNUDhgqUnMCVTBNyLI+WnRu 4r8WAZmvbLFWhLqX8BhUnYCGzwSjGbJmnKKP5VnMr8wGx/ic14sue7GHIUDqEB6H FIkDgtT0lVyXp1fyzIOmsm8iH4BV6HtboeOv+iZbYys4SPUmBeZGFCiIYj7RMqcD UERRtCNiwxTzGszXxzHDKJdzIyFemH4JHZsPJMXP3XBoyDBG5qY0xm/SFdgNyPk= =vFVV -----END PGP SIGNATURE----- --=-=-=--