3 ms·

One of my favorite aspect of Emacs is its configuration file. I use an org-mode file for configuration - which means that we can have rich documentation along w

by goku12 3y ago

One of my favorite aspect of Emacs is its configuration file. I use an org-mode file for configuration - which means that we can have rich documentation along with the code - all neatly folded up. The init.el file is just a stub meant to load the configuration from the org-mode file. Even better - the init.el itself is written within the org-mode file. The org-mode file can be executed like a shell script (actually elisp script) to extract the init.el file. Similar executable org-mode files are used to configure the environment (sway) and personal information management (email, calendar & contacts). The latter one got so complicated that I had to add an integration diagram using the draw.io app.

lockhouse 3y ago
The other great feature of Emacs is that its keybindings are so pervasive. Most native MacOS text input widgets and modern POSIX shells like bash and zsh use Emacs-style key binds for navigation and text editing. Also anything that uses GNU readline supports them as well out of the box.
- abhijeetpbodas 3y ago
  Bash/readline also has a vi mode :) https://www.gnu.org/software/bash/manual/html_node/Readline-vi-Mode.html https://www.gnu.org/software/bash/manual/html_node/Readline-...
- supazek 3y ago
  Native emacs keybindings never ever worked for me. I could only use emacs once I got used to evil mode
metroholografix 3y ago
I've always seen this as an anti-pattern. You can make the documentation in an .el file as rich as you want without losing all the niceties that Emacs offers for interactively working with source code (e.g. find-{function,variable} will jump to the ephemeral dynamically generated .el file, not the actual origin of the code which is in the .org file). Why settle for an extra layer of indirection that makes interactively working with source code more time consuming?
- BeetleB 3y ago
  Matter of preference. As an example, I may have a lot of configuration related to package X under one Org node. I merely have to "comment" the node headline to ensure none of that code gets to the config. Your comment reveals your bias - that the code is more important than the commentary. The counterpoint is: No. You can't make the documentation as rich as you want. I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config.
  - goku12 3y ago
    > I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config. Thanks for adding this. Literate programming with org-mode is indeed one of my favorite from Emacs.
  - pxc 3y ago
    > Your comment reveals your bias - that the code is more important than the commentary Yep! That's the key, imo. I love using Org mode wherever I feel that documentation is primary. So right now, most of my code that lives in Org files at work is shell snippets I've used for managing and configuring software. The literate approach is all I need there: I'm keeping track of what configuration I've done, not writing a giant, complicated program. Then I get the added benefit: the Org files form a wiki that I can use to refer colleagues to whether they use or care for Emacs or not! Similarly, tangling shell snippets into scripts lets you write tests for your documentation! The examples become scripts and then the scripts can be run and verified in CI.
- goku12 3y ago
  > Why settle for an extra layer of indirection that makes interactively working with source code more time consuming? I understand what you mean. But it never seemed to be a problem for me. Anyway, the real reason why I ended up with org-mode is that I heavily customize Emacs. The only way to be able to handle that much configuration was to split it up into a dozen or so elisp files. Org-mode's biggest advantage (for me) is that it can manage complexity very well. The org-mode configuration file is neatly divided into topics along with their documentation. The topics are also folded up - so it's very easy to find certain configuration segment.
OO000oo 3y ago
> The latter one got so complicated that I had to add an integration diagram using the draw.io app. Amazing that this is offered up as a selling point. If I didn't know I was reading a thread full of emacs users, I'd think this was a parody of a thread full of emacs users.
- goku12 3y ago
  > I'd think this was a parody of a thread full of emacs users. Haha! Indeed! Let me just clarify what I meant. I have a personal information management (email, calendar & contacts) where all information is stored locally and offline. The advantage is that I will never be locked out of my own data. However, this setup has so many components for syncing the info online and to interact with it. Quite frankly many of those components should be integrated into a single application. For example, mbsync can sync mail to a mail directory. But it needs go-imapnotify to trigger it when I receive a new mail. It's so frustrating that I considered writing those applications myself. In short, Emacs has nothing to do with the complexity. Instead, Org-mode and emacs has actually allowed me to manage that complicated configuration in one place, with lots of documentation. The draw.io diagram was for the information flow between different software components for the PIM and email setup - not for Emacs itself. Coming back to the complicated setup for PIM, I see a lot of new developments that promises to make it simpler. Hopefully, I won't need the org-mode power in the future to rein in the complexity.
  - ParetoOptimal 3y ago
    > In short, Emacs has nothing to do with the complexity. There are many cases where if I didn't have it's features like this I would have to sacrifice ease of use of my full system or hold tons of edge cases in my head.
pxc 3y ago
> The init.el file is just a stub meant to load the configuration from the org-mode file. Even better - the init.el itself is written within the org-mode file. The org-mode file can be executed like a shell script (actually elisp script) to extract the init.el file. Can I see (an example)? Wondering how much goes into that init.el.
- goku12 3y ago
  Sorry I couldn't post earlier. Here is a sample: https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257c51123dcbc https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257...
  - pxc 3y ago
    Thanks!
- nvy 3y ago
  Not OP but here's mine: https://github.com/nathanvy/dotemacs https://github.com/nathanvy/dotemacs The .org file gets processed and the source code blocks extracted into an elisp-only file which is what actually gets executed. Some people prefer an alternate approach[0] with the "stub" init.el that just loads other modules. [0] https://github.com/cute-jumper/.emacs.d/blob/master/init.el https://github.com/cute-jumper/.emacs.d/blob/master/init.el
  - pxc 3y ago
    Thanks for sharing both of these examples!

by goku12 3y ago

lockhouse 3y ago

The other great feature of Emacs is that its keybindings are so pervasive. Most native MacOS text input widgets and modern POSIX shells like bash and zsh use Emacs-style key binds for navigation and text editing. Also anything that uses GNU readline supports them as well out of the box.

abhijeetpbodas 3y ago
Bash/readline also has a vi mode :) https://www.gnu.org/software/bash/manual/html_node/Readline-vi-Mode.html https://www.gnu.org/software/bash/manual/html_node/Readline-...
supazek 3y ago
Native emacs keybindings never ever worked for me. I could only use emacs once I got used to evil mode

metroholografix 3y ago

I've always seen this as an anti-pattern. You can make the documentation in an .el file as rich as you want without losing all the niceties that Emacs offers for interactively working with source code (e.g. find-{function,variable} will jump to the ephemeral dynamically generated .el file, not the actual origin of the code which is in the .org file). Why settle for an extra layer of indirection that makes interactively working with source code more time consuming?

BeetleB 3y ago
Matter of preference. As an example, I may have a lot of configuration related to package X under one Org node. I merely have to "comment" the node headline to ensure none of that code gets to the config. Your comment reveals your bias - that the code is more important than the commentary. The counterpoint is: No. You can't make the documentation as rich as you want. I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config.
- goku12 3y ago
  > I want inline images. Can I put those in an .el file? Links. Tables. Bold, italics, etc. For many, this is more important than the code in the config. Thanks for adding this. Literate programming with org-mode is indeed one of my favorite from Emacs.
- pxc 3y ago
  > Your comment reveals your bias - that the code is more important than the commentary Yep! That's the key, imo. I love using Org mode wherever I feel that documentation is primary. So right now, most of my code that lives in Org files at work is shell snippets I've used for managing and configuring software. The literate approach is all I need there: I'm keeping track of what configuration I've done, not writing a giant, complicated program. Then I get the added benefit: the Org files form a wiki that I can use to refer colleagues to whether they use or care for Emacs or not! Similarly, tangling shell snippets into scripts lets you write tests for your documentation! The examples become scripts and then the scripts can be run and verified in CI.
goku12 3y ago
> Why settle for an extra layer of indirection that makes interactively working with source code more time consuming? I understand what you mean. But it never seemed to be a problem for me. Anyway, the real reason why I ended up with org-mode is that I heavily customize Emacs. The only way to be able to handle that much configuration was to split it up into a dozen or so elisp files. Org-mode's biggest advantage (for me) is that it can manage complexity very well. The org-mode configuration file is neatly divided into topics along with their documentation. The topics are also folded up - so it's very easy to find certain configuration segment.

OO000oo 3y ago

> The latter one got so complicated that I had to add an integration diagram using the draw.io app. Amazing that this is offered up as a selling point. If I didn't know I was reading a thread full of emacs users, I'd think this was a parody of a thread full of emacs users.

goku12 3y ago
> I'd think this was a parody of a thread full of emacs users. Haha! Indeed! Let me just clarify what I meant. I have a personal information management (email, calendar & contacts) where all information is stored locally and offline. The advantage is that I will never be locked out of my own data. However, this setup has so many components for syncing the info online and to interact with it. Quite frankly many of those components should be integrated into a single application. For example, mbsync can sync mail to a mail directory. But it needs go-imapnotify to trigger it when I receive a new mail. It's so frustrating that I considered writing those applications myself. In short, Emacs has nothing to do with the complexity. Instead, Org-mode and emacs has actually allowed me to manage that complicated configuration in one place, with lots of documentation. The draw.io diagram was for the information flow between different software components for the PIM and email setup - not for Emacs itself. Coming back to the complicated setup for PIM, I see a lot of new developments that promises to make it simpler. Hopefully, I won't need the org-mode power in the future to rein in the complexity.
- ParetoOptimal 3y ago
  > In short, Emacs has nothing to do with the complexity. There are many cases where if I didn't have it's features like this I would have to sacrifice ease of use of my full system or hold tons of edge cases in my head.

pxc 3y ago

> The init.el file is just a stub meant to load the configuration from the org-mode file. Even better - the init.el itself is written within the org-mode file. The org-mode file can be executed like a shell script (actually elisp script) to extract the init.el file. Can I see (an example)? Wondering how much goes into that init.el.

goku12 3y ago
Sorry I couldn't post earlier. Here is a sample: https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257c51123dcbc https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257...
- pxc 3y ago
  Thanks!
nvy 3y ago
Not OP but here's mine: https://github.com/nathanvy/dotemacs https://github.com/nathanvy/dotemacs The .org file gets processed and the source code blocks extracted into an elisp-only file which is what actually gets executed. Some people prefer an alternate approach[0] with the "stub" init.el that just loads other modules. [0] https://github.com/cute-jumper/.emacs.d/blob/master/init.el https://github.com/cute-jumper/.emacs.d/blob/master/init.el
- pxc 3y ago
  Thanks for sharing both of these examples!