v1gnesh

Any thoughts, @jam1garner, @csnover @octylFractal ?

Any further thoughts on this, @sharksforarms? Perhaps a `.conf` file with global settings?

Could you show me an example of such a crate/project please?

Hi @sharksforarms & @wcampbell0x2a, check these out. `nom`'s declarative parser seems to be catching up. [nom-derive-impl/src/config.rs](https://github.com/rust-bakery/nom-derive/blob/5315891a0016b15094d4d0201f7d3ac803e4fc57/nom-derive-impl/src/config.rs) [Overriding the default endianness](https://github.com/rust-bakery/nom-derive/issues/14) This will cut my boilerplate noticeably.

Thank you. As I had mentioned, I'm a noob at programming, barely capable of *using* this library. It'll take me a long long time to get comfortable enough to work...

Apologies in advance if what I'm about to say makes little sense. I'm a pretty basic programmer... If you have time, can you please help me understand how I can...

> I think I'd like something even more general though - ideally I'd want to be able to define custom parsers for built-in types (e.g. LEB128 for integers, custom parser...

That's great to hear, thank you! Please conisder scenarios from both #217 and #213, i.e., - `.conf` file to put project-wide settings - `struct`/`enum`-wide setting, but filterable (to specific types...

> Not sure I'm in favor of a default map function, it would only be able to accept a single type? Yes, ideally configurable in a top-level setting such as...

Keeping it general... Top-level functions: `map` - works as it currently does. `map_types` - apply `map` on these types `map_fields` - apply `map` on these fields `map_sizes` - `bits`/`bytes` of...