Re: org version numbers in file - WAS: Tangling takes long - profiling and calling R

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Rainer M Krug <Rainer@krugs.de> writes:

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