Jeremy Evans

I can reproduce this issue. Here's the template code generated: ```ruby TOPOBJECT.class_eval do def __tilt_18440(locals) begin;extend Haml::Helpers;_hamlout = @haml_buffer = Haml::Buffer.new(haml_buffer, {});_erbout = _hamlout.buffer; __in_erb_template = true; _haml_locals = locals;;_hamlout.buffer

A good use case for this is mentioned in the docs, with something like `foo.scss.erb`. This allows you to preprocess the scss with erb. There are other similar cases, like...

This doesn't really replace `templates_for`, though it certainly could use that internally instead of manually splitting the extension string. All `templates_for` does is return an array of template classes, so...

I prefer the explicit approach of registering the pipelines ahead of time. Trying to work without registering in advance raises ambiguity issues and is probably worse from a performance perspective....

Fair enough. Do you want some more time to think about it, or should I publish it as an external gem? You could always integrate the external gem later if...

I guess I was a bit late in updating this, but I added an external gem for this last October: https://rubygems.org/gems/tilt-pipeline

@judofyr Any additional thoughts on this? I don't have a problem adding this to tilt, but if you are still leaning against, I'll just close this. People can always use...

Thanks for the report. It would be great to get a pull request to support ffmpeg 5 while keeping current ffmpeg 4 support. Unfortunately, this is not something I'll be...

I am aware that MySQL does not have a boolean type. However, using 0 for false and 1 for true seems to be reasonable, as the `:cast_booleans=>true` setting returns 0...

Correct. Maybe true/false should only be handled if the client has `:cast_booleans=>true`, but I wouldn't have a problem making it unconditional.