trying to fix
This commit is contained in:
parent
fa407dfeb6
commit
e013d7569e
22945 changed files with 447936 additions and 0 deletions
115
var/elfeed/db/data/23/237f0c4f2c19686154e3bdc8f12a495a182e73c0
Normal file
115
var/elfeed/db/data/23/237f0c4f2c19686154e3bdc8f12a495a182e73c0
Normal file
|
|
@ -0,0 +1,115 @@
|
|||
<p>I’ve <a href="https://www.rousette.org.uk/archives/emacs-from-a-clean-slate/">been here before</a>, but I find myself back here again. I think that many
|
||||
people who start off with one of the big frameworks (like Spacemacs or Doom
|
||||
Emacs) eventually circle around to thinking, “hey, why don’t I just build my own
|
||||
Emacs config that includes the best bits of Spacemacs/Doom?”. Usually, that is
|
||||
followed some time later (as <a href="https://www.rousette.org.uk/archives/back-to-doom-emacs/">happened in my case</a> last time), by the realization
|
||||
that those frameworks are <em>really</em> well crafted, and getting anything like that
|
||||
degree of polish and sleekness yourself is very difficult without basically
|
||||
replicating the entirety of those projects. However, I’m playing with
|
||||
configuring from scratch again, just for kicks.</p>
|
||||
<p>My reasons are nebulous and not very well defined, and can basically be boiled
|
||||
down to — I felt like it.</p>
|
||||
<p>As I’ve got more comfortable with Doom, I’ve learned a lot more about which
|
||||
packages work best for me, and how I like things configured, so it has helped me
|
||||
to narrow down a comfortable setup without a lot of work on my part. There have
|
||||
also been some new packages out recently, and updates to packages I was using
|
||||
previously, which have enabled me to build a more streamlined system. The
|
||||
constellation of what I suppose we might call completion-related packages
|
||||
(Selectrum/Vertico, Consult, Orderless, Marginalia and Embark, some of which I
|
||||
wrote about <a href="https://www.rousette.org.uk/archives/switching-to-selectrum-for-incremental-narrowing-in-emacs/">here</a>) have become really sleek and capable, and much easier to
|
||||
configure than they used to be. The built-in <code>project.el</code> package handles a
|
||||
significant subset of the capabilities of <code>projectile</code>, without needing to load
|
||||
an external package. <code>projectile</code> is still a brilliant package, but if you (like
|
||||
me) only use a small subset of its powers, then <code>project.el</code> will probably work
|
||||
well for you. Finally, <a href="https://github.com/plexus/chemacs2">chemacs</a> has been around for a while, but the latest
|
||||
version now handles including an <code>early.init.el</code> in your configurations, which
|
||||
is useful with more recent versions of Emacs. Chemacs, for those not familiar
|
||||
with it, is a brilliant tool which enables you to keep several different
|
||||
versions of Emacs configurations (including either Spacemacs or Doom Emacs)
|
||||
around and choose to load any one of them. You can even open two versions of
|
||||
Emacs, one running Doom and one running your new configuration. This makes it
|
||||
much less disruptive to tinker with your Emacs configuration, because you can
|
||||
continue to use your working version as normal, as well as editing your
|
||||
new configuration with your usual Emacs configuration.</p>
|
||||
<p>First things first, I decided to take the plunge and move to Emacs 28 with
|
||||
native compilation (gccemacs). I used the <a href="https://github.com/d12frosted/homebrew-emacs-plus">d12frosted/emacs-plus</a> formula from
|
||||
Homebrew, specifying <code>emacs-plus@28 --with-native-comp</code> as the formula. It took
|
||||
quite a while for everything to compile, but once finished, it worked
|
||||
beautifully. Natively compiled Emacs 28 feels a lot more snappy on my Macs, and
|
||||
I haven’t yet found any problems with running it.</p>
|
||||
<p>Doom uses a clever custom packaging system which is built on <a href="https://github.com/raxod502/straight.el">straight.el</a>. I had
|
||||
also got used to using Doom’s <code>use-package</code> configuration, which made
|
||||
everything a bit neater and more modular. When I looked into <code>straight.el</code> more,
|
||||
I found that it had a neat way of making configurations completely reproducible
|
||||
by combining the init file and a versions lockfile. It also works with
|
||||
<code>use-package</code>: if you set it up with
|
||||
<code>(setq straight-use-package-by-default t)</code>, <code>use-package</code> will use straight to
|
||||
fetch and build packages by default. This also means that you are not limited to
|
||||
packages on the main repositories (like ELPA and MELPA), but you can also
|
||||
specify those on GitHub or local packages, which increases flexibility. Now that
|
||||
I have got used to this system, I really like it. If you save a versions file
|
||||
for a working configuration, you can update packages without worrying that it
|
||||
will break your system, because you can always restore your system to the
|
||||
version in the lockfile if things go wrong.</p>
|
||||
<p>I haven’t finished building all the features I want into my scratch
|
||||
configuration yet, but it is already comfortable enough to edit the
|
||||
configuration (and this blog post) with, without having to resort to my Doom
|
||||
Emacs configuration. I’m still using <code>evil</code> bindings, and I have started to
|
||||
build <code>SPC</code> leader bindings using <code>general.el</code> so that I have a custom menu of
|
||||
options without having to remember all the built-in bindings. I’m also using
|
||||
<a href="https://github.com/minad/vertico">Vertico</a> for completions which I have really come to like, <a href="https://github.com/oantolin/orderless">Orderless</a> for more
|
||||
advanced completion styles, <a href="https://github.com/minad/marginalia">Marginalia</a> for minibuffer annotations, <a href="https://github.com/oantolin/embark">Embark</a> for
|
||||
custom actions in the minibuffer and buffer, and <a href="https://github.com/minad/consult">Consult</a> for some handy
|
||||
commands which integrate well with the other packages. All of these packages
|
||||
build on top of standard Emacs functions (like <code>completing-read</code>), so
|
||||
integration is tight and fairly seamless.</p>
|
||||
<p>I could have just used <code>doom-modeline</code> or configured my own modeline, but I
|
||||
tried out <a href="https://github.com/dbordak/telephone-line">telephone-line</a>, really for no other reason that the name is based on a
|
||||
great ELO song<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>, and because it’s pretty. I like it a lot, and it turned out to
|
||||
be quite easy to configure to my liking.</p>
|
||||
<p>I’m also trying out the new <code>org-cite</code> framework which is built into Org 9.5,
|
||||
along with the <a href="https://github.com/bdarcus/bibtex-actions">bibtex-actions</a> package to make it easier to choose, insert and
|
||||
act on citations. Now that <code>org-cite</code> and <code>pandoc</code> can use the same citation
|
||||
format, it should be much more seamless when including references in documents.
|
||||
<code>bibtex-actions</code> is great now that I have it working, but I did get a bit stuck
|
||||
initially trying to set up the example configuration for <code>org-cite</code> that is
|
||||
included in the README. It is probably some interaction with the way that
|
||||
<code>straight.el</code> defines packages, but I found that I had to set it up like this
|
||||
to get it working with Zotero and <code>org-cite</code>:</p>
|
||||
<div class="highlight"><pre style="background-color:#fff;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-emacs-lisp" data-lang="emacs-lisp">(<span style="color:#038">defvar</span> <span style="color:#369">my/bibs</span> '(<span style="color:#d20;background-color:#fff0f0">"~/Documents/bibtex/zotero.bib"</span>))
|
||||
(<span style="color:#038">use-package</span> <span style="color:#369">citeproc</span>)
|
||||
(<span style="color:#038">use-package</span> <span style="color:#369">bibtex-actions</span>
|
||||
<span style="color:#038">:bind</span> ((<span style="color:#d20;background-color:#fff0f0">"s-b"</span> . <span style="color:#369">org-cite-insert</span>)
|
||||
(<span style="color:#d20;background-color:#fff0f0">"M-o"</span> . <span style="color:#369">org-open-at-point</span>)
|
||||
<span style="color:#038">:map</span> <span style="color:#369">minibuffer-local-map</span>
|
||||
(<span style="color:#d20;background-color:#fff0f0">"M-b"</span> . <span style="color:#369">bibtex-actions-insert-preset</span>))
|
||||
<span style="color:#038">:after</span> (<span style="color:#369">embark</span> <span style="color:#369">oc</span>)
|
||||
<span style="color:#038">:config</span>
|
||||
(<span style="color:#038">setq</span> <span style="color:#369">bibtex-actions-bibliography</span> <span style="color:#369">my/bibs</span>
|
||||
<span style="color:#369">org-cite-global-bibliography</span> <span style="color:#369">my/bibs</span>
|
||||
<span style="color:#369">org-cite-insert-processor</span> <span style="color:#a60;background-color:#fff0f0">'oc-bibtex-actions</span>
|
||||
<span style="color:#369">org-cite-follow-processor</span> <span style="color:#a60;background-color:#fff0f0">'oc-bibtex-actions</span>
|
||||
<span style="color:#369">org-cite-activate-processor</span> <span style="color:#a60;background-color:#fff0f0">'oc-bibtex-actions</span>)
|
||||
(<span style="color:#038">setq</span> <span style="color:#369">org-cite-csl-styles-dir</span> <span style="color:#d20;background-color:#fff0f0">"~/Zotero/styles"</span>))
|
||||
<span style="color:#888">;; Use consult-completing-read for enhanced interface.</span>
|
||||
(<span style="color:#369">advice-add</span> <span style="color:#06b;font-weight:bold">#'</span><span style="color:#369">completing-read-multiple</span> <span style="color:#038">:override</span> <span style="color:#06b;font-weight:bold">#'</span><span style="color:#369">consult-completing-read-multiple</span>)
|
||||
<span style="color:#888">;; a hack to get bibtex-actions working</span>
|
||||
(<span style="color:#06b;font-weight:bold">load</span> <span style="color:#d20;background-color:#fff0f0">"~/.emacs-configs/scratch-emacs/straight/build/bibtex-actions/oc-bibtex-actions.el"</span>)
|
||||
</code></pre></div><p>If I didn’t load the <code>oc-bibtex-actions.el</code> file manually at the end, none of
|
||||
the variables in the <code>use-package</code> block got defined. I’m probably missing
|
||||
something obvious, but this makes it work for me. I will try to remember to log
|
||||
an issue on the GitHub project to ask what I’m doing wrong.</p>
|
||||
<p>Anyway, I’m having fun. My custom Emacs config is working pretty well, and it is
|
||||
still snappy to load and run. I’ve learned more along the way about some of the
|
||||
packages that I was just loading blindly before, so it has been a useful
|
||||
process. I wouldn’t lay any bets with myself that I won’t have scurried back to
|
||||
the luxury of my Doom Emacs configuration within a couple of months, but for now
|
||||
I’m enjoying the process!</p>
|
||||
<section class="footnotes" role="doc-endnotes">
|
||||
<hr>
|
||||
<ol>
|
||||
<li id="fn:1" role="doc-endnote">
|
||||
<p>Every time I edit the <code>telephone-line</code> config, I sing “Oh, oh, telephone line, give me some time…” <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
|
||||
</li>
|
||||
</ol>
|
||||
</section>
|
||||
Loading…
Add table
Add a link
Reference in a new issue