PostGtk4 - Feature: Snippets plugin: initial version - #1113

Just a few preliminary code style comments. I'll have a more detailed look later. Probably best not to try and pack too much functionality into one PR. Choosing and inserting a few builtin (Vala) snippets is probably enough for a first step.

@jeremypw Thank you for the quick and extensive review. I'll work on these points as soon as I can.

I feel like this is ready for review now. A set of vala snippets is shipped with the plugin. You can see it in action below

snippets

Some noteworthy changes:

1. moved some functions from the preserve indent plugin to Scratch.Utils. They are probably useful in other plugins/features as well
2. the timeout to cancel an edition is 1 second
3. snippets.json is installed to PLUGINDIR/snippets/snippets.json

Merged master. I'm available to iterate on this, just let me know. We can also talk on slack about it if sync communication is better.

This is shaping up as a useful addition though -thanks for working on it!

@jeremypw From my poking around it seems like Word Completion does not play well with other completion providers. It seems to assume that it's the only completion provider and invalidates the context when it doesn't have proposals. I can send another PR that "fixes" this before this one is accepted. What do you think about that?

I used standard GtkSourceView widgets. I believe it's expected that the user understands how to use it. Honestly, I was always selecting with the arrows and it took me a while to realize that I could use Alt+2 for the second option. Same for Alt+D for details.

I added details to each snippet, so at least it's easier to know what they will do.

image

@igordsm Using the builtin SourceCompletion UI is fine for now although it looks rather ugly (to me). More of a problem is how different completion plugins are going to work together. There are potentially three: this one, the existing word-completion plugin and the proposed GVLS plugin. Is there a way of making all these work together or are we going to have to make them mutually exclusive?

I'm working on making the word completion plugin play nice with others. It assumed that it was the only one and did lots of strange things. As soon as I can test it together with snippets I'll send a draft PR. I'm convinced that completions providers can work together without problems.
...
On Wed, Nov 10, 2021 at 5:31 AM Jeremy Wootten @.***> wrote: @igordsm https://github.com/igordsm Using the builtin SourceCompletion UI is fine for now although it looks rather ugly (to me). More of a problem is how different completion plugins are going to work together. There are potentially three: this one, the existing word-completion plugin and the proposed GVLS plugin. Is there a way of making all these work together or are we going to have to make them mutually exclusive? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1113 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWCBR5DELZ43B2QYDB5JLULJCWVANCNFSM5FOW33AA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
-- Igor Montagner http://igormontagner.blogspot.com/

You should consider that GVls plugin and potentially others use async completion fill, that means you should consider to add proposals and pass false to add_proprosals() when your plugin is still in the works and true when it finish so make the others create its own proposals. Look at GVls's code.

I propose you to add you snippets to GVls so it can provide context snippets as completions using Microsoft LSP specification for snippets. This will help to avoid the problems above.

Also is possible to add a word index in GVls for an specific buffer and provide completion proposals for words, that may is useful and will fix the issue with current plugin requiring to deactivate it.

I can't help thinking that we should not get too tied into GVLs at this stage - is it not possible to write a more generalized LSP client plugin that could use any LSP compliant server and keep the server code more at arm's length? I need for one need to find time to do a lot more work on understanding language servers in general and GVLs in particular.

I take the point that we need to consider how to make synchronous and asynchronous completion processes work together at some point. Not sure it should block release of this plugin as we do not have a working VLS plugin implementation yet.

I can't help thinking that we should not get too tied into GVLs at this stage - is it not possible to write a more generalized LSP client plugin that could use any LSP compliant server and keep the server code more at arm's length? I need for one need to find time to do a lot more work on understanding language servers in general and GVLs in particular.

GVls provides a generic LSP client and a Server Manager to easy connect to any out there.

May you want to create a Vala snipped library so I can integrate it into GVls so that will be transparent for you. Your library could be used to write snippets plugins to any Vala editors or any thing out there.

I can help you to create your library if you want, so we can share work and help you to avoid understand how GVls or any other LSP client/server works.

I take the point that we need to consider how to make synchronous and asynchronous completion processes work together at some point. Not sure it should block release of this plugin as we do not have a working VLS plugin implementation yet.

As I've explained before, you should consider add_proprosals() to consider that async work on in the middle you (or both) work to write a snippets library for Vala, so any like GVls can add proposals and avoid conflicts with multiple completion providers.

GVls plugin in working, more integration to code will help to provide generic LSP client, that that is another history.

 public class CodeUnit : Object {
 public struct TextUnit {
 int64 start;
 int64 end;
 }
 private ArrayList<TextUnit?> m_text_units;
 public string trigger { get ;set; }
 public string database { get; set; default = "SQL"; }
 public string category { get ;set; default = ""; }
 public string description { get ;set; default = ""; }
 public string text { get; set; default = ""; }
 public ArrayList<TextUnit?> placeholders { get { return m_text_units; }}
 construct {
 m_text_units = new ArrayList<TextUnit?>();
 }
 }

I'm implementing the same thing with GtkSourceView5, I use the class above to represent the snippet.

In view of Gtk.SourceView5 providing a framework for snippets probably best to re-think this after porting Code to Gtk4.

Marking as blocked until sourceview-5 lands

It would be nice to progress this but needs to wait til after Gtk4 port which is the priority.