Closed FloatingSunfish closed 3 years ago
I'm really reluctant to add filtering back into the init phase. I know that keeping the filters separate from init adds an extra step, but in practice people just create shell scripts (or batch files) that run init and the filters they want. I'd prefer that all filters continue working on equal footing, rather than having some filters have special, built-in status.
I'll try to be receptive to arguments in favor of building certain filters into the init phase. I'd also consider some mechanism by which arbitrary filters could be run after init. But mostly I'd prefer that init stay "primitive" and filters stay separate.
@abingham Noted on this. Perhaps now isn't the time to do this for filters.
Also, now that I re-read the docs, I do see an entry in the Filters section where a Batch File is recommended to be used.
Currently, you need to run
cr-filter-pragma your_session.sqlite
after aninit
in order to exclude code marked with# pragma: no mutate
comments from mutation.My proposal is to make
cr-filter-pragma
part of the configuration file to make it easier to use and more in line with other filters in the config file:e.g.
This way, you only have to deal with it once and never have to run it as a command ever again.
@abingham UPDATE: After our recent discussion on #522, I'm still hoping that this could get added since I assume it would just be a simple check in the config and doesn't involve anything as complex as excluded operator mutations. Do let me know your thoughts on how complex this would be though.