Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tree-sitter tokens don't have any background colour #81

Closed
Romankivs opened this issue Jan 25, 2025 · 9 comments · Fixed by #86
Closed

Tree-sitter tokens don't have any background colour #81

Romankivs opened this issue Jan 25, 2025 · 9 comments · Fixed by #86
Labels
bug Something isn't working

Comments

@Romankivs
Copy link
Contributor

Describe the bug

Tree-sitter tokens don't have any background colour.

To Reproduce

Steps to reproduce the behavior:

  1. Setup tree-sitter grammar and parser for any language (e.g Rust) in ~/.ad.
  2. Open any file with code written in the corresponding language.

Expected behavior

Tree-sitter tokens are display with default background colour.

Screenshots

How it looks:

Image

Versions & OS Details

  • OS: Linux
  • Distribution: Arch
  • ad Version: 7971f28
@Romankivs
Copy link
Contributor Author

Proposed fix: #82

@sminez
Copy link
Owner

sminez commented Jan 26, 2025

Rather than requiring a background colour to be specified for each syntax element, I'd prefer that the default background be used when one is missing. Otherwise all this does is "fix" the default config.

For future issues, please bear in mind the advice given in the README of this repo and wait for a response to issues before raising PRs.

@Romankivs
Copy link
Contributor Author

For future issues, please bear in mind the advice given in the README of this repo and wait for a response to issues before raising PRs.

Sure, no problem

I'd prefer that the default background be used when one is missing.

Yeah, seems reasonable.

@Romankivs
Copy link
Contributor Author

The most straightforward way to achieve this seems to be to modify Colorscheme::styles_for method (responsible for providing Styles for a given tree-sitter token type) to insert default colorscheme's bg color when none is specified for a given token type:

pub fn styles_for(&self, tag: &str) -> Styles {
    let mut styles = match self.syntax.get(tag) {
        Some(styles) => styles,
        None => tag
            .split_once('.')
            .and_then(|(prefix, _)| self.syntax.get(prefix))
            .or(self.syntax.get(TK_DEFAULT))
            .expect("to have default styles"),
    }
    .clone();

    // Use default colorscheme's background color if none is specified
    if styles.bg.is_none() {
        styles.bg = Some(self.bg);
    }

    styles
}

Let me know whether this is an acceptable solution for this issue.

@sminez
Copy link
Owner

sminez commented Jan 27, 2025

I think that looks mostly alright but can we make the check and set the default once after loading config rather than on each access? This code gets called pretty frequently so keeping things as efficient as possible is a priority. There's definitely outstanding work around making this more efficient in general but I'd at least like to maintain the current performance where possible.

@Romankivs
Copy link
Contributor Author

The right place for setting default bg color for tree-sitter tokens seems to be inside of Config::try_load() near cfg.expand_home_dir_refs(&home); that is also responsible for config modification before returning it.

pub fn try_load() -> Result<Self, String> {
  ...
  
  cfg.set_default_bg_for_tokens();
  cfg.expand_home_dir_refs(&home);
  
  Ok(cfg)
}

...

fn set_default_bg_for_tokens(&mut self) {
    for style in self.colorscheme.syntax.values_mut() {
        // Use default colorscheme's background color if none is specified
        if style.bg.is_none() {
            style.bg = Some(self.colorscheme.bg);
        }
    }
}

Let me know whether my assumptions are correct and that is similar to what you had in mind.

@sminez
Copy link
Owner

sminez commented Feb 1, 2025

That looks reasonable 👍

@Romankivs
Copy link
Contributor Author

PR: #86

@sminez
Copy link
Owner

sminez commented Feb 12, 2025

Sorry @Romankivs, I didn't see that PR come through in my GitHub notifications. Thank you for this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants