From f7108060d47da65d0ae173c9abe9c2e0727c6b19 Mon Sep 17 00:00:00 2001 From: Kévin Le Gouguec Date: Fri, 3 May 2019 18:07:12 +0200 Subject: Fix typo in filename --- technical/reviews/mailing-lists.md | 68 +++++++++++++++++++++++++++++++++++++ technical/reviews/mailling-lists.md | 68 ------------------------------------- 2 files changed, 68 insertions(+), 68 deletions(-) create mode 100644 technical/reviews/mailing-lists.md delete mode 100644 technical/reviews/mailling-lists.md diff --git a/technical/reviews/mailing-lists.md b/technical/reviews/mailing-lists.md new file mode 100644 index 0000000..c63d376 --- /dev/null +++ b/technical/reviews/mailing-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 diff --git a/technical/reviews/mailling-lists.md b/technical/reviews/mailling-lists.md deleted file mode 100644 index c63d376..0000000 --- a/technical/reviews/mailling-lists.md +++ /dev/null @@ -1,68 +0,0 @@ -# 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 -- cgit v1.2.3