Envoyé de mon iPhone
> Le 16 juin 2015 à 14:45, Sebastien Vauban <sva-n...@mygooglest.com> a écrit : > > Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> Rainer M Krug <rai...@krugs.de> writes: >> >>> I would not remove it as even I have some org files using them - shame >>> on me. > > To be clear, are we talking of constructs such as: > > --8<---------------cut here---------------start------------->8--- > ** Subtree > :PROPERTIES: > :tangle: no > :END: > --8<---------------cut here---------------end--------------->8--- > > ? > >> We can check for that in Org Lint and warn the user. >> >>> But what about making it user configurable? a variable >>> ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would >>> enable this additional code, if nil it would be skipped? The default >>> should be set to ~t~ to be backward compatible. >> >> This looks like backward-compatibility hell to me. If we make it >> conditional the feature is no longer deprecated, is it? > > I understand your point, and I'm enclined to agree with you (for > a long-term sanity and stability of the mode we all cherish) -- even if > I dunno yet if I still use such (Well, if this is the above structure, > then, yes, I use it a lot as well...). > >> The more general question is: how many years do we need to wait before >> removing a deprecated (i.e., marked as such) feature? > > Your suggestion with Org-lint, or even writing a function that would > convert from the old to the new syntax, makes a shorter period > acceptable IMO. I don't think that it is that easy, as the new syntax is not equivalent to the old syntax. One example; defining one tangle target for the mother tree, and others for the child trees. This is by no means trivial (or even possible) with the new syntax, while it would be possible with the old syntax (if I remember correctly). So for backward compatibility, the support should stay, but one had to enable it explicitly. Cheers, Rainer > > Best regards, > Seb > > -- > Sebastien Vauban > >
