Rework stop markers/labels to be more manual

[zyxw59]

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.

[zyxw59]

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.

[zyxw59]

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?

[zyxw59]

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.

[zyxw59]

Not sure what the syntax should be. Some challenges:

• Delimiting the location (which should just be an expression) from the marker parameters
• Marker parameters are going to be different based on which marker is being used
  • Some markers (e.g. a label) might have string parameters, but currently the Expression type can only resolve to a number, point, or line, so we can't just parse a list of Expressions

---

A 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;

[zyxw59]

Maybe I should add a string type. Maybe also write a format function while I'm at it…

[zyxw59]

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 &strs) or change everything that relies on Copy to instead clone it…

[zyxw59]

Okay that wasn't too hard (#12). Now I can actually start working on something like the syntax I described above.

[zyxw59]

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

[zyxw59]

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.