Announce: LitREPL plugin for literate programming

[Sergey Mironov]

Hello. I'm glad to announce a (yet another) plugin for literate programming, for now in Python. Briefly, it aims to get a Jupyter-notebook look-and-feel while editing Markdown or Latex documents in Vim.

https://github.com/grwlf/litrepl.vim

The plugin detects code/result blocks, pipes their content through the persistently running interpreter and pastes the result back into the file. Python and IPython are currently supported, other languages don't seem to be a problem.

Currently, the plugin comes with an application of nearly 500 lines of code and takes less than 100 lines of code itself at the cost of being dependent on Posix APIs like pipes or shell utils.

The project is less than a month old, some troubles are possible. Brave testers are welcome, as well as comments.

BR,

Sergei

[N V]

Hi Sergei, 

Do you know codi.vim ? 

https://github.com/metakirby5/codi.vim

What's the main difference with your plugin ? 

Thank you

Nicolas 

[Sergey Mironov]

Hi Nikolas!

Somehow, Codi.vim escaped from my attention, thanks for letting me know. At first glance, I would name the following differences:

- Codi.vim seems to work on a line-by-line basis. As far as I see, it doesn't attempt to guess the structure of the document. LitREPL (in theory) works with valid Markdown/Latex documents. It uses its own express-parsers to find out the location of multi-line code/result sections, and transforms the document accordingly, making it possible to emulate a WYSIWY(with a little delay)G.

- Codi.vim doesn't seem to preserve the state of the interpreter between editing sessions. LitREPL, in contrast, keeps the interpreter running with its stdin/stdout connected to pipes which are pinned as files in the filesystem. It is also possible to get direct access to the interpreter's shell. As a possible downside, LitREPL depends on certain Posix tools to make things work.

- Codi.vim is implemented mostly in Vimscript, while LitREPL depends only on a small Vim-script wrapper while most of the work is done by a command line application written in Python. Probably, porting LitREPL to other editors should be an easier task.

- There are probably other minor differences like the support of ASCII '\r' symbol required for libraries like tqdm of Python (I see the support of Preprocessors in Codi.vim, so may be it does have the required support), the status of Ctrl+C support (LitREPL should support breaking the infinite loop), other behaviour on long-running commands (I plan to support the incremental output in LitREPL via files), etc.

BR,

Sergei

пт, 2 сент. 2022 г. в 14:11, N V <niva...@gmail.com>:

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/bc99067a-71d0-44b3-bc8e-72bb5af21893n%40googlegroups.com.

[Sergei Mironov]

An update on LitREPL:  plugin now supports asynchronous code block execution for individual sections. When the section is run, LitREPL waits for immediate response from the interpreter and returns control back to the user if no response is seen. Re-evaluating the code section updates the document with the latest output from the background process.

BR,

Sergei

пт, 2 сент. 2022 г. в 15:11, Sergey Mironov <grr...@gmail.com>: