Re: Questionable "cosmetic changes" commits

[Ryan Prior <ryanprior@hey.com>]

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

On December 4, 2020, Raghav Gururajan <raghavgururajan@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

[-- Attachment #2: Type: text/html, Size: 5465 bytes --]