Show HN: Codi.vim – An interactive coding scratchpad for interpreted languages
github.commeta: If you can still edit the title, you can add a "Show HN:" to the title: https://news.ycombinator.com/showhn.html, otherwise I hope a mod will do so.
content: looks very cool. Does it still work cleanly if you e.g. open and parse a file (I assume later loads come from the file system cache and are quicker, but still), or do complex operations? A lot of my use case for REPL programming is breaking down data from log-like files, where some steps take seconds.
Can I maybe "pin" lines that should not be rerun every time?
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 `!!`?
P.S. If anyone's interested in the process I used to record the gif:
https://github.com/metakirby5/codi.vim/blob/master/assets/pl...
Note that some characters I've typed like <esc> and ^A won't show up in your web browser. I recommend you edit with a text editor to see everything properly.
Interesting, I wonder what are the performance / overhead on "long statements", I see there is support for async. Is it vim's own async system or NeoVIM's async system is supported as well?
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