feat: Plugin support

[j-xella]

OK, maybe this is a wishful thinking which is waaaaaay out of what eza is supposed to do. But let me dream ....

Somehow, a plugin configuration is provided to eza that consists of these parts:

• long option name (must not clash with other names)
• optional, short option name (must not clash with other names)
• does option have a value?
• column header name
• executable name (and possible arguments) that accepts a list of file system objects on stdin (one per line, zero-separated ???) and for each file prints to stdout some info
• optional, what kind of file system objects this plugin can be applied to (files, folders, symbolic links, pipes, etc...)
• optional, timeout ?

Many plugins can be defined as above at the same time, as long as their names do not clash.

If user calls eza with short or long option name as defined above, then for each file system object eza calls the executable above, and prints the returned values in the appropriate column.

Now, obviously using plugins could take a performance hit, and users must be aware of it. But eza must try and minimize it:

• run several plugin executables in parallel, where possible. Maybe additional option for that, something like max-threads?
• re-use the same instance of running plugin instead of spawning new processes
• Start invoking plugins before all file system objects are read
• timeout on plugins after a while

[tertsdiepraam]

Not sure how relevant it is to mention a completely different tool in this repo, but you might like nushell. For example, I just wrote this little command that adds a line count to every file from ls (it generates some warnings, but that's fixable):

~/code/eza> let one = ls; $one | insert "lines" {|l| wc -l $l.name | parse "{n} {name}" | get n.0 }                                                     16-05-24 14:12:13
╭────┬─────────────────────┬──────┬──────────┬──────────────┬───────╮
│  # │        name         │ type │   size   │   modified   │ lines │
├────┼─────────────────────┼──────┼──────────┼──────────────┼───────┤
│  0 │ CHANGELOG.md        │ file │ 34.5 KiB │ a month ago  │ 1618  │
│  1 │ CODE_OF_CONDUCT.md  │ file │  5.4 KiB │ 2 months ago │ 136   │
│  2 │ CONTRIBUTING.md     │ file │  7.9 KiB │ 2 months ago │ 181   │
│  3 │ Cargo.lock          │ file │ 41.1 KiB │ a month ago  │ 1613  │
│  4 │ Cargo.toml          │ file │  3.1 KiB │ a month ago  │ 144   │
...

It's fairly easy to define a new command ls-lines or something that does this.

It serves a bit of a different purpose from eza, but if you need a tool where you want ls but enriched with your own data, it might be worth looking into. You can also do your own filtering and other computation. Not as pretty as eza though :)

[cafkafk]

Another option may be to one day support nushell "natively", so we can get nice columns and stuff when run in nushell, I think @PThorpe92 looked at it at some point, but IIRC it would require a lot of work. I do know there exists some snippet in the nushell discord for converting eza output to something nushell understands FWIW.

[cafkafk]

It would be nicer to offload this to the shell rather than us having to maintain a plugin system, also from like an ecosystem perspective, it seems more reasonable to have some universal language rather than over-specializing every single binary.