Remember last visited paths over (server) restarts about lf HOT 3 CLOSED

@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.

from lf.

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.

from lf.

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.

from lf.