panicbit

I've actually started building an implementation in Rust, so I might as well write a spec while I'm at it.

Moving the spec to FLIF-doc sounds fine. I'd prefer PRs since having a review of the spec doesn't hurt.

I'm currently working on a pure Rust decoder/encoder https://github.com/panicbit/flif-rs

It's definitely not related to my changes. I've checked against a sufficiently old commit. I'm checking with a bisect how this got introduced (tho I fear this might have been...

``` $ git bisect skip There are only 'skip'ped commits left to test. The first bad commit could be any of: e4c512e33d81e8fb0edfa56acd4f9ac12d04891b 121e8678b6d5d8551acf8e39d1af566614302eeb 81df42d63b6097c6c73fc49202a710846531659e 6802a4ee2109b12167e83a44997ff3b5cb292598 f85a1d003c22ea06aee2f6bb30f7bbb71ea1df1c 3676a8a48d2fe32c1800728a54bddae540a32175 c0ce78f892b35bf79c29312b40ee556ba1e8be37 221f36ca65a75f50c3886814db10916ae3f68dbd b7d3623e5313c7988c967c6a78f8abe69865d4b3...

Actually, seems like I might have just been unable to compile those due to running out of disk space... so maybe it's not actually related to `tabled`. I'll look into...

`help commands | find in` seems to show the same issue

I think it's actually related to `tabled`: Try piping into `to json` or get an an individual affected record to show. The output will be correct!

Or simply: `help commands | find in | get usage`

My final proof: ``` help commands | find in | each {{a: $in.usage, b: $in.usage, c: $in.usage}} ```  @fdncred The observation with only one column being affected was crucial!