updated with video
Originally, I attributed this to sorting, but @WhiteNoise clarified that there is no mtime sort.
So I’m relabelling this as a bug. With the additional info, I realize this may be a bug in the render process that is moving the row to a new position when the sorting should have otherwise kept the row in a stable position.
Here is a video showing the issue:
original
Use case or problem
When I edit front-matter directly in a Bases table, I need the active row to stay in place so I can move quickly through a set of notes. At the moment, Bases implicitly adds a secondary sort on modified time whenever any other column is sorted. As soon as I make an edit, the note’s mtime changes, the implicit sort re-evaluates, and the row jumps to a new position. This breaks my flow and makes bulk editing or triage work much slower. If I remove all sorting the jumping stops, but then I lose the ability to keep high-priority items at the top or group by a key field.
Proposed solution
Provide an option that disables the automatic secondary sort on modified time whenever the user specifies an explicit sort column. Possible approaches:
- Global setting: a toggle in Bases settings such as “Add implicit modified time sort when other sorts are present.” Off by default would keep row order stable.
- Per-view override: an advanced toggle in the sort menu for each table view so users can opt in only where needed.
Either choice would let users keep a stable view when editing while retaining the power of sorted columns.
Current workaround (optional)
The only reliable workaround is to remove all explicit sorts, effectively working in unsorted mode. This keeps rows from jumping but sacrifices the ability to surface priority items or group by folder.
