Incorrect type flags used to mark parameters and functions

[Complex2-Liu]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the discussions and believe that my question is not already covered.

Feature Request

Motivated by package tidy. See also LuaLs for someone familiar with Neovim.

/// Check if the given value is defined
///
/// @param v any
/// @return boolean
#let has(v) = {
  type(v) != type(none)
}

/// Like html rem
///
/// @param n integer
/// @param fontsize? length The root font size
/// @return length
#let rem(n, fontsize: 11pt) { return n * fontsize }

[astrale-sharp]

Hey there :)
What's the request here specifically ?

[Complex2-Liu]

rem is defined as a function, but typst-lsp prompts that it is a constant.

For packages (say physica) inside @preview, tensor is identified correctly as a function.

However, when I invoke this function, typst-lsp prompts that it is a constant again.

The image below shows how LuaLs works. It displays the comment of a function, and the information about parameters of this function: it takes only one parameter, v, which can be of any type.

[astrale-sharp]

I see thanks, it's clearer now ;)

[astrale-sharp]

This is probably a good first issue (I haven't investigated but it doesn't seem too complex). What do you think @Myriad-Dreamin ?

[Myriad-Dreamin]

typst-lsp just uses typst-ide for autocompletion. So imo, the inperfect is more probably caused by typst-ide, and less by typst-lsp. @astrale-sharp Is it time to check it by our awesome ide testing framework, :)?

typst-lsp/src/server/lsp.rs

Lines 426 to 429 in 0d5b933

	let (typst_start_offset, completions) =
	typst_ide::autocomplete(&world, Some(&doc), &source, typst_offset, explicit)?;
	let lsp_start_position =
	offset_to_position(typst_start_offset, position_encoding, &source);

[Myriad-Dreamin]

Supplement. If I understand webapp's completion correctly, webapp tells me the add function is a constant as well (c character in the following figure).

[nvarner]

Agreed, this is almost certainly a Typst bug. From a quick look at the relevant code, the scope_completions function looks a little ad-hoc, and improving its implementation is probably the fix.
https://github.com/typst/typst/blob/main/crates/typst-ide/src/complete.rs#L1280

[astrale-sharp]

@astrale-sharp Is it time to check it by our awesome ide testing framework, :)?

Unfortunately I just added functionality for testing the actual string being autocompleted, not it's kind which is globally a bit more weird to check if there are many possible completions 😅

[astrale-sharp]

Then I propose we should close this and open a typst issue, any objection @Complex2-Liu ?

[Enter-tainer]

We may open a typst issue and keep this open. And this can be closed once the upstream bug get fixed