Re: Questionable "cosmetic changes" commits

[Raghav Gururajan]

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.