From: Bob Proulx <bob@proulx.com>
To: help-gnu-emacs@gnu.org
Subject: Re: removing white space highlight
Date: Thu, 25 Feb 2016 23:08:29 -0700 [thread overview]
Message-ID: <20160225221634972375976@bob.proulx.com> (raw)
In-Reply-To: <87ziuokv2g.fsf@debian.uxu>
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.]]
next prev parent reply other threads:[~2016-02-26 6:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 10:06 removing white space highlight Luca Ferrari
2016-02-18 10:19 ` Gian Uberto Lauri
2016-02-18 10:54 ` Luca Ferrari
2016-02-18 10:30 ` tomas
2016-02-18 13:34 ` Luca Ferrari
2016-02-18 13:17 ` tomas
2016-02-18 14:37 ` Luca Ferrari
2016-02-18 14:15 ` tomas
2016-02-18 16:08 ` Luca Ferrari
2016-02-19 0:23 ` Emanuel Berg
2016-02-19 1:05 ` Drew Adams
2016-02-19 16:02 ` Marcin Borkowski
2016-02-19 20:43 ` Emanuel Berg
2016-02-19 20:50 ` Marcin Borkowski
2016-02-20 0:30 ` Emanuel Berg
2016-02-20 19:08 ` Bob Proulx
2016-02-21 0:32 ` Emanuel Berg
2016-02-21 1:34 ` Bob Proulx
2016-02-21 1:48 ` Emanuel Berg
2016-02-21 3:27 ` Robert Thorpe
2016-02-21 3:31 ` Emanuel Berg
2016-02-21 5:00 ` Marcin Borkowski
2016-02-21 6:10 ` Emanuel Berg
2016-02-21 11:48 ` tomas
2016-02-21 17:13 ` Emanuel Berg
2016-02-23 0:33 ` Robert Thorpe
2016-02-23 0:41 ` Emanuel Berg
2016-02-24 0:44 ` Robert Thorpe
2016-02-24 1:41 ` Emanuel Berg
2016-02-24 20:38 ` Robert Thorpe
2016-02-25 0:10 ` Emanuel Berg
2016-02-25 8:47 ` Luca Ferrari
2016-02-25 9:29 ` Christian Kruse
2016-02-25 19:58 ` Robert Thorpe
2016-02-25 20:10 ` vc-region-history promotion (was: removing white space highlight) Stefan Monnier
2016-02-25 22:15 ` removing white space highlight Emanuel Berg
2016-02-25 22:41 ` Robert Thorpe
2016-02-26 0:02 ` Emanuel Berg
2016-02-26 2:58 ` Robert Thorpe
2016-02-26 3:29 ` Emanuel Berg
2016-02-26 6:08 ` Bob Proulx [this message]
2016-02-26 19:48 ` Emanuel Berg
2016-02-27 20:54 ` Robert Thorpe
2016-02-28 2:43 ` Emanuel Berg
2016-02-28 18:09 ` Robert Thorpe
2016-02-29 0:52 ` Emanuel Berg
2016-02-29 2:43 ` Robert Thorpe
2016-02-22 14:05 ` Luca Ferrari
2016-02-23 0:13 ` Emanuel Berg
2016-02-23 0:34 ` Robert Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160225221634972375976@bob.proulx.com \
--to=bob@proulx.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.