From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id eEpVC6tYyF9NMgAA0tVLHw (envelope-from ) for ; Thu, 03 Dec 2020 03:16:59 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 6KcOB6tYyF/5IQAAbx9fmQ (envelope-from ) for ; Thu, 03 Dec 2020 03:16:59 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D36729408EE for ; Thu, 3 Dec 2020 03:16:58 +0000 (UTC) Received: from localhost ([::1]:60970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkf73-0000P7-Qw for larch@yhetil.org; Wed, 02 Dec 2020 22:16:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkf6s-0000Ok-LU for guix-devel@gnu.org; Wed, 02 Dec 2020 22:16:46 -0500 Received: from imta-38.everyone.net ([216.200.145.38]:37864) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkf6p-0001AD-Ot for guix-devel@gnu.org; Wed, 02 Dec 2020 22:16:46 -0500 Received: from pps.filterd (omta003.sj2.proofpoint.com [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 0B338YFt011435; Wed, 2 Dec 2020 19:16:35 -0800 X-Eon-Originating-Account: G1E6bFvf4QnL3uzWVkkqi1C4cGJuQVJAdvY9YM7p3Gs X-Eon-Dm: m0116952.ppops.net Received: by m0116952.mta.everyone.net (EON-AUTHRELAY2 - 5a81c196) id m0116952.5f8a0279.96710a; Wed, 2 Dec 2020 19:16:33 -0800 X-Eon-Sig: AQMHrIJfyFiRVGnRSwIAAAAF,4bf70324fe4938ffa460590b04397ba2 X-Eip: 5nSbB3fi83BPvEp4deIJ2CkKeLY2XXwe_FdxgImc8lY Date: Thu, 3 Dec 2020 04:16:24 +0100 From: Bengt Richter To: Ryan Prior Subject: Re: Questionable "cosmetic changes" commits Message-ID: <20201203031624.GA49345@LionPure> References: <87mtywf35o.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-03_01:2020-11-30, 2020-12-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 phishscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 clxscore=1034 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012030018 Received-SPF: pass client-ip=216.200.145.38; envelope-from=bokr@oz.net; helo=imta-38.everyone.net X-Spam_score_int: -22 X-Spam_score: -2.3 X-Spam_bar: -- X-Spam_report: (-2.3 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bengt Richter Cc: Development of GNU Guix and the GNU System distribution , Raghav Gururajan Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.78 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: D36729408EE X-Spam-Score: -1.78 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: GdGQ9h1bKDRV 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 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