Unicode completion of suffix first, with exact matches low priority

[aaron-jack-manning]

This is possibly related to #50, but the issue is present for me in the case of Unicode completion.

I have Unicode completion set up for various mathematical symbols but it generally very hard to get the symbol I am after, even when the source text has an exact match to the symbol name.

For instance, if I type in I get completions for symbol names beginning with in (such as integral) before the symbol which is just called in.

The same thing happens with suffixes, where I have an exact match typed in the buffer, but a partial match to the end of the word I am after is included and higher in the completion list.

[estin]

Hi! Seems like you needs to disable tail-word completion and works only with unicode-input

[language-server.scls.config]
feature_snippets = true
snippets_first = true
snippets_inline_by_word_tail = false
feature_unicode_input = true

And yes unidecode-input completions append to the end of list.

Or try to use only tail-word completion for all cases, because both feature tail-word and unicode-input have same search logic.

[aaron-jack-manning]

and works only with unicode-input

I'm not sure I fully understand what you mean by this. My goal with this is only to do unicode completion, my previous configuration was

[language-server.scls.config]
feature_unicode_input = true

and changing this to

[language-server.scls.config]
snippets_inline_by_word_tail = false
feature_unicode_input = true

or

[language-server.scls.config]
feature_snippets = true
snippets_first = true
snippets_inline_by_word_tail = false
feature_unicode_input = true

doesn't resolve the issue.

[estin]

Please build from master and try it. Filled sort_text for completion items and use ordered collections to search by.

    /// A string that should be used when comparing this item
    /// with other items. When `falsy` the label is used
    /// as the sort text for this item.
    #[serde(skip_serializing_if = "Option::is_none")]
    pub sort_text: Option<String>,

Tail-word completion and unicode completion currently works by same logic but with different configuration ways

Tail-word configured by (regular snippet)

~/.config/helix/languages.toml

[language-server.scls.config]
snippets_inline_by_word_tail = true
feature_unicode_input = false

~/.config/helix/snippets/snippets.toml

[[snippets]]
prefix = "alpha"
body = "α"
description = "This is α. Used in math ... other markdown docs"

Would have same completion logic as unicode-input completion with next config (simplified snippet)

~/.config/helix/languages.toml

[language-server.scls.config]
snippets_inline_by_word_tail = false
feature_unicode_input = true

~/.config/helix/unicode-input/base.toml

alpha = "α"

[aaron-jack-manning]

This does not seem to resolve the problem, although I have done a little more digging and it seems this is a consequence of when (within the word being typed) the completion logic first computes options.

I have recorded a video to explain what I mean. If I type the whole word before the completion can finish, it gives suggestions from the tail. If I type slowly, and let it give suggestions first, it then correctly filters those suggestions based on the new characters.

Screencast.From.2025-03-30.10-58-02.mp4

Notice that the first time I get completions for symbols that start with "ha" (short for harpoon, which is the start of each of those symbol names), but the second time I wait a moment after typing "alph" and get suggestions for "phi" instead (which is not given in the first case).

[estin]

Thanks! Now I can understand this behavior. And by yours helix-editor/helix#1438 (comment) unicode-input config generator I was feel this bug )

Please try this experimental branch to solve this issue

cargo install  --branch reverse-unicode-input-logic  --git https://github.com/estin/simple-completion-language-server.git

[aaron-jack-manning]

There is still some level of inconsistency in the symbol list which depends on whether I stop typing part way through the symbol name.

Screencast.From.2025-04-08.22-34-36.mp4

Screencast.From.2025-04-08.22-37-10.mp4

That said, these changes have resulted in the symbol I am after far more often being at the top of the list, and much easier to access. So while there is still a little bit of strangeness in the behaviour, my main issue is mostly resolved.

[estin]

@aaron-jack-manning now fixed and pushed to main branch

Preserve ordering by CompletionItem.sortText attribute

      /**
	 * A string that should be used when comparing this item
	 * with other items. When omitted the label is used
	 * as the sort text for this item.
	 */
	sortText?: string;