Trying to find how code is highlighted for warnings...

[carlca]

Consider this mojo code...

Functionally, both pairs of lines behave in the same way, only the first pair of lines have this ugly underline because the compiler thinks that the final call to background_color is causing an unused variable warning, because the fluent nature of the API requires each call made to a fn in Colors to return another instance reference of Color, thus allowing commands to be chained.

See how the highlighting is avoided in the second pair of lines by assigning the "unused variable" to a no-op variable _ =. I've searched though the Zed source code, and through your mz source code, but I cannot figure out how to disable this wavy, yellow line. I can check for warnings when I build from the command line; I don't need the editor to do it for me as I code... it's really distracting 😉

Any ideas?

[carlca]

I've found what seems to be a solution to the problem. I borrowed the highlights.scm from https://github.com/bajrangCoder/zed-mojo, another extension for Zed and Mojo. I placed the file in the languages/mojo folder of your extension and reinstalled the extension. The auto-complete still works but the warnings are not highlighted now, which is what I was after!

While this works as a solution for me, I imagine that this might be considered as treading on the toes of the other developer. However, his extension does not seem to support auto-completion... I'll leave such diplomatic issues to you to deal with 😉

[freespirit]

Hi @carlca thanks for reaching out. I'm not sure I get it - the rules in languages/mojo/highlights.scm should only apply for syntax highlighting and not for warnings. E.g. the way variables (style) are in white/gray, types (Colors) - in yellow and functions (p()) - in blue.
What bothers you instead is the warning that underlines the whole expression saying there's an unused variable. This should come from the other part of the plugin - src/lib.rs - that is responsible for running the mojo language server.
If background_color() does return a variable (the instance, so that you can chain calls), than the warning is appropriate or at least how it's intended to work on an LSP level. I'll try to find alternative solutions, like an LSP option "Disable warning X" but at first glance I couldn't find one. And _ = is what I've often seen used in such cases.

[carlca]

Hi @freespirit thanks for the reply! I've found that it you run magic run mojo-lsp-server --help there is a mass of available parameters, but I cannot find any documentation on thee parameters anywhere. I'm thinking that if the right parameter could be found, it would be a relatively easy task to add it in via lib.rs...

    fn new() -> Self {
        Self {
            command: "magic".to_string(),
            args: vec!["run".to_string(), "mojo-lsp-server".to_string()], // Extra params here?
        }
    }

[freespirit]

Hi @freespirit thanks for the reply! I've found that it you run magic run mojo-lsp-server --help there is a mass of available parameters, but I cannot find any documentation on thee parameters anywhere. I'm thinking that if the right parameter could be found, it would be a relatively easy task to add it in via lib.rs...

fn new() -> Self {
    Self {
        command: "magic".to_string(),
        args: vec!["run".to_string(), "mojo-lsp-server".to_string()], // Extra params here?
    }
}

Hi @carlca ! This was the first place to take a look but I found no useful option as well. I haven't yet found options to enable/disable linting rules with mojo-lsp-server but if you find some, I'd be happy to take a look. Thanks!