Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

don't give me compile error, look for definition (rust) #41

Open
kkharji opened this issue Feb 14, 2021 · 4 comments
Open

don't give me compile error, look for definition (rust) #41

kkharji opened this issue Feb 14, 2021 · 4 comments
Labels
LSP will require a LSP, nvim 0.5, and a lot of work

Comments

@kkharji
Copy link

kkharji commented Feb 14, 2021

No sure what better name to give it 😆

Is your feature request related to a problem? Please describe.

Yes, coming lisp languages when I run a block it automatically look for the definition and attach it then give an output

Describe the solution you'd like
A clear and concise description of what you want to happen.

When running a code and behind the scene there is a compile error, then look for definition in current buffer and evaluate them with the block. perhaps go over the line a bit and search the project.

@michaelb
Copy link
Owner

michaelb commented Feb 18, 2021

yep, that's what the support levels File, (in special case of external imports) Imports, Project and even system are about.

However, those are really tricky to implement. It's still really within the scope of the project, and i've already done conclusive tests on rust and python. However, all the solutions I've come up with needs either a LSP or treesitter. Using those works, but upstream changes broke my tests enough that I decided to wait for stable 0.5 to spend more time on that: rejoice, neovim 0.5 is due for very soon!

The idea behind the File support level is that if you print(foo(a)) it will go search for the definition of foo and whatever value a has. Like you can guess, this is very very tricky, for functions you can have recursive dependencies (where foo() needs bar()) etc.. and variables can be modified somewhere between declaration and print.

Depending on the language you are working on, (python, R and bash would be already working, but since I saw you actively asking question around the rust discord, i guess rust) you could use the REPL mode: that would enable you to sniprun the function definition and later the print. Not ideal again, but I can't achieve more without Treesitter or LSP

@michaelb
Copy link
Owner

(if you're interested, REPL mode for Rust could in theory be implemented quite easily, since there is a Jupyter kernel for REPLing rust (evcxr) and a python jupyter kernel is in master)

@kkharji
Copy link
Author

kkharji commented Feb 18, 2021

Oh yah this requires treesitter and lsp as said, maybe also lsp. with treesitter it might be easier to just get parse tree that has all the function defined in the workspace, then filter on function_item. It is very tricky but i believe it might make rust dev in neovim with sniprun unbelievable experience. I might play soon with treesitter and rust and If I have working prototype I will open a pr.

For creating a repl, well I'm kinda starting out with rust and I'm not sure I can handle it but keep me updated if you dag into this interesting rabbit hole

@michaelb
Copy link
Owner

michaelb commented Feb 18, 2021

it's 100% a rabbit hole project, i should have been doing school ones instead for a long time, and treesitter is not stranger to my condition.

Treesitter is very fun to play with, though not simple, whereas a REPL is very simple (conceptually and in the code) but not really fun to do.

I plan to do both for rust soon, as long as my internship doesn't make me (want to) work on weekends.

This project was made to be really easily contribuable, so as long as you don't change sniprun itself or do too much treesitter, I think whatever type of contribution is left is within the reach of a Rust beginner (i'm no expert myself). I think that as long as the syntax, what is Result and the concept of ownership is understood there's little to be afraid. The macro and build system, as well as more complicated async stuff does not need to be modified for most types of contribution.

You're right to think that the use of TS/LSP will be the Holy Grail of this kind of thing, i'm excited to do this!

@michaelb michaelb added LSP will require a LSP, nvim 0.5, and a lot of work and removed treesitter labels May 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LSP will require a LSP, nvim 0.5, and a lot of work
Projects
None yet
Development

No branches or pull requests

2 participants