Allow user defined scanners.

[kevincox]

It would be nice to be able to specify scanners without modifying command-t's source. For example a locate based scanner would be useful. Or someone might want to have a git ls-files -co scanner rather then the default git scanner.

Most commands output one file a line or files separated by null bytes. It would be nice to have a scanner (or one per split) that take a command to run and get results by splitting on nulls or newlines.

A nice benefit is that the find scanner can use it :)

[wincent]

Agreed that this would be nice. Ideally, the existing scanners would be refactored so that they behaved like third-party plug-ins rather than being baked into the source (they'd still be bundled, for convenience, but have them operate via the same API that any third-party plug-ins would need to use would be the way to keep the API "intellectually honest").

[kevincox]

Sounds good. In fact if I start work on #249 I might do it in such a way that a custom scanner can be provided in addition to the find and git ones.

[wincent]

Given the big rewrite for v6.0.x, I'm closing all older issues as there is unlikely to be anything significant happening on the 5-x-devel branch from here on¹. Feedback issue for 6.0.x is here:

• 🆕 Command-T 6.0.0 release — compendium issue #393

Footnotes

1. Patches and PRs would be welcome, but my personal efforts are going to be directed towards main. ↩