Snippets: First character not replaced with snippet

m1ga commented 8 months ago

Thanks in advance for your bug report!

[X] Have you reproduced issue in safe mode?
[X] Have you used the debugging guide to try to resolve the issue?
[X] Have you checked our FAQs to make sure your question isn't answered there?
[X] Have you checked to make sure your issue does not already exist?
[X] Have you checked you are on the latest release of Pulsar?

What happened?

When using e.g. the default HTML snippet to create a HTML layout it will keep the first < when filling in the snippet content.

https://github.com/pulsar-edit/pulsar/assets/4334997/7f37d83d-1f9a-441a-94c7-6cf8ae8edeef

Pulsar version

1.112.0

Which OS does this happen on?

🐧 Red Hat based (Fedora, Alma, RockyLinux, CentOS Stream, etc.)

OS details

Fedora 39

Which CPU architecture are you running this on?

x86_64/AMD64

What steps are needed to reproduce this?

create a new file
save it as .html
start <html
click enter to apply the snippet

Additional Information:

No response

savetheclocktower commented 8 months ago

So there are two differentautocomplete-plus providers offering you completions in this scenario.

The first html you see in your menu is offering you a snippet autocompletion. The trigger for that snippet is html, so the autocomplete-snippets provider is offering it to you expecting you'll just type html on a new line (without a preceding <) and it'll expand to the full snippet.

The second html you see is from autocompete-html and would have the contextual awareness that you're looking for.

One could argue that autocomplete-snippets shouldn't be suggesting a snippet when there's a preceding < character, but autocomplete-snippets doesn't have any specific knowledge of HTML; it just offers completions when a word being typed matches a snippet trigger word. <, being a non-word character, is regarded as irrelevant to its job.

But it seems arguable to me that the snippet autocompletion suggestion shouldn't appear above the suggestion from autocomplete-html. Those priorities are hard-coded, annoyingly.

I can think of two workarounds:

If you don't use the HTML snippets, you can go into the language-html package settings and turn them off. If they're not enabled, autocomplete-snippets won't suggest them to you. If you use only certain ones, you can disable the snippets, then copy individual ones into your own snippets.cson; there's a button for that in the package settings.
If you don't like that snippets are being shown in the autocompletion menu at all, you can disable autocomplete-snippets entirely. That's a blunt solution, but it might be agreeable to you.

The fix I'd want is a way for users to give their own nudges to the priority list for autocomplete-plus providers. I'll keep this issue open while I look into that.

confused-Techie commented 8 months ago

@savetheclocktower For your preferred fix, do you envision a setting in autocomplete-plus along the lines of priority with options such as "Always prioritize Snippets first", "Always prioritize autocompletions first", "Default"?

That way, while the priority is hard coded, it lets us have some effect on it, with the ability to not upset the status quo where it probably doesn't need to be.

m1ga commented 8 months ago

The second html you see is from autocompete-html and would have the contextual awareness that you're looking for.

but that won't trigger the snippet which I want to have. It will just complete the tag. But I didn't know I can just type html! Because in a normal page when you create an image you would start with < and type <img and then press enter. That will also keep two <<.

savetheclocktower commented 8 months ago

The second html you see is from autocompete-html and would have the contextual awareness that you're looking for.

but that won't trigger the snippet which I want to have. It will just complete the tag. But I didn't know I can just type html! Because in a normal page when you create an image you would start with < and type <img and then press enter. That will also keep two <<.

Yeah, this is why I'm ambivalent about snippets being offered as suggestions. Originally, the idea was that you just typed a magical token and pressed Tab to trigger a snippet. Offering them as autocompletion choices certainly makes them more discoverable, but the contextual difference between “the snippet triggered by html” and ”the HTML element” is obscured.

savetheclocktower commented 8 months ago

@savetheclocktower For your preferred fix, do you envision a setting in autocomplete-plus along the lines of priority with options such as "Always prioritize Snippets first", "Always prioritize autocompletions first", "Default"?

That way, while the priority is hard coded, it lets us have some effect on it, with the ability to not upset the status quo where it probably doesn't need to be.

It wouldn't be as specific as that. Maybe the simplest fix would be to create a config setting on autocomplete-snippets (and perhaps other autocompletion providers) to allow the user to substitute a custom priority value.

I tried to tackle this with symbols-view by allowing the user to specify a list of providers (by either their humanized provider name or by the name of the provider package) and boosting priority in reverse order of their indices. So if you listed three packages in that config field, the first package would get a boost of 3, the second a boost of 2, and the third a boost of 1. I also made it so that providers can report a priority value dynamically, but with a minimum of 0 and a maximum of 1 — so that there wouldn't be a “priority war.” But extensive changes like that would require a change in the autocomplete.provider service and updates in all the provider packages.

pulsar-edit / pulsar