style: edit prose
This commit is contained in:
parent
e383d1f199
commit
8f5dba1326
29
config.org
29
config.org
|
@ -39,13 +39,13 @@ It was at this point that I started thinking about Emacs again. By chance, I hap
|
|||
- Sensible defaults
|
||||
- Extensive ecosystem
|
||||
|
||||
As I became more comfortable with configuration via scripting, I immersed myself into the many utilities that make up the Emacs ecosystem: =org-mode=, =calfw=, =calc=, =mu4e=. I started putting more and more time into tweaking these applications to fit my needs, my files kept getting longer and longer, and eventually I fully fell off the deep end and now we're here.
|
||||
As I became more comfortable with configuration via scripting, I immersed myself into the many utilities that make up the Emacs ecosystem, especially =org-mode=, the gold standard of Emacs tools. I started putting more and more time into tweaking this environment to fit my needs, my files kept getting longer and longer, and eventually I fully fell off the deep end and now we're here.
|
||||
|
||||
*** Literate Programming
|
||||
|
||||
My first Doom Emacs config was hacked together directly from the generated example config: no comments, no organization, nothing. ~after!~ and ~use-package!~ blocks were scattered about the file without rhyme or reason, making it very difficult to remember what any particular line of code was actually doing. I was able to mitigate some of this issue by categorizing my config into multiple files, but at the end of the day it was a losing battle. The config directory was at around 1200 lines of code before I decided that something needed to be done.
|
||||
|
||||
I was considering what to do about this problem of organizational decay when I came across [[https://tecosaur.github.io/emacs-config/config.html][Tecosaur's config]] and learned about =org-mode='s literate programming support. I had been using =org-mode= for several months at this point and was very comfortable with it, so utilizing it to better organize my Emacs code seemed like a good idea.
|
||||
I was considering what to do about this problem of organizational decay when I came across [[https://tecosaur.github.io/emacs-config/config.html][Tecosaur's config]] and learned about =org-mode='s literate programming support. I was very comfortable with =org-mode= at this point, so it seemed like a good solution and a natural next step.
|
||||
|
||||
**** Org and Source Code
|
||||
|
||||
|
@ -113,7 +113,7 @@ As part of their literate config, Tecosaur implemented =confpkg=, an embedded Em
|
|||
- Automatically detecting cross-section dependencies
|
||||
- Reporting profiling information on config load times
|
||||
|
||||
It's an incredibly impressive utility, and I highly recommend reading [[https://tecosaur.github.io/emacs-config/config.html#rudimentary-configuration-confpkg][the section in their config]] on its design. I tried to read through it myself, but I don't understand half of it; it's a bizarre mixture of exploits to hook into =org-mode='s tangling process, self-modifying buffer shenanigans, and abuse of various features of the source block mechanism.
|
||||
It's an incredibly impressive utility, and I highly recommend reading [[https://tecosaur.github.io/emacs-config/config.html#rudimentary-configuration-confpkg][the section in their config]] on its design. I tried to read through it myself, but I don't understand half of it; it's a bizarre mixture of exploits to hook into =org-mode='s tangling process, self-modifying buffer shenanigans, and abuse of various features of =org-babel=, the package that manages source blocks.
|
||||
|
||||
Luckily, I don't need to be able to understand code in order to do what I do best: press =Ctrl+C= and =Ctrl+V= in that order. Programming!
|
||||
|
||||
|
@ -122,7 +122,7 @@ If you're reading the raw org file instead of the published version, the code fo
|
|||
- Prevent =confpkg='s code from being exported
|
||||
- Change the package template to contain my information
|
||||
- Reorganize to get rid of superfluous noweb references
|
||||
- Hook into only babel calls that contain =confpkg= as a substring
|
||||
- Hook only into babel calls that contain =confpkg= as a substring
|
||||
- Allow package statements anywhere in subconfig files, rather than only at the beginning
|
||||
|
||||
** confpkg :noexport:
|
||||
|
@ -815,7 +815,7 @@ literate
|
|||
|
||||
** Completion
|
||||
|
||||
I'm a big fan of the Vertico ecosystem, as it's lightweight and easy to use. Let's turn on that module, along with the icons flag because why not.
|
||||
I'm a big fan of the Vertico ecosystem, as it's lightweight and easy to use. Let's turn on that module, along with Corfu for a nice in-buffer completion popup and some icons because why not.
|
||||
|
||||
#+name: doom-completion
|
||||
#+begin_src emacs-lisp
|
||||
|
@ -1064,8 +1064,6 @@ It wouldn't be Emacs if there wasn't an endless list of config variables to chan
|
|||
(global-subword-mode 1)
|
||||
#+end_src
|
||||
|
||||
Thanks once again to Tecosaur for some of these settings.
|
||||
|
||||
** Personal Information
|
||||
|
||||
#+call: confpkg()
|
||||
|
@ -1081,7 +1079,7 @@ Emacs uses this basic personal information for a few different things, mostly ap
|
|||
|
||||
#+call: confpkg("Auth")
|
||||
|
||||
I don't want my cache files to get deleted whenever I mess up my Doom install, so let's move them to somewhere more safe.
|
||||
The =auth-source-pass= module lets you use [[*Password Management][pass]] as a source for authentication. Let's turn that on.
|
||||
|
||||
#+begin_src emacs-lisp
|
||||
(require 'auth-source-pass)
|
||||
|
@ -1214,7 +1212,7 @@ Some packages in this config such as =treemacs=, =org-roam=, etc. require certai
|
|||
1. Put that tool in the actual environment, e.g. in a profile. This makes sense for simple things (=ripgrep=, =sqlite=, etc) but for more opinionated things like an instance of Python it becomes less desirable.
|
||||
2. Build the tool and put a symlink to the output somewhere, e.g. in the HOME directory. This avoids polluting the environment, but you still have to deal with an unwieldy symlink that breaks Emacs if you accidentally delete it.
|
||||
This was my approach before coming up with the third option:
|
||||
3. Build the tool and point Emacs directly to the store path. This is the simplest solution, but requires the most complex Emacs configuration.
|
||||
3. Build the tool and point Emacs directly to the store path. This is the most automatic solution, but requires the most complex Emacs configuration.
|
||||
|
||||
This section is an implementation of that third solution.
|
||||
|
||||
|
@ -1237,7 +1235,7 @@ If IMPURE is t, then allow impure builds."
|
|||
(s-trim (buffer-string)))))))
|
||||
#+end_src
|
||||
|
||||
This works well enough if we just want to build something, but there's a problem: we haven't indicated to Nix that we want this output to stick around, so it will be deleted the next time we garbage collect. To fix this, we can write a wrapper function that also makes the output path a garbage collection root.
|
||||
This works if we just want to start a build, but there's a problem: we haven't indicated to Nix that we're using this output for something, so it will be deleted the next time we garbage collect. To fix this, we can write a wrapper function that also makes the output path a garbage collection root.
|
||||
|
||||
#+begin_src emacs-lisp
|
||||
(defun nix-build-out-path-gcroot (name out &optional impure)
|
||||
|
@ -2199,7 +2197,8 @@ Doom Emacs sets up spell-checking with ~ispell~ (Emacs-internal tool) and =aspel
|
|||
(setq ispell-dictionary "en_US"))
|
||||
#+end_src
|
||||
|
||||
We also need to generate a plain-text dictionary for some ~ispell~ functionality, which is annoying, but I haven't figured out a way around it. I could use my automated nix-build system for this, but I want to have access to my =aspell= config file, so it's easier to just put it in the usual location.
|
||||
We also need to generate a plain-text dictionary for some ~ispell~ functionality, which is annoying, but I haven't figured out a way around it. I could use my automated nix-build system for this, but in this case it's easier to just put it in the usual location.
|
||||
|
||||
Now that we have our new-and-improved template registry system, we can add new file templates as we please.
|
||||
|
||||
#+begin_src emacs-lisp
|
||||
|
@ -3358,8 +3357,8 @@ Org-roam is inspired by Roam Research, and like that tool it is based on the Zet
|
|||
In my use of Org-roam for task management, I divide nodes into a few different categories:
|
||||
|
||||
1. *Areas*, which represent continual areas of your life to organize and plan;
|
||||
2. *Goals*, short- or long-term, things that can be completed;
|
||||
3. *Tasks*, which are one-time and contribute to goals or areas.
|
||||
2. *Goals*, short- or long-term that can be completed;
|
||||
3. *Tasks*, which are small, one-time and contribute to goals or areas.
|
||||
|
||||
Areas are stored as subnodes of the =Areas= file node, and likewise for goals. They also have the =:area:= and =:goal:= tags respectively. A task is a node that is a TODO entry that links to an area or a goal. We can thus check for if a node is a task by checking if the node links to a =:area:= or =:goal:= tagged node.
|
||||
|
||||
|
@ -3466,7 +3465,7 @@ This advice overrides ~org-capture-place-template~, the function that:
|
|||
2. Modifies the template to fit its context
|
||||
3. Places the template in the file
|
||||
|
||||
The advice temporarily sets Org's capture template to an empty string, lets Org do its thing, and then expands the template itself. This does mean that Org no longer performs point 2, but YASnippet is powerful enough that we can simply do that ourselves in the template.
|
||||
The advice temporarily sets Org's capture template to an empty string, lets Org do its thing, and then expands the template itself. This does mean that Org can no longer perform point 2, but YASnippet is powerful enough that we can simply do that ourselves in the template.
|
||||
|
||||
*** Roam Capture
|
||||
|
||||
|
@ -3942,7 +3941,7 @@ The Doom module is very outdated, so I'll be overriding it.
|
|||
|
||||
*** Appearance
|
||||
|
||||
Operators being in italics looks ugly in this mode too, but unfortunately due to Idris's more complicated syntax highlighting system we have to do a bit more work than for Haskell. There's also the issue of the semantic highlighting faces, which don't match our theme colors.
|
||||
Operators being in italics looks ugly in this mode too, but due to Idris's more complicated syntax highlighting system we have to do a bit more work than for Haskell. There's also the issue of the semantic highlighting faces, which don't match our theme colors.
|
||||
|
||||
#+begin_src emacs-lisp
|
||||
(after! idris-mode
|
||||
|
|
Loading…
Reference in a new issue