Remember last visited paths over (server) restarts

[dumblob]

One of the killer features of ranger, lf and similar file managers is, that they remember the selected file/dir after leaving dirs (i.e. going up in the file system tree hierarchy) and then when opening these dirs, they preselect the last selected file/dir.

Unfortunately this feature is not persistent over restarts, which makes it way less useful as one usually alternates between shell and lf while working.

In lf there are 2 "levels of persistence" to consider.

1. Save this history server-side (i.e. all running clients will immediately send each record upon any change to lf server) for each client in it's own bucket. All history buckets will be merged (in case of a conflict the most recent record wins) to a "common" history and this then sent automatically to all newly opened lf clients and on-demand/manually to already running clients.

2. Save the history buckets from 1. to a disk to allow persistency over lf server restarts (very convenient for unexpected logouts, crashes, etc.).

Technically are both points slightly inspired by some ideas used for ShaDa (Shared Data) from the Neovim project.

[gokcehan]

@dumblob Currently each client have it's own index and position for each directory they visit. If I understand you correctly, what you're suggesting implies merging these into one or otherwise it wouldn't be possible to determine something for the new clients. I'm not sure if this is always desirable and also if it's possible at all. For instance, what will happen if two clients are on the same directory and one of them moves up or down. Shall the other one move with the other then? Or when two clients have the same ancestor a few levels up in the directory hierarchy which by the way is always the case if you consider the root directory. What will be the common index/position then? Even in vim you can display the same file with different cursor positions in multiple windows although semantics of a text editor is not very comparable to a file manager. Also note that vim/nvim does not have proper server/client architecture and a file is expected to be opened only by a single client.

May I suggest trying to spawn a shell from inside lf (e.g. $bash) and then drop back to lf with a shell exit command (e.g. <C-d>) if you're alternating frequently. This way you will have the same selected file when you get back to lf.

[dumblob]

If I understand you correctly,...

Fortunately not ;)

First, the idea is to leave the functionality as it is right now with regards to the path index. The only difference (but technically a substantial one) is, that the indexes will not be stored in clients, but on the server. Each index record will have a monotonic time stamp. Now comes the news. Namely, newly connected clients won't start with an empty index, but rather with an index made up by copy-merging all the existing indexes on server (if there is an ambiguity, the index record with newer time stamp wins). Additionally to not make already running clients miss out on something, there will be new command swaphistoryformergedone (of course should be shorter 😉), which can any running client run at any time and which will instruct the server to create a new empty index, copy-merge all the existing indexes to this one (with record time resolution as described above) and exchange the old index of the requesting client with this newly created copy-merged one.

Hope this clarifies the intention a bit.

May I suggest trying to spawn a shell from inside lf (e.g. $bash) and then drop back to lf with a shell exit command (e.g. <C-d>) if you're alternating frequently. This way you will have the same selected file when you get back to lf.

This will cover just about 20% of my use cases, where the history synchronization as described above will be used.

[gokcehan]

I'm reading this again and some of the things are not clear to me, specifically the case where there are multiple clients with different indexes on the same directory. Also the intention here does not seem to justify the additional complexity introduced. With the new select command, it may still be possible to implement this feature using shell commands on launch and exit. I am closing this issue since there is no active effort to implement this. Feel free to add comments if a new idea comes up.