When a List Becomes a Live View
A list becomes a live view when its source can change while a person remains inside the same fzf session. This chapter focuses on the lifecycle decisions that follow: whether updates should appear immediately or only after completion, how memory is bounded for endless input, and how focus or selections can survive a changing candidate set. The practical result is a way to choose live-data behavior deliberately and to recognize when fzf is ranking an upstream search rather than performing that search itself.
Reload changes the meaning of selection
In a static list, selection has a simple reference: the person chooses one record from the set that was loaded. A reload breaks that assumption. The source may return a different set, the chosen record may move, and the query may be evaluated against records that were not present a moment earlier. Keeping fzf open is easy; keeping the meaning of the person's position coherent is the real problem.
The reload action starts a new producer command and updates the candidate list without closing the interface. It is useful for a process list that needs a refresh key, a directory view that can switch sources, or a search command that should run again after the query changes. The new producer may emit records incrementally, so fzf can begin searching the new stream before it ends. That favors freshness and responsiveness, but the visible list can represent an intermediate snapshot rather than a final answer.
reload-sync makes a different promise. It replaces the current list only after the reload command has completed. The old list can remain available while the new producer works, and the new result becomes the basis for interaction as one complete replacement. That avoids showing an empty or partially built list when the producer takes time, but it also delays the update. Neither action is universally safer. The choice depends on whether a person benefits more from seeing new information early or from making a decision against a stable set.
The same trade-off appears in an endless stream. A log reader can keep sending records indefinitely, but retaining every record would make memory grow with the stream. --tail limits the number of items fzf keeps in memory, making interactive browsing of a long-running source possible within a chosen retention window. The cost is explicit: records that fall outside that window are no longer available for selection. A user who needs historical coverage must keep that history in the producer or another store; fzf's bounded view is not an archive.
Focus creates a second lifecycle problem. If the current item is simply tracked by its position in an input list, a reload that inserts, removes, or reorders records can point the cursor at a different object. With --track, fzf can preserve the current selection while a result list is updated, which is useful for changing views and unsorted logs.