pygls icon indicating copy to clipboard operation
pygls copied to clipboard

Register custom Document and Workspace classes

Open m-kru opened this issue 5 years ago • 5 comments

pygls provides some basic Document and Workspace classes. However, in real you expect these classes to have more functionality, for example user may want Document class to store list of symbols. I was wondering what was your idea on user utilizing these classes. Should I inherit from them, or maybe use them as attributes?

m-kru avatar Aug 18 '20 15:08 m-kru

You can take a look here on how to use your custom Document and protocol classes, and here on how to provide protocol class to the server.

I would say that this is a workaround and there should be an easier way to provide custom Document and Workspace (sub)classes, but I hope it allows you to move forward with your project for now.

danixeee avatar Aug 18 '20 16:08 danixeee

I do not like workarounds. Do you have any "easier way" in your mind?

m-kru avatar Aug 19 '20 05:08 m-kru

The solution that I used in textX-LS is pretty straightforward and there's nothing wrong with it. In my case it wasn't workaround because I needed to override protocol class as well.

You can always do something like:

import pygls.workspace

class MyDoc(pygls.workspace.Document):
    pass

pygls.workspace.Document = MyDoc

unless you want to contribute to pygls to make this possible.. :)

danixeee avatar Aug 19 '20 10:08 danixeee

I could try. I was just wondering if you already know how this should be implemented in pygls.

m-kru avatar Aug 19 '20 12:08 m-kru

I would agree that is by far the easiest method to override specific classes in Python.

Still, for much of your "internal" code and logic, it might be wise to work with custom classes you maintain in your own package. Writing tokenizers/lexers/compilers often comes with its own specific need for storage of information. I've been using sly to do some of the hard work, which naturally results in mappings to and from sly and pygls.

You could write up a parallel (but probably highly LSP inspired) implementation and provide a small interface module to "talk" with editors through pygls. Such a module is probably just some mappings and conversions of trivial fields, which shouldn't be too hard to maintain.

TiemenSch avatar Sep 22 '20 12:09 TiemenSch

Closing just due to having been around for a long time without replies. Very happy to re-open if there is still a need.

tombh avatar Dec 03 '22 20:12 tombh