Show HN: Codi.vim – An interactive coding scratchpad for interpreted languages (opens in new tab)

Thanks for the advice about "Show HN:" :) It's my first post here, so I really appreciate it.

Opening a file works fine, as well! However, further loads are actually not from any cache. I decided against caching, because it becomes very difficult to add new language support if state persists between evaluations. To retain speed, Vim's asynchronous jobs are used if available. Complex operations will obviously take longer to show, but they will not interrupt typing. There's a big warning about trying to print infinite lists in Haskell, though ;)

The typical use case for Codi is trying out short code snippets to see if they do as you expect, or as a calculator where you can use your favorite interpreted language. Processing a lot of data is not really a good use case, but it's possible because the previous job is cancelled with every keystroke; it shouldn't be any slower than running it normally.

Pinning is a great idea. I'm not sure how it would be implemented, as anything you type in the buffer could be interpreted as a line to evaluate. Maybe a special directive like `!pin`, and escape exclamations via `!!`?

The performance is the same as if you ran everything you've typed on an interpreter - that's what it's doing behind the scenes, anyways. That means if you write `sleep(1)`, it's going to take a second to show the results. Previous jobs are cancelled on keystroke though, so (if there aren't too many bugs) it should be only running one interpreter at any given moment.

But yes, it does use Vim's async system (if you have +job and +channel), so your keystrokes aren't interrupted even if the code takes awhile to run. If Vim doesn't have support for those, it falls back on synchronous execution on CursorHold events. Currently, NVim's async is not supported, but it's in the works on an experimental branch @ user/metakirby5 :) Check out the discussion at https://github.com/metakirby5/codi.vim/issues/5