String literal autocomplete

[shaded-enmity]

Been using Helix as my daily driver for over a year now, and one thing I've been consistently bumping into is the lack of autocomplete for string literals.

Example code:

df["col"] = df["col"].fillna(0)

This is quite a common pattern when working with Pandas dataframes and sometimes the column names can be annoyingly long. When writing out the second "col" I'd like to be able to trigger autocomplete with list of other string literals in the current file.

In pseudocode:

fn autocomplete_string_literals(document: &Document, cursor: &Cursor) -> List<String> {
  let node: AstNode = document.node_under_cursor(cursor);

  if let AstNode::StringLiteral(text) = node {
    return document.iter_string_literals().filter_map(string_candidate_metric(text)).collect();
  }
}

Is something like this possible today? If not, I'm happy to look into it if such PR would be welcome.

[pascalkuthe]

that is too specifc, that could be covered by #1063 but I don't think specific completions for string literals would be supported (or even could be what is a string literal is language dependent).

This would be more appropriate as a feature request to the language server you are using (they have an ast we do not)

[shaded-enmity]

Hmm, couldn't this be based solely on the Tree Sitter integration of each supported language? I guess the problem then becomes a matter of having a mapping of tree_sitter[language].string_literals to actual AST types for the given language and some kind of lens for extracting the literal value from the node.

[pascalkuthe]

you may theretically be able to build something on ts but that needs queries for every language/a lot of effort. We are not going to do that for something fairly niche like this

[pascalkuthe]

it would also be inferior to actual lsp completions since we don't know if a string literal is valid at the current location so helix would always suggests string literals everywhere whereas an lsp can figure out you are in a position where a string literal would be valid

[shaded-enmity]

The upside is that "what is a string literal in tree sitter" is rather standardized because of highlights.scm, which, by convention uses the @string type for that. So maintaining the mapping is pretty much automated task.

Using a custom LSP server for this entails having another copy of tree-sitter and its many grammars in my custom LSP and an entire new dependency stack to audit.

Anyway, I understand that this feature is not desired for Helix core, I'll look into the LSP folks reference in the linked issue, thanks for finding that!