Proposal for filter option 'needs_safety'

Creating filters that work on different safety contexts is currently not possible. Let’s say I want to create an air_quotes filter that puts a " around some words and I want it to work on HTML but also on plain text.

1. Using default filter settings, the result is always unsafe for HTML, so this only works for plain text.

2. Using 'pre_escape' => 'html', 'is_safe' => ['html'] and " as the quote character in my callback works fine for HTML, but cannot be used in plain text contexts because everything gets HTML encoded.

3. Using 'preserves_safety' => ['html'] mostly works, but because the characters my filter wants to inject into the text are reserved in HTML, this is unsafe.

For option 3 to work safely, my filter needs to know if the source text is safe for HTML or not. It then could encode it’s own modifications accordingly so that it can guarantee that the “safety is preserved”.

My current solution for this problem is: Create one air_quotes filter using option 1 for plain text and create another air_quotes_html filter using option 2.

Because of that I would like to propose the needs_safety option for the TwigFilter class. If enabled this would prepend the arguments list of the filter callback with the value of ->getSafe($node) from its values node.

If you agree, I’d like to create a pull request to add that feature.

Start with the TwigFilter class and the values node's getSafe($node) behavior described in the proposal. Review existing safety-related filter options and callback argument handling before assessing how needs_safety should work. Done means the option supports filters across HTML-safe and plain-text contexts without requiring separate filters, with tests covering both contexts.