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 come 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. > > 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, -- 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