Closed zyxw59 closed 1 year ago
One thing that might be useful would be a way to specify an offset on a line. We could reuse the syntax used for defining routes: point_a --(1) point_b
.
But that has the complication that it's ill-defined until after routes have been defined (since the width of a given offset depends on the routes along a given segment).
Also, what happens if the width of the given offset isn't the same at all points on the specified segment?
Probably the answer to both of those is to throw an error when it's poorly-defined.
Oh, but there isn't actually a way for the program to know when all the routes have been defined… Maybe we should make the "route definition" and "stop definition" sections explicit, and not allow defining routes/stops outside of their respective sections?
Or maybe just allow it everywhere, using the default line_sep
if necessary, and if the relevant widths change later, don't worry about it; the point stays at its initial definition.
Not sure what the syntax should be. Some challenges:
Expression
type can only resolve to a number, point, or line, so we can't just parse a list of Expression
sA potential syntax:
stop<.styles> <location> marker <marker name> <marker parameters>;
So for example
stop.terminus (a --(3) b) & (c -- d) marker text "Last stop" 45;
Maybe I should add a string type. Maybe also write a format
function while I'm at it…
Oh boy, adding a string type is complicated because Value
is currently Copy
, so I'd need to either add a lifetime (to use borrowed &str
s) or change everything that relies on Copy
to instead clone
it…
Okay that wasn't too hard (#12). Now I can actually start working on something like the syntax I described above.
oh hmm, that --(x)
syntax would have to be special-cased into the parser. But I could maybe add a syntax for offsetting a line… something like a<>b ^^ 3
oh but also binary operators as they currently work don't have access to the evaluation context (and therefore line_sep
and related info). Maybe it can just operate in real units. That at least makes it possible to put things at non-integer offsets etc.
Figuring out how to programmatically place stop markers and labels has been basically the #1 blocker for all eternity, because it's a really hard problem with a million edge cases that requires serious graphical design thinking. Making it more manual will require a bit of design work for new syntax, and it will put more work on map designers to place markers and labels, but a tool that's hard to use is better than one that doesn't work at all.