debug: Tag debug shapes

[johannes-wolf]

Tag debug paths as such and skip them in merge-path.

Debug shapes bring other problems, maybe we should remove the feature or remove documentation about it.

Fixes #575

[fenjalien]

This is would also resolve #463 if you used the ignore key instead

[johannes-wolf]

They are different. Marks must be considered for bbox calculation and intersection (?), debug shapes not. Although, this is not yet implemented in this PR.

[fenjalien]

I don't think marks should be considered for intersections and would they be big enough to really count towards a bounding box?

Besides that, if we do have separate keys for debug, marks, hidden and ignore, would there be a way to combine them into one field? Maybe a "type" or "class" key that holds "debug" or "mark", it could even be an array to hold multiple if needed. It could even be a bytefield...
We'll be needing something similar for modifiers anyway.

[johannes-wolf]

I don't think marks should be considered for intersections and would they be big enough to really count towards a bounding box?

Besides that, if we do have separate keys for debug, marks, hidden and ignore, would there be a way to combine them into one field? Maybe a "type" or "class" key that holds "debug" or "mark", it could even be an array to hold multiple if needed. It could even be a bytefield... We'll be needing something similar for modifiers anyway.

Yes, I think some kind of "class" is good. We could then provide a function for filtering out certain elements.
Maybe just a tags list of strings/ints?

[fenjalien]

If we are still aiming for modifiers in 0.3.0, can this be blocked until modifiers are implemented? Then we can use whatever system works for modifiers.

[johannes-wolf]

If we are still aiming for modifiers in 0.3.0, can this be blocked until modifiers are implemented? Then we can use whatever system works for modifiers.

Yes. Although path-replacing modifiers need no special handling, as they just replace the original path.