On December 4, 2020, Raghav Gururajan <raghavgurura...@disroot.org> wrote: > I can tell you that those cosmetic changes I made were 100% > irrational, useless and noisy.
That's certainly a way to frame it, but I'd like to hold some space for the idea that the things we neuroatypical people do to manage and satisfy our own unusual perspectives are not irrational or useless if they make sense to us and serve a purpose for us. > Due to [clinical conditions], if the packages I am editing is not it > in a specific way, I am unable to focus properly. That too, if I am > working on multiple package definitions and if each pack-defs are > arranged in different way, it is very very hard for me. That is an interesting use-case I hadn't considered, but a valid one, and it gives me ideas. I'm going to experiment with some tools to make this feasible. Consider the tooling for Unison[1] which reduces code churn in a number of unique ways.[2] It can store programs as abstract syntax trees rather than plain text files, and it's content-addressed, referring to functions by their hashes rather than their fixed names. As a programmer that gives you the freedom to choose names and language syntax that suit you without imposing on others to follow suit. Due to the functional paradigm and technical structure of Guix, I think we can build some of the same capabilities in our tooling. Like Unison functions, our package definitions are reduced to a declarative content- addressed form, from which a textual definition could be generated again using a reverse process. By such a process, you & I could edit package definitions in whatever textual form suits us individually without having to agree on anything, not even the names of symbols. Then we can use a tool to automatically canonicalize our code into the form most widely acceptable to the community when it's time to submit a patch. Taking this idea to its logical conclusion & building on Guile's multi- language-syntax paradigm, I can picture using a futuristic tool to edit package definitions in Emacs lisp or JavaScript, again without requiring that anybody upstream adopt those languages or even recognize that I'm using them. I'll see what I can hack together for a naïve implementation of this concept and present it for review. > Moving forward, I will try hard not to do this. But can I ask you all > to allow these cosmetic commits for my existing projects (i.e. commits > from wip-desktop and pidgin patch-set) please? It doesn't bug me, but I know it does bug other people and imagine we want to avoid creating unnecessary review work for people who follow the commit stream. > I understand that these commits were a burden to everyone and my > sincere apologies for that. I appreciate the grace and consideration you brought to your response & all your contributions to Guix! [1] https://www.unisonweb.org [2] https://www.unisonweb.org/2020/04/10/reducing-churn/#definitions- getting-renamed-or-moved
