Maintain line information for each field for semantic error reporting?

[epage]

committed offers additional error checking than style. It might be helpful for when we do this if the parser could maintain line information so we can report that line information back to the user.

Related to #7

[JeanMertz]

Could you give some more concrete details on what you'd envision using this for? When you talk about fields, do you mean type, scope, body, etc?

So in reality, all of those would be line 1, except for the body, which would start at line 3 (the only variable line would be the start of the footer)?

Or, do you mean you'd like for the body to actually be a vector of strings, each representing a line? But then what's the added value over body().lines(), since body() already returns a string with newlines preserved?

I get why #7 is useful, because we're dealing with unparsed data there, so you might get strange cases like:

feat(my scope):
    description

In which case you want to be able to point to line 3, column 5 as a potential error, but I don't get the use case for after parsing succeeded.

I guess I'm not really clear on what you actually want here 😅.

[JeanMertz]

I've pushed an experimental change which doesn't solve this issue yet, but makes accessing this information nicer with the new API.

You can check it out here: fff9608

The README has also been updated to show the difference between the Simple API, and the Typed API.

At some point, I envision doing something like this:

use conventional::{Commit, Scope, Typed as _};

let commit = Commit::new("feat(my scope): my commit").unwrap();
assert_eq!(5..13, commit.scope().span().columns);

I'm not 100% sold on the new API yet, but I do like its usage, as I would like to keep the an easy way to just parse/validate the commit, and get its components as string slices, if you don't need any other fancy access.

In theory, you could implement Deref on the component types (it already is), always return the specific component types, and not have to import either the Simple or Typed trait, but that still leaves you with a less-than-ideal API surface area, such as:

assert_eq!("my scope", &**commit.scope());

[epage]

So in reality, all of those would be line 1, except for the body, which would start at line 3 (the only variable line would be the start of the footer)?

Yes, technically I could guess for the starting line for subject and body. I'll also be doing validation on the footer thoug.