Add Clone+Debug derives to vte::Parser

[zhiburt]

I wonder whether it's reasonable?

Take care.

[chrisduerr]

Is this something you actually need? While adding these isn't necessarily bad, I don't see why someone would need to use them.

[zhiburt]

Just for cases where you incorporate it into other structures which is necessary to Clone.

As far as I understand it won't hurt as it won't be compiled if not used.
Therefore no footprint.

But if it the change will be made; it is not urgent (at least for me) so it can wait a future release.

[nixpulvis]

I mean, if you don't need to clone the parser, you can always implement Clone yourself and just skip that part (initialize a new parser). The real question is if you need to preserve the state of the parser, and what value cloning the parser actually has.

As for Debug, I generally think everything should implement this in one form or another unless there's a good reason not to.

[zhiburt]

The real question is if you need to preserve the state of the parser, and what value cloning the parser actually has.

Exactly;
That's why it's impossible to implement Clone in client code, once parser was used.

As for Debug, I generally think everything should implement this in one form or another unless there's a good reason not to.

Same

[chrisduerr]

As far as I understand it won't hurt as it won't be compiled if not used.

That's not entirely accurate because you're still dealing with the compilation overhead. It's effectively compiled and then removed again. It also makes it much easier to accidentally use it.

As for Debug, I generally think everything should implement this in one form or another unless there's a good reason not to.

Well the automatically derived impl certainly isn't the way to go, that'll just spill out a bunch of internal details that won't make sense to anyone. I don't see what useful information we'd provide in debug logs for the parser.

You still haven't answered my question though. What motivated this pull request? Adding it without actually needing it for yourself would just make this patch a bunch of unnecessary noise.

[zhiburt]

That's not entirely accurate because you're still dealing with the compilation overhead. It's effectively compiled and then removed again. It also makes it much easier to accidentally use it.

True

What motivated this pull request?

Well...
I was just wanted to do .clone() 😅
In my particular case 2 calls vte::Parser::new works.
But you know it's sort of "code smell" - "duplication".
And if everybody got to deal with it maybe just adding Clone is a better option.

Specifically clone a structure which holds vte::Parser underneath.

https://gitlab.com/zhiburt/ansitok/-/blob/master/src/parse/ansi_parser.rs?ref_type=heads#L12

Either way it just something I wanted to point out.
In all essence it can be closed if it does no make sense.

Take care.
*And thanks for the library

[chrisduerr]

I was just wanted to do .clone() 😅

That's all I wanted to know, whether this was motivated by an actual implementation or just changed for the sake of changing things.

It's certainly useful to have this for testing, so I don't think it's a bad idea to add it. Though the debug derive probably should be different.

[chrisduerr]

We should implement all the standard traits that are useful to potential consumers:
https://rust-lang.github.io/api-guidelines/interoperability.html#types-eagerly-implement-common-traits-c-common-traits

I think eq/clone would probably be useful for testing. Ord/Hash shouldn't be necessary.

Debug doesn't seem relevant, I don't see how we'd provide a useful debug implementation for it that doesn't just dump a bunch of internal state that can change at any time.

[nixpulvis]

Nobody should be expecting Debug information to be a reliable API. It's more for... well, debugging. Which I do think "leaking" internal state is perfectly reasonable to do. If we can clean up the format to be more useful, then that's great, but I don't see an issue with the derived one personally.

[chrisduerr]

Which I do think "leaking" internal state is perfectly reasonable to do.

That internal state has no information that is of use to consumers though and none of it is accessible to them in any other way. It's basically just arbitrary data that has no clear meaning to library users. Littering that out to a debug implementation doesn't help anyone.

[nixpulvis]

I suppose I see what you mean.

It may be worth putting a little thought into what might actually be useful to users while debugging their use of the parser tho. Like how far into a sequence they are, state machine information, etc.