Yes, the protocol first step is about "Documents" What do you think would be the best thing for "Document" besides "ChangeSet"? We can have $root/packagename/classname/[class|instance]/protocol/method.st mapping with method as document but there would be quite a lot. $root/packagename/classname_[class|instance].st may be a simpler mapping but editing and save will be complicated. Why did you go the way you went for SOM? Phil On Wed, Feb 8, 2017 at 9:47 AM, Stefan Marr <smalltalk@stefan-marr.de> wrote:
Hi Ben:
On 8 Feb 2017, at 08:01, Ben Coman <btc@openInWorld.com> wrote:
Just a very brief thought, to wonder being a Language Server Protocol client might be a path to polygot programming in Pharo. Or if providing a LSP server might be a bridge-head for Pharo to be integrated into larger projects.
* http://langserver.org/ * https://github.com/Microsoft/language-server-protocol/blob/ master/protocol.md
Just to report on my experience with the language server protocol. Most IDEs supporting it assume that you got a file syntax to start from. So, that would seem like the biggest hurdle, if you arenât happy with change sets.
Beside that, providing a basic language server for Pharo should be pretty simple. You got already all the functionality in the image, and merely need to expose it via the language server protocol to be consumed by for instance VS Code. So, that includes simple parser errors, lookup of senders, documentation or even code critique results.
To get an impression of how that could look for a Smalltalk-like language, check the screenshots here: http://stefan-marr.de/2016/08/can-we-get-the-ide-for-free-too/
and here: https://marketplace.visualstudio.com/items?itemName=MetaConcProject.SOMns
Thatâs how it looks for Newspeak/SOMns.
Best regards Stefan
-- Stefan Marr Johannes Kepler Universität Linz http://stefan-marr.de/research/