This is a good ticket, thank you! It probably depends, alas, on some long-planned reworking of the repainting/scrolling code.
The hard cap for truncation is currently there so that each on-screen element (the chrome, timer, the grid, the clues, the feedback box, and the controls) are in fixed and assigned spots on launch. Really ideally it would be able to expand each of those dynamically, and handle overflow as necessary. (In addition to requiring a rewrite, it raises some questions... like, would scrolling through a long clue use the same keys as scrolling through the grid, if both have scrolling logic? Does that require the introduction of some kind of "focus" mechanism?)
This is a good ticket, thank you! It probably depends, alas, on some long-planned reworking of the repainting/scrolling code.
The hard cap for truncation is currently there so that each on-screen element (the chrome, timer, the grid, the clues, the feedback box, and the controls) are in fixed and assigned spots on launch. Really ideally it would be able to expand each of those dynamically, and handle overflow as necessary. (In addition to requiring a rewrite, it raises some questions... like, would scrolling through a long clue use the same keys as scrolling through the grid, if both have scrolling logic? Does that require the introduction of some kind of "focus" mechanism?)
In any case I appreciate you logging this here!