Rainer M Krug <rai...@krugs.de> writes: > Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > >> Rainer M Krug <rai...@krugs.de> 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,
