1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
#+TITLE: Monthly Retrospective: August 2022
#+SERIES: ./MonthlyRetrospectives.html
Anyway, without further ado, let’s take a look at what was achieved
for the last thirty days or so.
#+begin_export html
<nav id="generate-toc"></nav>
#+end_export
* Emacs
I have started tweaking and improving my Emacs [[https://src.soap.coffee/dotfiles/emacs.d.git][configuration]]
again. [[mn:minimalism][After having used Emacs for seven years now, I am nowhere
close to consider my configuration as a done project. I really envy
developers who are using their editor with little to no
customization.]]
** Theme Selection Menu
The change I am the most excited about is that I have /finally/
reduced the boilerplate in need to write to use a new theme. I am
very indecisive when it comes to theming. I like to have my
choices, and I get tired of any colorscheme pretty quickly. As a
consequence, I introduced a customizable variable to let me select
a theme dynamically, and have this choice persist across Emacs
session.
I have a Hydra menu that allows me to select which theme I want to
use for the time being. It looks like this.
#+CAPTION: A Hydra menu for selecting a theme.
#+NAME: fig:hydra-theme-menu
[[../img/select-theme.png]]
But adding new entries to this menu was very cumbersome, and mostly
boilerplate that I know a good macro could abstract away. And I can
finally report that I was right all along. I have my macros now,
and they allow me to have the Hydra menu above generated with these
simple lines of code.
#+begin_src elisp
(use-theme ancientless "a" :straight nil :load-path "~/.emacs.d/lisp")
(use-theme darkless "d" :straight nil :load-path "~/.emacs.d/lisp")
(use-theme brightless "b" :straight nil :load-path "~/.emacs.d/lisp")
(use-theme monotropic "m")
(use-theme monokai "M")
(use-theme nothing "n")
(use-theme eink "e")
(use-theme dracula "D")
(use-theme chocolate "c")
(use-themes-from tao-theme
'(("tl" . tao-yang)
("td" . tao-yin)))
#+end_src
** Eldoc and Flycheck Popups
I have been experimenting with several combinations of packages to
have Eldoc and Flycheck using pop-up-like mechanisms to report
things to me, instead of the echo area.
The winning setup for now is the one that uses the [[https://github.com/cpitclaudel/quick-peek][quick-peek
package]]. That is, [[https://github.com/flycheck/flycheck-inline][flycheck-inline]] (customized to use quick-peek, as
suggested in their README), and [[https://melpa.org/#/eldoc-overlay][eldoc-overlay]]. This works well
enough, so the pop-ups of eldoc are maybe a bit too distracting.
#+CAPTION: flycheck-inline in action with an OCaml compilation error.
#+NAME: fig:flycheck-inline
[[../img/flycheck-inline.png]]
#+CAPTION: eldoc-overlay in action, displaying an OCaml type.
#+NAME: fig:eldoc-overlay
[[../img/eldoc-overlay.png]]
In my quest for pop-ups, I ran into several issues with the
packages I tried out. For instance, [[https://github.com/casouri/eldoc-box][eldoc-box]] was very nice, but
also very slow for some reason. It turns out there were an issue
about that slowness, wherein the culprit was identified. This
allowed me to [[https://github.com/casouri/eldoc-box/pull/48][submit a pull request that got merged rather quickly]].
Similarly, after a packages update, I discovered [[https://github.com/flycheck/flycheck-ocaml][flycheck-ocaml]] was
no longer working, and [[https://github.com/flycheck/flycheck-ocaml/pull/14][submit a patch to fix the issue]].
* This Website
I have not been investing a lot of time in this website for the past
six years or so. This month, things change a bit on that side too.
** New Contents
First, I have published a (short) article on [[rel:/posts/RankNTypesInOCaml.html][higher-order
polymorphism in OCaml]]. The goal was for me to log somewhere the
solution for an odd problem I was confronted to at ~$WORK~, but the
resulting article was not doing a great job as conveying this. In
particular, two comments on Reddit motivated me to rework it, and I
am glad I did. I hope you enjoy the retake.
Once this was out of the way, I decided that generating this website
was taking way too much time for no good enough reason. The culprit
was *~cleopatra~*, a toolchain I had developed in 2020 to integrate
the build process of this website as additional contents that I
thought might interest people. The sad things were: *~cleopatra~*
was adding a significant overhead, and I never take the time to
actually document them properly.
** Under the Hood
Overall, the cost of using *~cleopatra~* was not worth the burden,
and so I got ride of it. Fortunately, it was not very difficult,
since the job of *~cleopatra~* was to extracting the generation
processes from org files; I just add to implement a small
~makefile~ to make use of these files, without having to rely on
*~cleopatra~* anymore.
This was something I was pondering to do for a long time, and as
often in these circumstances, this gave me the extra motivation I
needed to tackle other ideas I had in mind for this website. This
is why now, rather than starting one Emacs process per Org file I
have to process, my build toolchain starts one Emacs server, and
later uses ~emacsclient~.
Now, most of the build time is spent by [[https:soupault.app][soupault]]. I guess I will
have to spend some time on the Lua plugins I have developed for it
at some point.
** A New Mailing List
Finally, I have created [[https://lists.sr.ht/~lthms/public-inbox][a public mailing]] list that is available if
you want to start a discussion on one of my article. Don’t hesitate
to use it, or to register to it!
|