Hacker News Reader

Comment by goku12 | Hacker News Reader

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.

View on HN

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.

Bash/readline also has a vi mode :) https://www.gnu.org/software/bash/manual/html_node/Readline-...

Native emacs keybindings never ever worked for me. I could only use emacs once I got used to evil mode

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?

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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

Not OP but here's mine: 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

Thanks for sharing both of these examples!

Sorry I couldn't post earlier. Here is a sample:

https://paste.sr.ht/~gokuldas/30c47d1c2721111171a51ecc44f257...

Thanks!

Reply on news.ycombinator.com