allow customization of file type in statusbar

[sbromberger]

trafficstars

Describe your feature request

Now that #2434 has been merged and we have this great new capability, I'd like to revisit the discussion started in this comment. Specifically, I'd like to get feedback on my idea to allow customization of file type to user-settable strings. "typescript" takes 9 characters in the statusbar, but with the properly installed glyphs can be reduced to a single "TS" icon. This gives more room for other statusbar plugins that will be coming in future updates.

As commented, this shouldn't be a heavy lift in terms of code - it looks to be a fairly straightforward PR - but it's probably worth some discussion to see whether this is a feature that others (besides myself) would use.

[sbromberger]

cc @etienne-k

[usagi-flow]

I see a number of different approaches. Here's two of them which I believe offer the most advantages:

Simple but flexible configuration

The idea would be to be able to configure how the file type is displayed using two configuration options:

[editor.statusline.file-type]
name = "short" # long/short/none
icon = true

This is probably the highest level of language-independent configurability.

It remains to be verified if icon should really be a local property here, or if we shouldn't simply offer a global opt-in option like devicons = true which would then also apply icons to the future file tree and maybe to some VCS/Git statusline element.

The downside of this approach is that for each file type, we'd have to define a "short" name.

Nonetheless, whether or not we use short names, and whether the devicons property is defined locally or globally, I prefer this solution because it provides quite some customizability without requiring "too much configuration effort" from the user.

User-defined mappings

Here, we'd let the user define how each file type would be represented:

[editor.statusline.file-type]
"name.rust" = "rs" # Could also use a devicon here
"name.typescript" = "ts"

This would be the easiest to implement and fastest to achieve, but we're basically shifting work to the user. It remains to be seen if this would be an approach we really want.

[sbromberger]

Honestly, I'm in strong favor of the second option (User-defined mappings). It allows customization beyond just "devicons" - if I wanted just ts or rs for "typescript" or "rust", I could do it - but if we use the first option that no longer becomes possible - I'm constrained to the full name, a single short alternative, or nothing.

My feeling is that if users are going out of their way to change the defaults they should be offered the widest possible latitude for customization.

[sbromberger]

@etienne-k - how opposed to the second option are you? I'd like to perhaps start a PR on this soon, but want to make sure we have reasonable consensus before I do so.

[usagi-flow]

Opposed? Not at all! :)

Simply because this change would introduce new functionality (more specifically: configurability) which isn't there yet, and that, at the cost of... nothing I can think of.

In other words, the way I see it, we're choosing between: "luxury but complicated to implement" and "great and easy to implement"

So while I can't speak for everyone, I do think such a PR would definitely be welcome! Even if it generates additional discussion.

[the-mikedavis]

See also https://github.com/helix-editor/helix/pull/2869 for discussion of bringing in icons by configuration

[sbromberger]

So - thinking about this some more, I don't think this mapping should be limited to the statusline (that is, it shouldn't be under editor.statusline) I can see it being useful elsewhere (like in bufferline, whenever that gets merged, and perhaps in file pickers). I might try making this a top-level editor config setting, instead of statusline.