Re: Questionable "cosmetic changes" commits

["Raghav Gururajan" <raghavgururajan@disroot.org>]

Hi Ryan!

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

+1

I meant to say that, the actions were irrational by itself. But when contrasted with right reasons, we can see why sometimes an irrational act can be a rational act, when it benefits the agent's overall outcome.

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

Thanks Ryan!

Yeah, my brain laterally connects fields of different package definitions. Like a spread-sheet, where each columns are different package definitions and each row is a fields of a package's definition.

For example, if column 1 is glib and column 2 is gtk+, my brain spots pattern or errors when [arguments] field of both the packages are in the same row. Let's say [arguments] field of glib pack-def (column) is in 4th place (row); and; if the 4th place (row) of gtk+ pack-def (column) is [propagated-inputs]; my brain goes haywire. So I first do the cosmetic change of rearranging the fields of gtk+ pack-def to match with pack-def of gtk+. This is just one example.

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

That's very interesting. I'll have a look.

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

+1

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

Thank you Ryan!

>> 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 see.

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

Regards,
RG.