Re: Questionable "cosmetic changes" commits

[Bengt Richter <bokr@bokr.com>]

Hi Ryan, Mark, et al,

On +2020-12-02 20:13:56 +0000, Ryan Prior wrote:
> Hi Mark!
> 
> On December 2, 2020, Mark H Weaver <mhw@netris.org> wrote:
> > We all have our own personal preferences of how best to indent scheme
> > code, but if more of us adopted the habit of needlessly reordering
> > fields and reindenting code of every package we touch, as one of us
> > seems to have done, it could get out of hand quickly.
> 
> I don't particularly hold any opinion about stylistic commits except
> that I prefer tools like gofmt, Python's Black and standard.js which
> enforce uniform code style, and would use such a tool for my Guile code
> if it exists.

Agree.
As Tobias points out, it exists inside emacs. But I like small independent
tools for specific things. Especially if they compose well.

> 
> I do think it's important to acknowledge that the commits written by
> Raghav were part of his internship and advised by his mentors who signed
> off on the commits, so it's not like these changes were unsolicited and
> materialized out of nowhere.

I find myself with schizophrenic sympathies here :)

On the one hand:
    1. Don't make unnecessary work for me.
    2. If it ain't broke, don't fix it.
    3. Mother appreciates help in the kitchen, but
       don't touch the fine crystal! (Mother: "That's precious,
       from your great grandmother, only for special occasions.
       You know what cut glass crystal like that is worth?"
       Smarty Kid: "Buying or selling?" :)
    4: At work, sign for janitorial services: DO NOT MOVE
       ANYTHING ON MY DESK!! (arrangement of untidy mess encodes
       part of my workflow state).
On the other hand:
    1. I habitually use emacs scheme-mode indenting as well as shell-script-mode,
       and find it a useful lens to reveal the meaning of the code, and my errors.
    2. I prefer to read pretty-printed code, and wouldn't mind if all
       submitted code automatically were canonicalized in a well-defined way.
       I use emacs indenting because it is right there when I am editing.
    3. NOT to canonicalize can obscure dumb errors, and that can be a smokescreen for worse.
    4. For code, it is the abstract syntax tree that matters (in telling the machine
       what to do), not cosmetics, but cosmetics matter in making info human-sensible.
In conclusion:
    1. I want the best of all worlds, so I always like to pick a la carte,
       unless the Chef is three-flowers-plus, or I am budget-constrained.
    2. I lean towards wanting a standard pretty-print canonicalization, if it doesn't make work for me ;)
    3. diff has options to ignore white-space differences, etc., so I wonder what tools need what options
       to ease Mark's pain, (until everything is canonicalized, when that pain should disappear anyway).
    4. Canonicalization should actually help make reviewing easier, and more effective, IWT.
    5. I would like better factoring of functionality, so that e.g. I wouldn't have to start emacs
       (I know, some never leave :) to canonicalize a file the way scheme-mode does. Unix philosophy?
       (E.g., don't give cat a new built-in option like -nA, but realize how easily it could compose with a factored-out
       scheme-source canonicalizer. Some of you could probably write a bash script to use emacs as a filter,
       but is that a sensible way to go? Probably, if you are a fluent hacker and you need a tool in a hurry,
       but not for deciding separate and separable distribution components.
       (I think I got my nostalgic ideas of components from Meccano kit from the '40s ;)
tl;DR:
   1. I vote for running all code to be submitted through a standard pretty-printing canonicalizer.
      It could even inject TODO stubs for missing synopses, and doc strings (as an option :)
-- 
Regards,
Bengt Richter