feat: allow themes to add a custom style for file extensions

[mikavilpas]

Request for comments

This is a draft PR, and I'm looking for feedback on the feature itself, the implementation, and the API.

This adds a feature that allows

• (optionally) specifying a custom style for file extensions.
  • by default, the extension is styled the same as the filename, so the user has to opt in to this feature.
  • this can help to visually distinguish between different file types.
  • an extension is defined as rust defines it, i.e. the part of the file name after the last ..
  • directories don't have extensions, so they are not affected by this feature.
• (possible in the future) solving feat: add "extension" linemode (m e) to show extensions of files #1036
  • instead of displaying a single filename, could now split the filename into two parts, the name (stem) and the extension. Then could truncate the stem to fit the screen.
  • this PR can help applying search highlights to these two parts separately.
• (possible in the future) allowing different styling for different types of extensions.
  • this PR can help applying search highlights while maintaining the custom style.

Example: a custom style for file extensions

Example: highlights are displayed correctly when highlighting searches

Example: the way to configure the style in theme.toml

diff --git a/.config/yazi/theme.toml b/.config/yazi/theme.toml
index b6392db..63d24ed 100644
--- a/.config/yazi/theme.toml
+++ b/.config/yazi/theme.toml
@@ -7,6 +7,7 @@
 
 syntect_theme = "~/dotfiles/.config/bat/themes/catppuccin-bat/themes/Catppuccin Macchiato.tmTheme"
 cwd = { fg = "#8bd5ca" }
+extension = { fg = "#6e738d", italic = true }
 
 # Hovered
 hovered = { fg = "#24273a", bg = "#8aadf4" }

Open questions

• do you think this feature is useful? I can finish it if you think it is.
• currently, some multibyte unicode characters position the extension highlight incorrectly.
  • I think this is possible to solve, but I'm not sure it might behave on different platforms.
  • I noticed searching uses regex on the byte level, so maybe this could be a good way to try to solve this.

[sxyazi]

Sorry, I can't accept this PR.

Its implementation is too complex and contradicts Yazi's design principles - features related to UI and insensitive to performance should be prioritized to be implemented on the Lua side, allowing users the ability to rewrite them to customize their own interactive experience.

[mikavilpas]

features related to UI and insensitive to performance should be prioritized to be implemented on the Lua side, allowing users the ability to rewrite them to customize their own interactive experience

Do you think it would be a good idea to rework this idea a little bit, and allow plugins to add arbitrary highlights? I could see this enabling a lot of features for plugins to write.

I actually started writing this in lua, but had the following issues:

• no testing framework is available for lua code
  • very difficult to maintain without tests
• support for type checking is limited
  • difficult to get the implementation right

[sxyazi]

Do you think it would be a good idea to rework this idea a little bit, and allow plugins to add arbitrary highlights? I could see this enabling a lot of features for plugins to write.

Yes, I absolutely love the idea. It's just that I don't like its current implementation - implementing it in Rust almost bids farewell to scalability.

I actually started writing this in lua, but had the following issues:

Yeah this is a long-standing issue with the plugin system. But I can't afford to spend too much time on it right now, there are more pressing matters at hand - I'm planning to redesign some of the plugin system's APIs, and these will all be breaking changes, so I need to get them in place by Yazi v0.3. Perhaps we can look into addressing them after Yazi v0.3, it should be soon.

[mikavilpas]

I absolutely love the idea

Ok, nice. I got the opposite impression from your first reply, but maybe we can try this again later.

I was thinking (depending on the implementation), some kind of logic might also be required so that plugins don't apply conflicting highlights, so it needs a redesign anyway.