Replace Jupyter with Emacs Org Mode: Unleash the Power of Literate Programming
michaelneuper.com
michaelneuper.com
A diff-aware org-latex import would be amazing for this actually, like if pandoc could do tex -> org but align all the code blocks / generated figures
Re: the fourth point, "version control", it requires a few hoop jumps if you really want nice diffs, like using "jupytext" either manually or via commit hooks. However, given that native .ipynb diffs are now rendered on GitHub, I'm not sure those tools will be worth the effort for an average user.
// disclaimer: I did use emacs as the main editor for half a decade, am quite familiar with org-mode... and I still think nothing replaces magit as a git client, but that's another unrelated discussion
> // disclaimer: I did use emacs as the main editor for half a decade, am quite familiar with org-mode... and I still think nothing replaces magit as a git client, but that's another unrelated discussion
Aren't you agitated by the lacking the window management, inability to always use the keyboard, use of macros, and lack of `C-h k`?
- full-blown super-configurable window management is barely needed for dev work aside from several editor panes, being able to quickly switch to terminal/vcs, being able to jump to any recent file or any open tab by fuzzy searching or shortcuts, etc - all of this exists in base vscode
- I'm 99.9% cases I can use the keyboard, especially with vim keybindings. There's also command palette for almost every possible action
- C-h k you can pretty much replicate (to an extent) by binding recordSearchKeys together with openGlobalKeybindings
- Macros: global-level macros are not a thing in vscode unless you use third party plugins or hack something yourself. However, in vim mode you have all of the vim macro functionality which covers most of the typical use cases
All in all, there's pros, there's cons. Emacs will always remain more configurable but suffers as an actual dev tool.
Oh no... my opinion got confused as sarcasm :S
No sarcasm here though!
> full-blown super-configurable window management is barely needed for dev work aside from several editor panes, being able to quickly switch to terminal/vcs, being able to jump to any recent file or any open tab by fuzzy searching or shortcuts, etc - all of this exists in base vscode
Last I paired with someone that used vscode there wasn't an equivalent for simply doing `C-x 3` from the keyboard and you had to use the mouse.
Being forced to use the mouse in many situations was my main point here.
> I'm 99.9% cases I can use the keyboard, especially with vim keybindings. There's also command palette for almost every possible action
Ah, okay. I've never seen anyone use the vim keybindings in vscode and haven't used them myself in vscode.
> C-h k you can pretty much replicate (to an extent) by binding recordSearchKeys together with openGlobalKeybindings
Good to know.
> Macros: global-level macros are not a thing in vscode unless you use third party plugins or hack something yourself. However, in vim mode you have all of the vim macro functionality which covers most of the typical use cases
I'm assuming you are not counting "split git log of commits to the right, go to first one, add comment to top of file, go to next git log item, repeat" as a typical use case?
Or the same for a macro operating on search results.
> All in all, there's pros, there's cons. Emacs will always remain more configurable but suffers as an actual dev tool.
Not in my experience. I've used vscode a bit and just have a fuzzy memory of what felt like endless small annoyances.
1. (By default) before you can use Python source blocks, you need to have the Org Babel Python functionality loaded which is most easily done by evaluating the elisp (require 'ob-babel), but there are other ways also [1].
2. The first example, which uses the print function, will not output anything because the Python blocks by default are evaluated inside a function body and the return value is returned to Org [2]. To return the printed output instead, you need the header argument ":results output". There is an example of this syntax later in TFA.
3. If you are serious about replacing (or complementing) other Jupyter tools with Org mode, you might want to eventually look at emacs-jupyter [3], which provides a more advanced handling of outputs and also supports other (i.e. non-Python) kernels.
Also, I don't think I've ever seen anything like the debugging example and when I tried to replicate it out of curiosity, the block simply failed with a bdb.BdbQuit exception. Am I missing something? What is supposed to happen?
[1] https://orgmode.org/manual/Languages.html
[2] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-...
snark aside, it’s slower than every other modern editor i’ve tried (after i get it configured). part of it is no doubt what i’ve done to it, but shit, if it’ll take me 2 years to learn it and turn it into something equal parts fast and functional then i’m probably not the target audience.
back to helix!
https://www.gnu.org/software/emacs/manual/html_node/elisp/Na...
In contrast, Jupyter can be installed and used almost immediately by almost everyone.
Reading the article again; it's clear that it's written in a style that only another Emac users can understand. Anyone new to Emacs hoping to do this will be turned away. I've had a 1-year stint with Emacs and it wasn't really all that pleasant.
*I understand it's under still active development, but it is not receiving any modern UI improvements - and a good chunk of it is still single-threaded. Elisp also holds it back, and time spent "learning" Emacs is best spent advancing things that are more relevant.
Just not with Electron, please.
Obviously, VSCode isn't as extensible as Emacs is; and isn't free-as-in-freedom. (And a few people understand 'emacs' to mean its non-modal keybindings that readline / macOS adopt, like C-a and C-e).
VSCode's command palette (which includes the keyboard shortcuts) reminds me of a nice Emacs M-x menu.
As is its tight integration with developer-environment tools while still remaining lighter weight than a more typical IDE. -- e.g. its git editor, its terminal and console output, and a repository of plugins/extensions.
Emacs is so slow, constantly broken, and filled with a community of people who blind to it's problems.
That said, I still use it for org mode, calc, and editing random text files and for that it works well.