mailing-lists.md (6332B)
1 # Emacs 2 3 ## 2019-01 4 5 ### [Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it.][cc-mode/electric-pair] 6 7 A thread that feels very representative of the friction between 8 "keeping things working as they always did" vs. "simplifying that huge 9 lumbering beast of a codebase". I find [Stefan Monnier's 10 intervention][cc-mode/electric-pair-stefan] helpful because it 11 captures both sides of the argument quite well: 12 13 > >> I understand that there's a transition needed between these two and this 14 > >> intermediate state can require more work, but it's important to keep the 15 > >> long term goal in mind when designing the current solution. 16 > 17 > > Whose long term goal? 18 > 19 > At the very least mine. 20 > 21 > > My goal, both long and short term, is to keep CC Mode 22 > > working properly. 23 > 24 > That's orthogonal. 25 > 26 > To give you a similarly general goal, my own goal is to make it so that 27 > **any feature which makes sense in many major mode be implemented once and 28 > then used in the relevant major modes, rather than being implemented 29 > independently for those major modes.** 30 > 31 > This is both for uniformity between major modes, and because it both 32 > simplifies and improves many major modes (which would otherwise either 33 > not provide the feature or only in very primitive ways). 34 > 35 > **And those maintainers like you who did go to the trouble of being early 36 > implementers of the feature suffer through the pain of having to adapt 37 > their code once the generic version of the feature becomes available.** 38 > Sometimes even at the cost of having the new feature working slightly 39 > worse in some corner cases. 40 > 41 > But many of them are quite happy to be able to drop their old code and 42 > get rid of that responsibility (i.e. bug reports about regressions can 43 > be redirected to Emacs maintainers). 44 45 On a non-technical note, this thread allowed RMS to advertise the [GNU 46 Kind Communications Guidelines][gnu-kind-communication]: 47 48 > To ask "who started it" is to oversimplify. Often what happens 49 > is that a little harshness creeps into a discussion, then people 50 > react to that in a way that is a little more harsh. So nobody 51 > "started it" but multiple people exacerbated it. 52 > 53 > **Thus, part of the effort is, when we feel harshness coming at us, 54 > to damp it down rather than hitting back.** 55 56 [cc-mode/electric-pair]: https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00360.html 57 [cc-mode/electric-pair-stefan]: https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00518.html 58 [gnu-kind-communication]: https://www.gnu.org/philosophy/kind-communication.html 59 60 ### [Documentation about the completion framework][completion-documentation] 61 62 Helpful pointers for whoever wants to dig into completion plumbing. 63 Personally, I struggled to get to grips with it when [debugging some 64 `icomplete` issue][icomplete-issue], relying on the source for 65 information, and giving up while trying to write an automated test 66 case. 67 68 [completion-documentation]: https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00504.html 69 [icomplete-issue]: https://gitlab.com/peniblec/memory-leaks/commit/dcc0c05dc1f6a22645bf9355b72aa44b49776620 70 71 ## 2019-05 72 73 ### [\[RFE\] Migration to gitlab][migration-gitlab] 74 75 Eli Zaretskii's comprehensive answer to the question: "How could 76 moving to a GitLab-centric workflow possibly make a maintainer's life 77 worse?" 78 79 My interpretation: 80 81 Emacs's development infrastructure is pretty threadbare by modern 82 standards. Contributions, drive-by or otherwise, linger as 83 unremarkable Debbugs attachments until someone takes the time to try 84 the patches out. Once the discussion branches into multiple 85 sub-threads, it can be hard to track the "current state" of the patch 86 series. 87 88 A Continuous Integration server [exists][emacs-ci], but it only tracks 89 branches on Savannah AFAIK; regressions can only be identified if 90 someone takes the time to run tests locally (at best) or once the 91 patches have been committed to the Emacs repository (at worst). 92 Contrast with GitLab-centric projects where anyone "driving-by" is 93 automatically greeted with a test suite report. 94 95 We are reliant on the unyielding dedication of extremely competent 96 maintainers to review contributions, condemned to spend CPU cycles 97 checking for breakage and waste heartbeats pointing out trivial 98 formatting issues, before they can move on to higher-level review 99 (e.g. feature design, documentation clarity). The push for "better 100 tooling" is motivated by the prospect of lowering the bar for 101 participating in maintenance. 102 103 Yet despite the dismal state of the current server-side tooling, 104 GitLab *as a maintainer frontend* lacks many features that some Emacs 105 veterans expect. Some of the facilities Eli lists may eventually get 106 equivalents in GitLab's web UI, but neither the GitLab UI nor the 107 browser it runs on will ever provide a completely reprogrammable 108 environment one can enhance on-the-fly. 109 110 To borrow terms from [Josh Triplett's comparison of Rust vs. C for 111 systems programming][compelling-vs-parity], the GitLab server offers 112 *compelling features* over Debbugs, but the GitLab web UI does not 113 provide *feature parity* with Emacs. 114 115 AFAICT, some paths of least resistance for better development tooling 116 would be 117 118 - extending Debbugs to push a patch series as a branch on EMBA, and 119 report the test results, 120 - adding scripts to check commit messages against the expected 121 Changelog format, and suggesting templates based on the diffs 122 (i.e. what `diff-add-change-log-entries-other-window` does). 123 124 Full interoperability between maintainers who would like a web UI for 125 reviews, and maintainers who prefer the versatility of simply quoting 126 patches in a mail-composition buffer sounds tricky. The CI server 127 would need to break quoted-patch emails down into { quoted hunk, 128 comment } pairs so that the comments show up correctly (i.e. properly 129 cross-referenced to the hunk being discussed) on the web UI; not sure 130 if some platform already supports that; maybe [sourcehut][srht] took a 131 stab at it? 132 133 [migration-gitlab]: https://lists.gnu.org/archive/html/emacs-devel/2019-05/msg00306.html 134 [emacs-ci]: https://emba.gnu.org/emacs/emacs/pipelines 135 [compelling-vs-parity]: https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ 136 [srht]: https://sourcehut.org/