From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: removing white space highlight Date: Thu, 25 Feb 2016 23:08:29 -0700 Message-ID: <20160225221634972375976@bob.proulx.com> References: <878u28mj7z.fsf@debian.uxu> <87io1cuqhx.fsf@robertthorpeconsulting.com> <87ziuokv2g.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1456466928 25074 80.91.229.3 (26 Feb 2016 06:08:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 06:08:48 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Feb 26 07:08:47 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZBa2-0003Tb-WF for geh-help-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 07:08:47 +0100 Original-Received: from localhost ([::1]:47550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZBa1-0003ne-Uk for geh-help-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 01:08:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZBZr-0003nX-1P for help-gnu-emacs@gnu.org; Fri, 26 Feb 2016 01:08:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZBZm-0008R7-NB for help-gnu-emacs@gnu.org; Fri, 26 Feb 2016 01:08:34 -0500 Original-Received: from havoc.proulx.com ([96.88.95.61]:45012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZBZm-0008Qz-GX for help-gnu-emacs@gnu.org; Fri, 26 Feb 2016 01:08:30 -0500 Original-Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id E4E6314D for ; Thu, 25 Feb 2016 23:08:29 -0700 (MST) Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 81D11211DE for ; Thu, 25 Feb 2016 23:08:29 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 4E8A82DC5B; Thu, 25 Feb 2016 23:08:29 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87ziuokv2g.fsf@debian.uxu> User-Agent: Mutt/1.5.24 (2015-08-30) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 96.88.95.61 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:109323 Archived-At: Emanuel Berg wrote: > Robert Thorpe writes: > >> I'll be like that once for every file. > > > > Yes, for decades. > > Are there so really so many files that are left > untouched for so long? I have been staying out of this because Robert has been doing an excellent job of stating the issues. But I guess I will do my part too. > Why can't you do it once for all files? If you have placed an automated routine in your particular editor (remember that other people on your team will use different editors with differing capabilities) that touches every line in the file then you will start making changesets that contain a lot of noise. You will check in a result that cannot be reasonably reviewed by a peer review group. If the group is at all reasonable they will reject your change-set and send you back to work on it further. While producing a changeset it isn't enough simply to produce any old set of changes. Any slacker can made a random change and produce a truly awful large patch. It is the excellent programmer that understands the entire development process and produces a change that is easily reviewed so that it will be quickly accepted. I assume that if you are making a change that you are wanting it to be accepted. If not then why bother at all? I think that is the main point you are missing. You are thinking about yourself but you should be thinking about the reviewers who will look at the work you have done. If you are not thinking about their job then you are making their job much harder. If you make their job too hard they should simply reject your change and send you back to work on it further. And even for those folks who are just working solo. Your work is your reputation. If your work is good then so is your reputation. If your work is crufty then the same with your reputation. Because of version control your work is not just the finished file but the history of the file too. > > That's far too high a price to pay for being > > perfectionist about whitespace. > > Being a perfectionist in the negative sense is > spending too much time on stuff that doesn't mean > anything, really, and/or being neurotic about it. You discover a small chip of paint flaking off of the side of your house. Nothing is stopping you from immediately sanding, doing a full paint preparation with all of the needed caulking, then priming, then painting. Nothing is stopping you from doing this quite expensive, multiple day task immediately. Except that you may have been leaving for the airport to go on travel and just don't have time to do that before your flight takes off. And you might be out of budget for painting the house right now. You will probably not do all of these needed things /right now/ but queue them up for doing at some later time. And it is only a paint chip. A small thing. That later time might be years later. In the way that life is often busy with multiple things going on at the same time the same is true for software development. On large long running projects there will be many files that are doing their job fine but perhaps are not perfect in the abstract. While fixing a showstopper critical security hole bug in someone else's project that needs to make a minimum changeset immediately if not sooner you might see other things that could be polished up. You could drop everything and then spend six months fixing up that other project. But you can't. You need to make a minimum changeset patch to fix that problem /right now/. It needs to get through peer review and deployed. It can't wander about and tinker with other random things. And there is other work that needs to be done. This is why I think cleanup should be done explicitly as an explicit action and not as a side effect of other random changes. > However not wanting to have trailing whitespace and > having it automatized in four lines of Elisp and then > have the desired behavior forever seems like rather > good craftmanship to me... Your good craftmanship feels to me like a buldozer rolling through regardless of the other traffic. You will get to where you want to go but no one will want to be near you while you are doing it. Remember that with great power comes great responsibility. Bob [[Aside: What? You haven't painted your house in the last year? People will think your house is abandoned if you haven't changed the paint color at least every year. That is the way some software projects feel to me.]]