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
|
# 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
|
