On Windows, Configuration should be located at AppData\Roaming, Not AppData\Local

[Bip901]

The canonical equivalent of Linux's ~/.config on Windows is %APPDATA%, whereas ~/.local corresponds to %LOCALAPPDATA%.

However, while correctly using ~/.config on Linux, lf stores its configuration in %LOCALAPPDATA%\lf on Windows, which means it doesn't roam when logging in on other physical machines in the same network.

[CatsDeservePets]

I do agree. On Windows, it is a complete mess.
nvim, lf, ... use AppData\Local
eza, bat, ... use AppData\Roaming
wezterm uses .config\wezterm
Some tools use ProgramData, some use the registry...

I the case of lf, you can either set the env var LF_CONFIG_HOME or use the -config flag.
Personally, I just accepted that Windows is an inconsistent mess with only so much one can do about it.

[joelim-work]

There are a number of files that are read/managed by lf:

• lfrc (config file)
• colors (color configuration)
• icons (icon configuration)
• files (clipboard for cut/copy)
• marks (stores bookmarked directories)
• tags (stores tagged files)
• history (command history)

The first three are configuration files, and should be stored in a config directory (e.g. $XDG_CONFIG_HOME). The remaining files store persistent application state, and should be stored in a data directory (e.g. $XDG_DATA_HOME).

On Unix systems, this is fairly straightforward, but for Windows all the files are just stored in a single local directory (e.g. %LOCALAPPDATA%). From what you're saying, it sounds like using %APPDATA% is ideal for sharing configuration files, so I don't mind moving those three files (lfrc, colors and icons) there. At the same time this means Windows can support $LF_DATA_HOME too since the layout of these files is now similar to Unix.

[Bip901]

From what you're saying, it sounds like using %APPDATA% is ideal for sharing configuration files, so I don't mind moving those three files (lfrc, colors and icons) there. At the same time this means Windows can support $LF_DATA_HOME too since the layout of these files is now similar to Unix.

Yep. That would be great!

[joelim-work]

This is implemented now.

Since this is a fundamental breaking change (default location of the config file), I will be pinning this issue for the time being.

[lboulard]

The canonical equivalent of Linux's ~/.config on Windows is %APPDATA%, whereas ~/.local corresponds to %LOCALAPPDATA%.

Incorrect. Both %APPDATA% and %LOCALAPPDATA% are a fusion of ~/.local, ~/.config and ~/.cache when dealing with files. Closest equivalent of ~/.config would be Win32 registry. Of course, impractical for lf.

%APPDADA% is for data shared across machines per application per user. %LOCALAPPDATA% is for data specific to a machine per application per user.

If you follow windows logic from here KNOWNFOLDERID, for example, you would have:

• lfrc: read %APPDATA%\lf\lfrc then %LOCALAPPDATA%\lf\lrc
• colors: read %APPDATA%\lf\colors then %LOCALAPPDATA%\lf\colors
• history: %LOCALAPPDATA%\lf\history
• marks: %LOCALAPPDATA%\lf\marks

My own experience with UNIX cli tools is that it is better to only support XDG in a cross platform tool then let users manage tools on Windows. I set XDG_* to isolated places to avoid conflit with Windows (mis)behaviors.
For me, settings XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_CACHE_DIR avoid conflict with %APPDATA% and %LOCALAPPDATA%.

Up to you to change again lf handling of data/configurations files. Windows is a lost cause. But please avoid breaking current setup.

[Bip901]

%APPDADA% is for data shared across machines per application per user. %LOCALAPPDATA% is for data specific to a machine per application per user.

That's true, and that is the closest Windows match to the behavior of their linux counterparts.

Try searching "xdg directories windows" in your favorite search engine - you'll find many developers using these choices for Windows. See for example this answer.

Windows is a lost cause.

This kind of thinking is not beneficial - we're trying to find the best solution given the current state of Windows. Try making it work, not giving up.

[lboulard]

Try searching "xdg directories windows" in your favorite search engine - you'll find many developers using these choices for Windows. See for example this answer.

And this accepted answer is incorrect. "Windows NT" description I found on this page only exits since Windows XP (may be 2k). There is no correspondance between XDG and Windows "AppData", just too many programmers who want to see one.
On Windows, application are expected to save config in registry and data place changed with time. Never changed since Windows 3.11. Oldest data place is ALLUSERSPROFILE=C:\ProgramData to store data for Win9x and older, and, still used by application that were never updated for Windows 2k and later in data management to stay compatible!!!

Windows is a lost cause.

This kind of thinking is not beneficial - we're trying to find the best solution given the current state of Windows. Try making it work, not giving up.

Sorry. This is not negativity, this is the state of Windows config file. Look at PowerShell that stores configuration files in ~/Documents and ignore any app data paths. Even Microsoft does not follow own rules.

If you want an answer, as someone that automate deployement of tools under windows. Follow XDG specifications everywhere, even on Windows, ignore any app data paths. This is the solution that is easier to manage (like git, tig, lazygit, glow, wezterm, …). All tools like eza, bat that try to fit in Windows are just a pain for config management automation. Currently, if I wanted to configure lf, I would do:

• LF_CONFIG_HOME=%XDG_CONFIG_HOME%\lf
• LF_CONFIG_DATA=%XDG_DATA_HOME%\lf

Always ignore Windows offering in data files management. If one day, you do a new CLI tools, never goes in Windows app data maze. Remember, for MS this is for data, not configuration, that should be inside WIn32 Registry.

For now, I have no lfrc in use. I do configure lf at start time because I just have 2 commands: set hidden and set info size:time. I simply deploy lf without any prepared configuration file.

[joelim-work]

If you want an answer, as someone that automate deployement of tools under windows. Follow XDG specifications everywhere, even on Windows, ignore any app data paths. This is the solution that is easier to manage (like git, tig, lazygit, glow, wezterm, …). All tools like eza, bat that try to fit in Windows are just a pain for config management automation. Currently, if I wanted to configure lf, I would do:

• LF_CONFIG_HOME=%XDG_CONFIG_HOME%\lf
• LF_CONFIG_DATA=%XDG_DATA_HOME%\lf

To provide some history, the reason why LF_CONFIG_HOME/LF_CONFIG_DATA exists is not because someone wanted to override XDG_CONFIG_HOME/XDG_DATA_HOME, it is because it was deemed strange to have XDG_ environment variables on Windows, see #1209 (comment) for more details. I would have preferred to just use XDG_CONFIG_HOME/XDG_DATA_HOME instead, but I wasn't the one who made the decision.

So I don't mind making a change to include XDG_CONFIG_HOME/XDG_DATA_HOME in the path lookup on Windows. It does raise the question of why LF_CONFIG_HOME/LF_DATA_HOME exists then - maybe I could deprecate it, but then it would be another breaking change although I'm not sure how many users would actually be affected by this.

[daanzu]

I vote for including XDG_CONFIG_HOME/XDG_DATA_HOME. I have them set for a reason.

[lboulard]

To provide some history, the reason why LF_CONFIG_HOME/LF_CONFIG_DATA exists is not because someone wanted to override XDG_CONFIG_HOME/XDG_DATA_HOME, it is because it was deemed strange to have XDG_ environment variables on Windows, see #1209 (comment) for more details. I would have preferred to just use XDG_CONFIG_HOME/XDG_DATA_HOME instead, but I wasn't the one who made the decision.

Comment is interesting. LOCALAPPDATA and APPDATA are system defined variables (readonly commodity for user). You do not change them. There are provided because you cannot get there values using KNOWNFOLDERID constants and Win32 COM API from dosbatch and cmd.exe.

So I don't mind making a change to include XDG_CONFIG_HOME/XDG_DATA_HOME in the path lookup on Windows. It does raise the question of why LF_CONFIG_HOME/LF_DATA_HOME exists then - maybe I could deprecate it, but then it would be another breaking change although I'm not sure how many users would actually be affected by this.

No long ago, there was a blog post macOS dotfiles should not go in ~/Library/Application Support running around geek/techno news site. I think some analogy apply here. OS provided App Data paths are made for GUI applications, not for command line tools.

I think myself that XDG is well done for all command line tools on any platform that defines an homefolder for user. If lf can go this way I am all for it, and may be only support XDG conventions (drop LF_* vars and any App Data paths). But I do not want to upset/confuse existing users.