New Note Form Footer Advertises Pick Keys That Do Nothing #932

• Type: Bug
• Severity: Low

Environment

• OS: Linux
• WM: Niri
• Compositor: Wayland
• Software version: 2.66.0

Description

The New note form opened from the create row in Search Notes shows a footer reading ↑↓ pick, ↵ create and esc back. The form presents three fields — Name, Folder and Tags — so the hint reads as though ↑↓ moves between them.

It does not. ↑↓ and its Ctrl+N / Ctrl+J / Ctrl+K / Ctrl+P equivalents only ever move within the list rendered underneath Folder or Tags. Moving between Name, Folder and Tags is done with Tab alone, and Tab is not mentioned anywhere in the footer.

The footer is also shown before any list exists. The form opens with focus in Name, where there is no list under any field, so the hint advertises a capability that has nothing on screen to act on.

Steps to Reproduce

1. Open the Search Notes palette with Ctrl+P.
2. Type a query that matches no existing note.
3. Move to the create row and press Enter to open the New note form.
4. Read the footer. It shows ↑↓ pick.
5. Press ArrowDown while the cursor is in Name.
6. Observe that nothing moves and nothing is selected.
7. Press Tab to move to Folder.
8. Observe that focus moves to the next field instead, confirming that Tab is the field-level navigation.

Expected Behaviour

The footer should describe the keys that work in the field that currently has focus.

• In Name, where there is no list, it should offer ↵ create and should say that Tab moves to the next field.
• In Folder or Tags, when a list is shown, it should offer ↑↓ pick and ↵ choose.
• It should not offer ↑↓ pick when no list is rendered.

Actual Behaviour

The footer is static and always shows ↑↓ pick, ↵ create and esc back, in every field and regardless of whether a list is on screen.

↑↓ does nothing in Name. It moves only within the list under Folder or Tags, and Tab is the only way between fields.

↵ create is also wrong while a list row is highlighted: Enter picks that folder or tag instead of creating the note.

A second, sharper case went unreported: in Tags, arrowing the highlight off the only row returns the footer to ↵ create, but Enter at that point commits the typed tag as a chip rather than creating the note. The same word was covering three different actions.

Why The Hint Misleads

Two separate decisions combine.

The list of choices is conditional, but the footer is not. The folder and tag rows render only when there is at least one row, and the Name field produces neither a folder list nor a tag list, so on arrival there is no list anywhere in the form.

The ↑↓ in the footer is scoped to those rows, not to the three fields. The wording pick does not say what is being picked from, and the form's only other pickable things are its fields.

The hint therefore becomes true only after Tab-ing to Folder or Tags, by which point it has already been shown once while untrue.

The Name field's key handler has no palette-navigation branch at all, which is correct on its own terms — there is no list to move through — but it means the advertised keys are inert there rather than absent.

Suggested Behaviour

Make the footer reflect the focused field, rather than adding ↑↓ handling to the fields.

• Show tab next field in every state, since Tab is the actual field-level navigation.
• Show ↑↓ pick only when Folder or Tags has focus and its list is rendered.
• Name the ↵ action rather than the field, so create is never ambiguous between adding a tag and creating the note.
• Omit the ↵ hint entirely when Enter would do nothing, which happens in Tags when the typed text is not a valid tag.

Shift+Tab walks the fields backwards and is also worth advertising, but the footer is already at its widest in the list states and wraps on a narrow window, so that is left as a separate call rather than bundled in.

Making ↑↓ move between fields instead was considered and rejected. Inside Folder and Tags those keys are already the standard combobox behaviour for moving through options, so overloading them at the field level would conflict with the list they are needed for.

Additional Notes

• No functional loss: every action the footer describes is reachable, and the misleading entries are the two that do nothing or do something else in the focused field.
• The footer is not hidden on touch devices the way other palette footers are. It carries an explicit data-keyboard-hints hook instead, because it also holds the Back and Create buttons, so the rule that hides every other palette footer cannot be allowed to match it.