FarGroup
Feature request -- add Far CLI parameter -ro-localconfig
Feature request -- add Far CLI parameter -ro-localconfig
Description
If the parameter -ro-localconfig is specified then Far does not save data to localconfig.db.
Problem
My workflows often require several Far instances, where one is usually the main (opened for longer time) and the others are temporary (usually opened from the main for some quick side jobs).
The problem. The main Far sometimes exits when a temp Far is still open. Then, when the temp Far exits it saves the current panel paths to localconfig.db. These paths may be different from where we left the main Far. When the main Far starts it reads localconfig.db saved by a temp Far and shows unexpected and unwanted panel paths and some time is lost for restoring the resumed job context.
Solution
If temp Far instances are started with the suggested switch -ro-localconfig then the problem is solved, they do not affect the main Far data stored in this file.
Why /ro is not enough
I need all the other history shared, literally everything. E.g. if I add or arrange folder shortcuts, type new commands, create file associations, filters, etc. etc. Even shared file history may be useful in the main Far. This is all needed and should not be lost with /ro.
@HamRusTal Indeed, I should have mentioned that, updated the description.
I need all the other history shared, literally everything. E.g. if I add or arrange folder shortcuts, type new commands, create file associations, filters, etc. etc. Even shared file history may be useful in the main Far. This is all needed and should not be lost with /ro.
How about using a different local profile path for the temp instances, where all the files except localconfig.db are symlinks to the files in the local profile path of the main instance?
@bitraid I have already tried several workarounds including this particular. Nothing works really well and requires a lot of not quite trivial work to organize, too. I came here after the long discussion at Telegram.
E.g. how do you symlink required (for avoiding corruption and data loss) db files *.db-shm, *.db.wal? These files may exist or not, they are temporary. Simlinks may point to missing files, this can be done. But if they are missing at some point (main Far exited), then temp Far has issues.
You can pass -set:System.AutoSaveSetup=false to additional instances.
The config will still be writable, but saving the state would be a deliberate decision.
You can also start the main instance with some predefined paths if that's so important.
In general, -ro-localconfig seems like overkill. localconfig could contain other (potentially useful) parameters, not only panel paths. Maybe we should just add something like "[x] remember last folder" to panel settings.
@alabuzhev
You can pass -set:System.AutoSaveSetup=false to additional instances.
But I need auto save, like I said. I need live shared history, e.g. new commands, file history.
Maybe we should just add something like "[x] remember last folder" to panel settings.
This might work, do I start temp instances with this option disabled, using set:?
[x] remember last folder
Just in case, all 5 settings should be not saved (2 paths + 2 current items + 1 left panel active)
AutoSaveSetup way is not ideal. One needs to remember (easy to forget and lose useful data). And on saving localconfig is updated again. So this does not actually solves much, only adds new issues.
Generalizing just a little, this problem looks like yet another manifestation of the issue that has been raised multiple times over FAR history. Namely, FAR does not make a difference between Settings/Options and Session state, so users have no way to control separately when those are persisted. I'm with those who tend to consider panels state (active/passive state, path, current item, selected items, size, panel mode, sort modes) part of Session state. If Session state gets separated from Settings/Options the right way, those who do not need it will still be able to persist both at the same time.
@HamRusTal I'm totally with you on that matter. I was involved in these discussions long time ago. I'd like the state of panels to be separated (including visibility of panels and their items, too).
In theory, such state data could be persisted in this exact localconfig.db, in addition to existing now.
Then my suggestion (or more generic, say /ro-state) would work nicely by not saving this database.
BTW, I have one practical personal way to know what "state" is for me and what is "setting".
Namely, I regularly backup my settings by far /export and keep these files in git.
What bothers me, often these files are only different due to panel property changes.
I do not want them in my settings repo. And that is my practical criteria of "state" :-)