Start tracking mailing list threads I find informative

Maybe reading them will feel less like procrastination this way.

1 files changed, 68 insertions, 0 deletions

diff --git a/technical/reviews/mailling-lists.md b/technical/reviews/mailling-lists.md
new file mode 100644
index 0000000..c63d376
--- /dev/null
+++ b/technical/reviews/mailling-lists.md
@@ -0,0 +1,68 @@
+# Emacs
+
+## 2019-01
+
+### [Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it.][cc-mode/electric-pair]
+
+A thread that feels very representative of the friction between
+"keeping things working as they always did" vs. "simplifying that huge
+lumbering beast of a codebase".  I find [Stefan Monnier's
+intervention][cc-mode/electric-pair-stefan] helpful because it
+captures both sides of the argument quite well:
+
+> >> I understand that there's a transition needed between these two and this
+> >> intermediate state can require more work, but it's important to keep the
+> >> long term goal in mind when designing the current solution.
+> > Whose long term goal?
+>
+> At the very least mine.
+>
+> > My goal, both long and short term, is to keep CC Mode
+> > working properly.
+>
+> That's orthogonal.
+>
+> To give you a similarly general goal, my own goal is to make it so that
+> **any feature which makes sense in many major mode be implemented once and
+> then used in the relevant major modes, rather than being implemented
+> independently for those major modes.**
+>
+> This is both for uniformity between major modes, and because it both
+> simplifies and improves many major modes (which would otherwise either
+> not provide the feature or only in very primitive ways).
+>
+> **And those maintainers like you who did go to the trouble of being early
+> implementers of the feature suffer through the pain of having to adapt
+> their code once the generic version of the feature becomes available.**
+> Sometimes even at the cost of having the new feature working slightly
+> worse in some corner cases.
+>
+> But many of them are quite happy to be able to drop their old code and
+> get rid of that responsibility (i.e. bug reports about regressions can
+> be redirected to Emacs maintainers).
+
+On a non-technical note, this thread allowed RMS to advertise the [GNU
+Kind Communications Guidelines][gnu-kind-communication]:
+
+> To ask "who started it" is to oversimplify.  Often what happens
+> is that a little harshness creeps into a discussion, then people
+> react to that in a way that is a little more harsh.  So nobody
+> "started it" but multiple people exacerbated it.
+>
+> **Thus, part of the effort is, when we feel harshness coming at us,
+> to damp it down rather than hitting back.**
+
+[cc-mode/electric-pair]: https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00360.html
+[cc-mode/electric-pair-stefan]: https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00518.html
+[gnu-kind-communication]: https://www.gnu.org/philosophy/kind-communication.html
+
+### [Documentation about the completion framework][completion-documentation]
+
+Helpful pointers for whoever wants to dig into completion plumbing.
+Personally, I struggled to get to grips with it when [debugging some
+`icomplete` issue][icomplete-issue], relying on the source for
+information, and giving up while trying to write an automated test
+case.
+
+[completion-documentation]: https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00504.html
+[icomplete-issue]: https://gitlab.com/peniblec/memory-leaks/commit/dcc0c05dc1f6a22645bf9355b72aa44b49776620