Tab Completion? about diceroller HOT 12 OPEN

I'll take a look at the autosuggest; my primary goal right now is to get 4.2.0 out the door in the next couple weeks and I'm currently wrapping that up (it's mostly documentation work at this point, but that work also takes a fair amount of time)

from diceroller.

The library uses ANTLR to generate its parser, and it may be possible to wire into that to see which tokens it would expect next as the user is typing. In terms of what the library would offer for this, I could see an API where you feed it a string of what the user has typed so far, and it returns some structure that indicates completions. Exactly how this would be implemented, I'm not sure. Autocompletion for a language with a defined grammar plus the ability to add custom stuff (custom extras or custom functions) seems like it's getting pretty close to a regular programming language, so implementing a Language Server Protocol endpoint may be the easiest way of going about this; it would in theory allow using existing libraries to drive the autocompletion.

What are your thoughts on that?

from diceroller.

I haven't had a ton of experience using ANTLR, and my knowledge of language servers is limited.

That said, from my naive position, a full language server seems like overkill, and I worry that it's possibly a bigger time sink then most would expect to implement this.

However it would be very very cool if easy enough, working, and relatively performant.

Do stand-alone language client libraries exist, that would allow this to be easily hooked into say, a forum or browser based virtual tabletop?

or would half of vscode need to be included, 'just' to get autocomplete?

from diceroller.

language server protocol is 2000% overkill for this, but I can't find anything else already standardized for autocompletion in this sense. I'd prefer to use an existing protocol/library for this rather than inventing something bespoke if possible, to reduce workload (both on myself and people implementing this library in their apps). However, language server protocol may end up causing more work, not less.

from diceroller.

If going down the LSP route, it would mean every consumer would need to have (yet another) server set up.

Yes something bespoke would make it (potentially) harder to cater for, but we could likely cover 90% of the cases with the following.

https://github.com/oranoran/antlr4-autosuggest/ is a library that claims to be able to do autocompletes on Java for antlr4 syntax.

It also has a python script that (rather painfully) ports the Java code to JS.

It's rather a small library having a quick look at the code (for java).

So, if DiceRoller was able to integrate it's Antlr grammar successfully with that, We'd have the easy win of it working on Java and Javascript clients. (with no server component needed).

This clearly doesn't fix the issue for every potential client language though, so here remains the question, is it easy to port to C#? Is it easier to port that to C# then creating your own autocompleting language server from scratch?

Because, considering DiceRoller is written in C#, once you nail C# you have nailed everything using it, as they could always (as you originally planned to do) write their own little communication protocol to hook into DiceRoller however they wish. Or simply use the result of the Java/JS autocomplete libraries.

I havn't done any actual investigation into how easy/hard it is, just a bit of searching.

P.S. Sorry for the delay in replying, I lost a draft reply that I swear I posted.

from diceroller.

I've since discovered https://github.com/mike-lischke/antlr4-c3 and reading through the issues, various people have had success in using it to write language servers for vscode.

https://tomassetti.me/code-completion-with-antlr4-c3/

https://neuroning.com/post/implementing-code-completion-for-vscode-with-antlr/

However, it's typescript.

Would a project implementing autocompletion/autosuggest in Typescript, be satisfactory?

from diceroller.

There does appear to be a C# port, but it's a year and a half out of date. https://github.com/mike-lischke/antlr4-c3/tree/master/ports/c%23

from diceroller.

Would a project implementing autocompletion/autosuggest in Typescript, be satisfactory?

I think so, especially since WASM is becoming more and more of a thing. I have plans of targeting Blazor with this project as well so that it can be consumed via js (whether client-side or server-side) but haven't dug into any of the technical aspects of that yet.

In terms of integrating it directly into this project, the main means of doing so would be making use of ANTLR's error recovery mechanisms; basically you feed the current string into the parser, and the errors would highlight what tokens are expected next. We can take that list of tokens and expand it out into the actual strings that could be valid for the next bit of the roll. I haven't had time to meaningfully touch this library for a while, but if someone (such as you!) wants to take a stab at it, I'd be happy to assist with reviews, testing, or just chatting about architecture.

from diceroller.

Disclaimer: I'm prone on giving up on projects, and chasing all-sorts.

That said, I've currently checked the project out, and have attempted to create a second project in the solution to start playing with the C# port of antlr4-c3

However, all my professional C# experience has been with projects that have already existed, and had Nuget dependencies all set up, and the project/solution files of C# projects frankly intimidates me, since I learned C# after learning Java from Minecraft Modding, I have extremely limited experience with Project Setup, as I basically just transferred my skills, learnt the difference, and learnt the libraries.

At current, I've just managed to create a hello world project inside of DiceRoller, with the intent that there be 2 new projects created (testing ignored), 1. being the minimum setup you need to get auto-complete working, to be used as a library, and 2. being an example server capable of limited, in memory, play by post/chat, and any required serverside glue-code to serve auto-completions, to attempt to encourage others to use the full capabilities of this project, instead of just using it as a dice syntax parser.

I'd expect, at some point if this side-project prove fruitful (ideally), that the documentation on syntax that you have hosted would be stored in a translatable resource, that could be used in various popups.

I think that if your plan is to eventually target Blazor, that as long as the C# port proves functional, that it would be best to keep as much of this in C# for the moment, to aid in portability down the road, leaving only a basic client.

The Example Server may act as a LSP, not sure how I want to go with that yet, as most of the articles I read, said that LSP's tend not to be as portable as you would think, and usually require a client made for each platform anyway. It's my intent to at least explore that option at some point, as I believe it could be useful for advanced macro programming in various game systems using DiceRoller.

Like I said, most of this is very idealistic, but I need to start somewhere.

from diceroller.

I'm running into frustrating issues with .net versions not matching between projects, and multiple version antlr dependencies causing chaos, and don't have the skills/knowledge required to solve it.

1, what's the difference between:

https://www.nuget.org/packages/Antlr4
https://www.nuget.org/packages/Antlr4.Runtime.Standard
and https://www.nuget.org/packages/Antlr4.Runtime

(It appears to me that CCC uses an alternate antlr C# antlr target then DiceRoller does)

2, Does DiceRoller need .net452 support? a C# Discord basically chewed me out for even supporting something so old, even though it wasn't my project.

and 3,
Is it appropriate to target .netstandard2.0 for something that will be run standalone, and not necessarily consumed as a library?

from diceroller.

.NET Framework 4.5.2 can be dropped; support for it in the library was announced as deprecated a while back and subject to removal anytime after April 2022. The base library should continue to support .NET Standard 2.0 at this time with a release note that 4.6.x is deprecated. I’ll make some tweaks to the build for all of that.

Your tool wouldn’t need to face the same backwards-compat constraints as the main library, so targeting .NET 6.0 (for example) would be fine.

from diceroller.

@ryantheleach I've updated the project/solutions to not rely on .NET Framework 4.5.2 anymore, so should be all good in that front. For the Antlr thing: Antlr.Runtime.Standard is the official C# target and is the most up-to-date. The other target is older and predated the official one, but is no longer being developed.

from diceroller.