Thanks, I have updated the documentation for statfmt as well, and removed the experimental notice from the wiki.

May I ask what's the consideration for loading ruler file dynamically but not set a default path? colors and icons have their default path under ~/.conf/lf. Why not have default for ruler?

May I ask what's the consideration for loading ruler file dynamically but not set a default path? colors and icons have their default path under ~/.conf/lf. Why not have default for ruler?

Currently, colors and icons cannot be changed or re-sourced at runtime. lf checks whether they exist in one of its recognised configuration directories. You can read more about these locations and their resolution order here.

When introduced in r39, rulerfile behaved just like icons and colors (i.e. having a fixed name and location). With the release of r41, the option changed from a boolean toggle to a path string instead, just like previewer and cleaner. This allows users to change the design of the ruler on the fly.

Resolving rulerfile, previewer and cleaner relative to the config directory was already brought up in #2418. I am not against this idea.

just like previewer and cleaner. This allows users to change the design of the ruler on the fly

The file of previewer and cleaner are executable files. Which means that I can put this file in the $PATH. So, I can simply set it to the file name, but not the absolute path nor the relative path.

Thus, I think the situation of rulerfile is more like icons and colors. They are not executable files. And they have default path.

I'm not strongly against loading it dynamically. But just a little bit confused by the config style.

Thus, I think the situation of rulerfile is more like icons and colors. They are not executable files. And they have default path.

The icons and colors files either exist in their pre-defined locations or not. Unlike these, rulefile does not have a default path or file name. Realistically, most people will use ~/.config/lf/ruler but it could be named anything. Not having a fixed location is required to make rulerfile load dynamically.

Imagine developing a plugin for Vim that uses lf as a file picker. It might make sense to change the appearance of the ruler. Before there was rulerfile, plugins could just change rulerfmt and statfmt like this lf -command 'set rulerfmt foo; set statfmt bar' or this lf -config vim_lfrc. How would you do this now, if the path of the ruler was hardcoded? Backup the existing ruler file inside the config dir, replace it with yours, launch lf and after that delete the new ruler file and restore the previous one? Instead, you can just do lf -command 'set rulerfile vim_ruler'.

Before there was rulerfile, plugins could just change rulerfmt and statfmt like this lf -command 'set rulerfmt foo; set statfmt bar' or this lf -config vim_lfrc. How would you do this now, if the path of the ruler was hardcoded? Backup the existing ruler file inside the config dir, replace it with yours, launch lf and after that delete the new ruler file and restore the previous one? Instead, you can just do lf -command 'set rulerfile vim_ruler'.

Oh, this make more sense to me. Thanks for your reply