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. Best regards, Seb -- Sebastien Vauban