Closed jdtsmith closed 2 years ago
OK I took a look and polymode is pretty easy to setup. The results so far are quite encouraging (see below with python-mode and markdown-mode commingled, all while running lsp-mode!). There are a few rough edges: poly-mode and code-cells fight over who gets to style the header lines, and the various markdown commands for toggling structure "leak out" of the markdown blocks, but it's a good proof of principle.
This is really like a "poor man's Jupyter notebook". But even beyond the convenience of editing in Emacs, in some ways it's better. It is, and always remains, a python file, so you can send the whole thing to the interpreter, run as a script, send any random region you want (vs. total cell-at-a-time notebook approach). You can have rich documentation, without a special format, the need to "tangle" content, etc. Lsp servers can happily chew on the file and give feedback (and occasionally complain about various things in your strings!). You can drop into debuggers and navigate tracebacks.
Stuff I think will make this really useful (some of which is probably out of band for you):
super-[Ret]
.Thoughts?
Hi JD, thanks for sharing your impressions.
I took a quick look at polymode some time ago and somehow couldn't figure out how to use it, or didn't think my solution was robust enough. What's the setup code involved in the screenshot you posted? Maybe it's something useful to share in a wiki?
About your bullet points:
Points 1 and 2: I was thinking about something simpler and more specialized than polymode to deal specifically with comment blocks written in markdown or other simple markup language. In other words, make Emacs deal better with some text appearing after a column of #
signs (fill paragraph, basic font locking).
Point 3: I decided to only bind keys under the prefix C-c %
, but I included an example in the Readme where more handy bindings are included in code-cells-mode-map
. I think this should remain a user customization, do you agree? I think the super
modifier should remain reserved for window manager shortcuts (of course it's always fine for the user to do whatever in their private configuration). If you would like to expand on what "convenience commands" are missing, I'll consider adding them.
Point 4: consult-outline
and similar commands do this already, no?
Point 5: not sure how this could look like, but if you can give a more concrete suggestion I'll consider adding it.
Thanks. I've been playing with polymode and have gotten it working pretty well. I really like the approach you have showed here of "block-comments or multi-line strings" for markdown, so that the file stays syntactically valid all the time, and lsp-mode/flycheck/etc. are much happier. Feels like the right balance to me. I've also mixed in outshine as a really good outline upgrade, that basically handles everything you'd want for nested code block collapse/TOC/select/edit. With some patches it does a great job styling, etc. Once I get it working well I'll write up a gist.
I think aside from import/export of notebook format, it handles basically everything. Any thoughts about factoring out that part into a supporting package?
In case you missed it, having a discussion with the polymode author over at polymode/polymode#305. They are interested in contributing to a python-polymode.
@jdtsmith I would be interested in that gist to see where you got with outshine, polymode etc.
Just playing with this. Advantages over org-mode: it's "just a plain code file" (e.g. python with markdown), so no special exports, conversions, tangling, etc. are needed. Quite simple. I like the default horizontal lines for demarcating cells.
Have you tried configuring this with mmm or polymode, to use markdown as the "inner mode", on
#*** This Title [markdown]
sections? That plus TeXfrag to preview markdown-latex equations in-buffer would replicate much of the functionality of a Jupyter notebook for me.