Liliana Marie Prikler <liliana.prik...@gmail.com> writes:
> Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus: >> I have the same positive view on our faux ChangeLogs commit messages, >> though I also would like to have them generated. The benefit is >> still there: I still get to *review* an effective summary of the >> changes before pushing or sending them off for review. But at least >> I don’t have to write them myself. >> >> Now, this is no longer a problem for me because I’ve been writing so >> many commit messages over the years (and because I no longer try to >> adhere to some poorly specified format), but it *is* a problem for >> people that I’ve mentored. >> >> etc/committer.scm and the yasnippets are supposed to alleviate some >> of the pain, but I don’t need to think for a long time to come up >> with a number of improvements in this area. > Can I assume this to mean it'd take you some short time to think of > snippets that we're currently lacking? If so, please do contribute > them. If not, what do you mean then? I mean that they have plenty of defects. When I wrote the first few iterations of etc/committer.scm it was only really meant and good for bulk package updates (= lots of changes across files, all upgrades). It couldn’t (and maybe still can’t) reliably detect added or removed package definitions. It doesn’t handle changes to the arguments field. It’s also terribly slow because it naively recomputes information for every hunk in the diff, reading package definitions from the old vs the changed file after every commit. The update yasnippet repeatedly gets the order of lines wrong when adding a patch to dist_patch_DATA in gnu/local.mk; it also doesn’t do what etc/committer.scm is already able to do: detecting changes to inputs. Configuring yasnippet is also not trivial for people who don’t regularly use Emacs (the snippets are tied to modes set by magit). I think in light of these defects “Uhm, we have snippets?” isn’t a satisfying response. -- Ricardo
