What happens
Below a frame width of 110 cells the tasks list draws no side pane, and with no pane the answer keys the pane offers are not bound. taskPaneCols returns zero under the floor, taskPaneOpen reports false from it, and taskPaneKey returns early on !a.taskPaneShowing(), so a digit that names an answer does nothing from the list.
What is NOT wrong, checked before filing
The answer road still exists at any width. enter from the list opens the record card, and the card reaches the same door (taskRecordAnswer) that the pane reaches, by the comment's own statement that a second loop over the options there would be a second chance for the two to disagree about what 1 means.
So this is one extra keystroke on a narrow terminal, not an unanswerable question. An earlier reading of this as "the page has no door below 110 columns" was wrong and is corrected here.
Why it is still worth deciding
- The verb line that advertises the keys is drawn by the pane, so on a narrow frame a person is not told the shortcut is unavailable; it is simply absent. Nothing says "press enter to answer".
- Nobody has established whether the record card itself renders usefully below 110 cells. That is unverified and is the question that decides whether this is cosmetic or real.
The decision wanted
Either: accept the floor, and make the narrow list say how to answer, so the absence is announced rather than silent.
Or: bind the answer keys on the list itself at any width, so the shortcut does not depend on a layout choice.
The first is smaller and consistent with the floor's stated reasoning, which is that under 110 cells a split buys a preview by making the thing previewed unreadable.
Replication
NOT YET RUN. Recipe a stranger can execute: open the tasks place in a terminal narrower than 110 columns with a row whose work is waiting on an answer, and press the digit the wide frame would accept. Then press enter and the same digit on the card.
Acceptance
End to end, at a frame under the floor: the list either accepts the answer key directly, or draws a line naming the key that does. Asserted on the real surface, not on a width helper.
What happens
Below a frame width of 110 cells the tasks list draws no side pane, and with no pane the answer keys the pane offers are not bound.
taskPaneColsreturns zero under the floor,taskPaneOpenreports false from it, andtaskPaneKeyreturns early on!a.taskPaneShowing(), so a digit that names an answer does nothing from the list.What is NOT wrong, checked before filing
The answer road still exists at any width.
enterfrom the list opens the record card, and the card reaches the same door (taskRecordAnswer) that the pane reaches, by the comment's own statement that a second loop over the options there would be a second chance for the two to disagree about what1means.So this is one extra keystroke on a narrow terminal, not an unanswerable question. An earlier reading of this as "the page has no door below 110 columns" was wrong and is corrected here.
Why it is still worth deciding
The decision wanted
Either: accept the floor, and make the narrow list say how to answer, so the absence is announced rather than silent.
Or: bind the answer keys on the list itself at any width, so the shortcut does not depend on a layout choice.
The first is smaller and consistent with the floor's stated reasoning, which is that under 110 cells a split buys a preview by making the thing previewed unreadable.
Replication
NOT YET RUN. Recipe a stranger can execute: open the tasks place in a terminal narrower than 110 columns with a row whose work is waiting on an answer, and press the digit the wide frame would accept. Then press
enterand the same digit on the card.Acceptance
End to end, at a frame under the floor: the list either accepts the answer key directly, or draws a line naming the key that does. Asserted on the real surface, not on a width helper.