5 ms·

Replace Jupyter with Emacs Org Mode: Unleash the Power of Literate Programming

41 points by nemoniac 4y ago

deafpolygon 4y ago
This is just going backwards. There's far more to using Emacs than simply firing it up - the software is arcane, hasn't been updated* in a long time, and could really use a modern re-imagining. 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.
- subjectsigma 4y ago
  “I didn’t like Emacs personally so anyone using it is holding back progress”
  - KyeRussell 4y ago
    “I like emacs and I’m blind to its objectively archaic UX paradigms”.
    - burakbayramli 4y ago
      "I never liked Emacs I don't see the point of quick key combinations when minute-long mouse clicks could get you the same thing and look visually awesome like a bright shiny object looks to a fish"
    - jabradoodle 4y ago
      I use emacs for it's UX. If you don't like it, use something else.
  - smabie 4y ago
    To provide another perspective, I used Emacs for over a decade before switching to jetbrains products and couldn't be happier. Everything just works so much better. 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.
- slavapestov 4y ago
  > and could really use a modern re-imagining. Just not with Electron, please.
  - rgoulter 4y ago
    As I see it, VSCode takes a bunch of inspiration from a well set up Emacs. 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.
    - comfypotato 4y ago
      Worth noting here that the command palate is almost directly from sublime. (It’s predecessor may have been Emacs, or text mate, I’m not sure.)
- yakubin 4y ago
  I agree about Elisp and single-threadedness, but disagree about the UI. It’s the best UI I’ve ever used. I wish others apps used Emacs UI concepts.
- eigenspace 4y ago
  What? I don't think you at all understand what you're talking about.
- jabradoodle 4y ago
  It's not a commerical product, it isn't being held back, it is being used and contributed to by those who like it. There are alternatives with more user share, that is not a problem.
rsfern 4y ago
I love org mode for scientific writing (especially with org-ref [0]) but it’s just not very convenient for collaborative projects because there are very few emacs users (in my field at least). Overleaf has been workable in my experience, but I still get pushback sometimes. 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 [0]: https://github.com/jkitchin/org-ref https://github.com/jkitchin/org-ref
wkdneidbwf 4y ago
i hope that one day i’ll have a computer fast enough to run emacs crisply. 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!
- wara23arish 4y ago
  What version are you on? I use it within a VM with lsp and a bunch other stuff running and its good for the most part.
- dmm 4y ago
  emacs 28 includes native compilation of elisp. If performance was keeping you from using emacs, it's worth another try. Performance with large files is also much better. https://www.gnu.org/software/emacs/manual/html_node/elisp/Native-Compilation.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Na...
  - all2 4y ago
    Does it still run in a single thread?
    - dmm 4y ago
      emacs supports async io concurrency and some form of threading. Modes have to be designed in a way that takes advantage of them though.
    - ParetoOptimal 4y ago
      Yes, but tryout elfeed and call `update-feeds` and you'll see that's not a hard blocker on it's own.
burakbayramli 4y ago
[dead]
aldanor 4y ago
Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. You get full IDE-like experience aware of all your local packages and external packages, typing resolution, Copilot, any editor customisations like vim keybindings etc. I don't think it just gets any better these days. 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
- ParetoOptimal 4y ago
  > Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. You get full IDE-like experience aware of all your local packages and external packages, typing resolution, Copilot, any editor customisations like vim keybindings etc. I don't think it just gets any better these days. > // 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`?
  - aldanor 4y ago
    Not sure if this is an /s comment or not, but: - 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.
fooofw 4y ago
For anybody following along with the examples, a few points/tips that might help newcomers: 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 https://orgmode.org/manual/Languages.html [2] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-... [3] https://github.com/nnicandro/emacs-jupyter https://github.com/nnicandro/emacs-jupyter

41 points by nemoniac 4y ago

This is just going backwards. There's far more to using Emacs than simply firing it up - the software is arcane, hasn't been updated* in a long time, and could really use a modern re-imagining. 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.

subjectsigma 4y ago
“I didn’t like Emacs personally so anyone using it is holding back progress”
- KyeRussell 4y ago
  “I like emacs and I’m blind to its objectively archaic UX paradigms”.
  - burakbayramli 4y ago
    "I never liked Emacs I don't see the point of quick key combinations when minute-long mouse clicks could get you the same thing and look visually awesome like a bright shiny object looks to a fish"
  - jabradoodle 4y ago
    I use emacs for it's UX. If you don't like it, use something else.
- smabie 4y ago
  To provide another perspective, I used Emacs for over a decade before switching to jetbrains products and couldn't be happier. Everything just works so much better. 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.
slavapestov 4y ago
> and could really use a modern re-imagining. Just not with Electron, please.
- rgoulter 4y ago
  As I see it, VSCode takes a bunch of inspiration from a well set up Emacs. 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.
  - comfypotato 4y ago
    Worth noting here that the command palate is almost directly from sublime. (It’s predecessor may have been Emacs, or text mate, I’m not sure.)
yakubin 4y ago
I agree about Elisp and single-threadedness, but disagree about the UI. It’s the best UI I’ve ever used. I wish others apps used Emacs UI concepts.
eigenspace 4y ago
What? I don't think you at all understand what you're talking about.
jabradoodle 4y ago
It's not a commerical product, it isn't being held back, it is being used and contributed to by those who like it. There are alternatives with more user share, that is not a problem.

rsfern 4y ago

I love org mode for scientific writing (especially with org-ref [0]) but it’s just not very convenient for collaborative projects because there are very few emacs users (in my field at least). Overleaf has been workable in my experience, but I still get pushback sometimes. 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 [0]: https://github.com/jkitchin/org-ref https://github.com/jkitchin/org-ref

wkdneidbwf 4y ago

i hope that one day i’ll have a computer fast enough to run emacs crisply. 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!

wara23arish 4y ago
What version are you on? I use it within a VM with lsp and a bunch other stuff running and its good for the most part.
dmm 4y ago
emacs 28 includes native compilation of elisp. If performance was keeping you from using emacs, it's worth another try. Performance with large files is also much better. https://www.gnu.org/software/emacs/manual/html_node/elisp/Native-Compilation.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Na...
- all2 4y ago
  Does it still run in a single thread?
  - dmm 4y ago
    emacs supports async io concurrency and some form of threading. Modes have to be designed in a way that takes advantage of them though.
  - ParetoOptimal 4y ago
    Yes, but tryout elfeed and call `update-feeds` and you'll see that's not a hard blocker on it's own.

burakbayramli 4y ago

[dead]

aldanor 4y ago

Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. You get full IDE-like experience aware of all your local packages and external packages, typing resolution, Copilot, any editor customisations like vim keybindings etc. I don't think it just gets any better these days. 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

ParetoOptimal 4y ago
> Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. You get full IDE-like experience aware of all your local packages and external packages, typing resolution, Copilot, any editor customisations like vim keybindings etc. I don't think it just gets any better these days. > // 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`?
- aldanor 4y ago
  Not sure if this is an /s comment or not, but: - 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.

fooofw 4y ago

For anybody following along with the examples, a few points/tips that might help newcomers: 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 https://orgmode.org/manual/Languages.html [2] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-... [3] https://github.com/nnicandro/emacs-jupyter https://github.com/nnicandro/emacs-jupyter