From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: org version numbers in file - WAS: Tangling takes long - profiling and calling R Date: Wed, 17 Jun 2015 09:16:45 +0200 Message-ID: References: <87ioaobvl1.fsf@selenimh.access.network> <87a8vzc1u8.fsf@selenimh.access.network> <87381r9vk3.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]:39054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z57am-0004xY-Ur for emacs-orgmode@gnu.org; Wed, 17 Jun 2015 03:17:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z57aj-0002ue-DI for emacs-orgmode@gnu.org; Wed, 17 Jun 2015 03:17:00 -0400 Received: from mail-wg0-f54.google.com ([74.125.82.54]:36258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z57aj-0002tj-3T for emacs-orgmode@gnu.org; Wed, 17 Jun 2015 03:16:57 -0400 Received: by wgzl5 with SMTP id l5so28832696wgz.3 for ; Wed, 17 Jun 2015 00:16:56 -0700 (PDT) In-Reply-To: <87381r9vk3.fsf@selenimh.access.network> (Nicolas Goaziou's message of "Tue, 16 Jun 2015 23:45:32 +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: > >>> We can check for that in Org Lint and warn the user. >> >> That would be a really good idea! > > Done. Great - thanks. > >> Before deleting it, one should get a warning that a certain feature is >> deprecated. At the moment, it is only mentioned in the help (as far as >> I am aware). > > It has been mentioned in the manual for the last two years. See footnote > in (info "(org)Header arguments in Org mode properties"). Yes - that's true. But who of the longer org users reads the manual of features they use regularly? org-lint seems to become the place where these changes can be marked and the user be notified - that is really brilliant. I could imagine the following automatic workflow to enable automatic linting of org files upon opening when they were saved under an older (or unknown) version of org: 1) a new argument is introduced : #+FILE_ORG_VERSION: 8.3beta 2) when opening an org file, this version is checked. The following cases are possible: - parameter not present: assume that file version is older and run org-li= nt - file version older then org version: run org-lint - file version identical to org version: just open - file version newer: run org-lint 3) after reviewing the results, org-lint could offer to update the file version (#+FILE_ORG_VERSION) to the version of org-mode. This should be, by the way, possible to do even when running org-lint manually. 4) this behavior should be possible to disabled by an additional header #+ORG_FILE_VERSION_CHECK: f but not via emacs.el as this should be the standard behavior. One could go even one step further, to define a minimum and maximum org ver= sion so that one get's a warning that the file requires a different org version than used: #+REQUIRED_ORG_VERSION: min:8.0 would require org newer and including than 8.0 #+REQUIRED_ORG_VERSION: max:8.0 would require org older and including than 8.0 #+REQUIRED_ORG_VERSION: min:8.0 max:8.9.9=20 a version between and including 8.0 and 8.9.9 because e.g. a feature used was only present during these releases or #+REQUIRED_ORG_VERSION: min:8.0 max:8.0=20 require version exactly version 8.0 where the warning comes when the version is different to the ones specified. I really think that org files should have the org-versions that was used to write them and the org version required to run them. Even though that org-documents are documents, I kind of see them as *add-ons* to org, because they can contain code to be execute, variables to be set, and added functionality to the standard org. So to make this more robust, to store the org version used to create the file version and the required org versions would make perfect sense to me. This should obviously only include release, alpha, beta, rc and not git checkout values. Cheers, 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 iQEcBAEBCAAGBQJVgR7kAAoJENvXNx4PUvmCHSEH/j/imo2DrvYgKf6/WMCOOl1G BS1iqgyynVSk4TzyZWvdxnZ/uFTrNV56VgoMqPzsqbFPCtYoB+K7IjUGgorNJuqQ ouRj8Gdl2FlxIF1CRg6GIFDCZX8FnWi0DkfxRTYlBXoUcYbfxZoVLKHt/gshpbnO dJIT6SpisIp0PIdernqcEuXvi81aozhfZ6gSQQJ+iys/rneTolYo/Z0iwtdKqY4n /b1UR3U+MGlsyvRyFeYZduP+Mdu9+AhghrN3kjOtHVsLFMXIjbPX0iP2djufdigP 3QWOZjKDrYvFP11eGNAqfPSQcJt3c2ZIVkmiUR9BecbM1VnTmgj3pHI6nVix3yY= =Pgwn -----END PGP SIGNATURE----- --=-=-=--