Detecting the alternate lfrc files in text editors - a common file name extension?

[andis-sprinkis]

Discussion raised related to this PR for plugin that provides the lf configuration file (lfrc) syntax highlighting in Vim and Neovim:
Match all files ending with lfrc by DusanLesan · Pull Request #11 · andis-sprinkis/lf-vim

There is a demand for storing, editing and loading different lfrc files than the $HOME/.config/lfrc file.

Any of these files should be handled in a text editor as an lfrc format file (highlighting, toggling comments, LSP etc.).

The most typical way to detect text file formats are by their file name extension.

The Vim highlighting plugin I currently look after only checks for a full file name lfrc.

This can be added at the top of the lf config files

# vi: ft=lf

for Vim, Neovim and such, but most other text editors and syntax highlighters don't check for these headers.

Besides the currently used file name lfrc, I suggest having an agreed-upon file format extension for the alternate lf configuration files e.g. windows.lfrc or windows.lf.

@gokcehan what are your thoughts on this?

[joelim-work]

As a collaborator and someone who is quite involved in maintaining the project these days, I'll add my thoughts here.

Regarding the extension itself, I think I prefer .lf over .lfrc to be used by convention because:

• It is shorter
• It matches the filetype in the Vim plugin
• Dedicating an extension to this implies that lf has its own configuration language and should be named as such - for example Vim uses an extension of .vim and not .vimrc.

Since users are actually allowed to name their config file whatever they want (can be specified using the -config option), there is also the question of whether lf should support the new extension directly. I think it is fine to load from something like $HOME/.config/lf/config.lf by default, but the original $HOME/.config/lf/lfrc should be kept for backwards compatibility (it is too large of a breaking change otherwise). It shouldn't be too difficult to implement though:

diff --git a/os.go b/os.go
index ff3669e..7007779 100644
--- a/os.go
+++ b/os.go
@@ -92,7 +92,9 @@ func init() {
 
 	gConfigPaths = []string{
 		filepath.Join("/etc", "lf", "lfrc"),
+		filepath.Join("/etc", "lf", "config.lf"),
 		filepath.Join(config, "lf", "lfrc"),
+		filepath.Join(config, "lf", "config.lf"),
 	}
 
 	gColorsPaths = []string{
diff --git a/os_windows.go b/os_windows.go
index dac8f44..60f15f8 100644
--- a/os_windows.go
+++ b/os_windows.go
@@ -78,7 +78,9 @@ func init() {
 
 	gConfigPaths = []string{
 		filepath.Join(os.Getenv("ProgramData"), "lf", "lfrc"),
+		filepath.Join(os.Getenv("ProgramData"), "lf", "config.lf"),
 		filepath.Join(data, "lf", "lfrc"),
+		filepath.Join(data, "lf", "config.lf"),
 	}
 
 	gColorsPaths = []string{

Apart from that the only other things that needs changing is updating the documentation and renaming the files in the etc directory.

---

In any case, this kind of change is big in terms of the fundamental design, and also low-priority. So I would prefer to keep this as a discussion for now before making any changes.

[DusanLesan]

@joelim-work Making additional files with the .lf extension makes sense to me based on the points you listed. Previously, I decided against it purely for aesthetic reasons: I didn’t like having an extension that matches the parent directory name, such as ./lf/tmux.lf.

I’m fine with either .lf or .lfrc, and for the sake of a faster decision, I’d vote for .lf, as it seems to be the preferred choice so far.

I’d say lf itself doesn’t need any changes for now. We could simply settle on a generally agreed upon extension for non default config files. The discussion could then extend to whether an alternative naming for the default config is necessary.

lf-vim will still need to support lfrc file name for compatibility purposes, and an alternative naming convention wouldn’t affect it, as it would still need to support both lfrc and *.lf (or any other agreed extension).

[DusanLesan]

Also, I recently saw someone using .lfrc, which made me consider broader support for supplementary config files in the first place #1942 (comment)

[andis-sprinkis]

Seems like the *.lf file name extension is well available for adoption.

• Vim runtime files (built-in syntax and other filetype-specific plugins, which it has >1200, accumulated over a long period of time) don't refer to any .lf files
  • vim/runtime at master · vim/vim
• Vscode language identifiers don't specify any .lf files either
  • Language Identifiers
• The bat syntax highlighter has no .lf files either.
  • bat/assets/syntaxes at master · sharkdp/bat
• Google results about .lf text files for me only return only what looks like a vendor-specific robotics language (not that I'm familiar with this topic).
  • .LF File Format — ride-cli documentation