This will allow us to remove grainfind.js support and still align flags between compiling and the LSP.

Syntax highlighting seems to mess up on record attached to an enum constructor I know this a hard problem given { and block statements often get confused but figure its still worth the issue.

We should use scope entity.name.type.numeric.

Syntax Highlighting issue when it comes to division symbols as can be seen here

While working on a pr for grain I stubled into the lemire.gr file and the syntax highlighting was completly messed up for some reason.

I'm looking at this example on https://grain-lang.org/docs/constructs/bindings

let rec isEven = (n) => {
  if (n > 1) {
    isOdd(n-1)
  } else {
    n == 0
  }
}
and isOdd = (n) => {
  if (n > 1) {
    isEven(n-1)
  } else {
    n == 1
  }
}

And the and is white, instead of the blue of let and rec.

I'm not sure if this is just a bug on the website or in here.

To improve the installation process for non-vscode users, it might be nice to:

• Publish the server package on npm
• Add a bin entry to its package.json like "bin": { "grain-language-server": "./out/server.js" }, so it's easily runnable when installing it from npm.

With my work on getting the Grain compiler to work on Windows, I wanted to test the LSP. However, I ran into a couple of issues.

Upon startup, this is logged:

[1125/135810.399:ERROR:registration_protocol_win.cc(103)] CreateFile: The system cannot find the file specified. (0x2)

And then if I turn on tracing, I get this error a single time and then nothing else (even upon changing the file, etc):

Validating file:///c%3A/Users/User/GitHub/grain/test.gr
Exception:

When debugging on Windows, I found that my LSP information was incorrect. This seems to happen when the file is using CRLF line feeds instead of LF. I switched to LF and everything started to work.

In #45, I added an if statement to add an error on line 1 if your code has CRLF, but I think we should just fix the compiler to support them.

Works fine if the type isn't parameterized.

Oscar said he really wanted this.

VSCode supports multiple root level folders in a workspace.

The vscode server implementation doesn't yet support determining on the server side which root folder a file is found in.

This is more obvious where the folders are in distinct paths but not when the folders are inside each other.

I'd suggest sorting the root folders by length and then matching the URI of the file against the most specific folder URI to determine the best matching folder.

You then need to track per folder if there's a build script, and to use it to compile if it exists. We currently use chokidar to monitor these files, so that monitoring would need to be reset

There is an event sent when the workspace folders change to allow this to be recalculated.

Probably using this: https://github.com/PanAeon/vscode-tmgrammar-test

I'm not exactly sure about the performance of the JS compiler vs the filesystem access stuff, but if we could solve that and make it performant, we might just want to ship the JS compiler with this plugin instead of looking for an installed Grain (or maybe use it as a fallback?).

1.23e-3 doesn't highlight correctly.

Grain allows infix operators to have double slash or slash star characters in them (though this is disallowed at the beginning of the operator).

VSCode seems to provide file paths with a lowercase drive letter (actually, it's even more weird, file:///c:/Users/User/...) and we do a bunch of normalization in order for the Grain compiler to work. For Packaged Grain, it fails if the drive letter is lowercase, so in #45 I needed to add a normalization that capitalized it. We should figure out the more proper fix.

grain-lang/grain#670

Instead of doing our own operations on URI filepaths, we might be able to use https://github.com/microsoft/vscode-uri

We already use it on the website, and it's planned syntax anyway.

Microsoft marketplace does only allow running their extensions from within VS Code (legally that is). There are other Code-based (i.e. Eclipse Theia, VSCodium) or simply vsx compatible (Onivim) editors out there that could profit from it. There's actually growing amount of users that refuse to use the MS-branded builds because of their aggressive telemetry and use the aforementioned VSCodium instead.

We have not added syntax highlighting support for the new and syntax added in v0.6 yet.

Once grain-lang/grain#1472 is merged into main we will need syntax highlighting for Infinity and NaN

Julia, FSharp, and many other languages have a “compile” button at the top right of VSCode.
They also allow evaluating code by selecting it and hitting shift+enter.

Grain seems to allow nothing of this, I don't know how to compile code.
(Other than in the terminal, of course)

It looks like the new include syntax isn't handled perfectly just yet.

We should highlight the identifier after the as properly

add highlighting for syntax like 0x1.4Ap5

Screenshot:

In grain-lang/grain#570, a binary packager was added to Grain; however, the VSCode extension's LSP doesn't work with them.

I have tracked the issue down to this line: https://github.com/grain-lang/grain-language-server/blob/master/editor-extensions/vscode/server/src/server.ts#L304 - it seems that when specifying input to node's execFileSync that it isn't actually flushing that input into the 0 file descriptor (stdin), but instead creating its own pipe and binding that to stdin.

I verified that normal stdin works using

$ ./grain lsp test.gr < test.gr

Refactor the code to make our Grain executable locator code a reusable function (and also handle Grain executables with non-standard names)

With Packaged Grain, people might now get Grain into their path with different names, such as grain, grain-mac-x64, grain-linux-x64, or grain-win-x64.exe (additionally, grain.cmd might be there when building from source on Windows). These might also be available in the local directory because Packaged Grain is portable.

We should do some sort of lookup to see which Grain is available to use.

You can specify a custom standard library for Grain using the --stdlib flag. We pave over this behavior in the CLI by pointing at the bundled stdlib by default, but if someone is using the flag to compile their code, this LSP won't behave correctly.

I'm not sure how to solve this in an elegant way but wanted to open for posterity.

vscode textmate syntax highlighting issue it can be seen on line 1632 of string.gr in the stdlib happy to make a github issue if you guys want

The syntax highligthign for entries is colored as if it were a function when it is not one.

I was trying to abstract my Advent of Code stuff, so I split their input into a new file and it ends up breaking my type hinting.

This is my file:

import Array from 'array';

import { data } from './data';
// import { data } from './sample-data

let allPairs = Array.product(data, data);

let (a, b) = Array.find(((a, b)) => a + b == 2020, allPairs);
print((a, b));

print(a * b);

Where data is just an array of numbers

In The Code Below The Division Symbol is getting recognized as a comment,

import { sin, cos, pi } from "number"

print(sin(90))
print(cos(90))

/**
 * Computes the tan of a number (in radians) using Chebyshev polynomials.
 *
 * @param radians: The input in radians
 * @returns The computed tangent
 *
 * @since v0.5.2
 */
export let tan = (radians: Number) => {
  sin(radians) / cos(radians)
}

as can be seen here.

The inlay hints added to the lsp are an awesome addition but not for everyone especially if we add them in other places in the future such as we inlay positional argument names. It would be nice if we had a toggle to turn these off in the vscode extension.

Example of implementation:

A note on this as well is that vscode allows for a global toggle of inlay hints but this probably isnt the best. given you might very easily want module hints but not want something like type hints.

LSP mode is capturing errors, but warnings are printing out and not being captured into the JSON

As an example

marcus@penguin:~$ grain lsp test.gr < test.gr
File "test.gr", line 9, character 0-line 13, character 1:
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a case that is not matched:
Pepperoni
{
"errors": [],
"values": [
{

This can be done as soon as this lands: microsoft/vscode#110830

Highlighting issue with export when exporting an operator

Currently the grain lsp only reruns when you modify the file this is nice but if you are fixing an issue in another file and come back that error is still there until you change it, it would be nice if on refocus to the file the lsp reran.