Line- or column-major APIs
Should the Tickit APIs that take/return position information be ordered as (line, column) or (column, line)?
While line-major is traditional for terminal systems, other graphical systems all tend to use column-major ordering.
A change at this point will be potentially quite disruptive as there's no easy way to isolate users from it by versioning or function names, as it spills out into structs as well.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Paul "LeoNerd" Evans
- Direction:
- Needs approval
- Assignee:
- Paul "LeoNerd" Evans
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
I'm much in favour of keeping the order as it is now (line, col), as there's already IMHO far too much precident set for this order. -- LeoNerd
Graphical toolkits tend to use (x, y) which is how 2D coordinates are usually represented, so switching to (col, line) will be consistent with that. OTOH (line, col) feels more naturial to represent terminal positions, at least for me(I always look for the line first when searching). -- tarruda
A third option of course is to pass two-element (int, int)-structs around the place.
typedef struct { int line, col } TickitPos; and then possibly even retain ABI-compat with the existing code. -- LeoNerd
